Submission IDs and access tokens
Each Submission has a stable, opaque ID you'll see in URLs and exports. Separately, Submissions and Continue Links use short-lived tokens for consumer access. IDs are safe to share inside your agency; consumer-facing tokens are time-limited for security.
In short: The Submission’s ID is the stable identifier you see in the URL and exports — share it freely with teammates. Continue Link tokens are short-lived and meant for the consumer’s use only.
Two kinds of identifiers
Each Submission carries:
- A stable Submission ID — opaque (not sequential), present in the URL when you view the Submission, included in exports, and referenced by integrations. Think of this as the Submission’s permanent name.
- Token-based access strings — used in Continue Links and document request links to let consumers in without logging in. Time-limited for security.
The two serve different purposes. Don’t confuse a temporary token in an email with the permanent ID.
When you’d reference a Submission ID
- Internal communication. “Hey, can you take a look at sub_abc123?” is fine in Slack or email between teammates.
- Integrations. Webhooks and API responses include the Submission ID.
- Support cases. When opening a ticket with SALT support, the Submission ID is what they need to find your record.
- Exports and reporting. Each row carries the ID for downstream cross-reference.
Tokens — what they’re for
Tokens authorize consumer-facing access without requiring the consumer to sign in. SALT generates a token, embeds it in a URL, and sends that URL to the consumer:
- Continue Links carry a token that expires in 30 minutes.
- Document request links carry a similar token.
- Form-fill resumption may use a token-based access flow.
Tokens are scoped to a specific action and a specific Submission. They expire fast on purpose — a leaked token is useful to an attacker for at most a short window.
Don’t share tokens internally
Tokens are for consumers. Sharing a Continue Link token with colleagues is the wrong tool — use the Submission ID and the internal URL instead. Internal URLs require sign-in; tokens bypass it for the consumer’s specific session.
What if a token leaks?
If you suspect a token has been shared inappropriately:
- Token expiry naturally limits damage — most expire in 30 minutes.
- Generate a fresh one to invalidate the assumption that the leaked token still works (where supported).
- For a serious leak — for example, a token-bearing email forwarded to many people — contact support to discuss invalidation options.
For day-to-day use, token leakage is a minor concern thanks to the short expiry.
Common questions
Is the Submission ID the same as the consumer-facing URL token? No. The ID is internal and stable; the consumer-facing token is short-lived. They appear in different places — the ID in your URLs, the token in emailed Continue Links.
Can I look up a Submission by phone or email instead of by ID? Yes — search the Submissions list by phone or email. The ID is just one of many ways to find a record.
If I delete a Submission (where possible), is the ID reused? No. SALT IDs are opaque and never reused. Deleted IDs simply stop resolving.
Can I customize my Submission IDs (e.g. prefix with my agency name)? Not today. IDs are SALT-generated. For agency-friendly references, use Tags or a custom field.