Skip to main content

JWT Tokens

SpitShake uses JSON Web Tokens (JWT) to authenticate embedded signing forms and template builders. Tokens are generated server-side, scoped to a specific resource (submitter or template), and passed to the frontend embed components.
Tokens authenticate the JSON routes under /api/embed only. Embed the signing form with the submitter’s signing link (embed_src); the form ignores a token. The token-based builder page (data-token on <docuseal-builder>) is not available yet.

Overview

Token types

SpitShake issues two types of embed tokens, each scoped by the aud (audience) claim.

Form tokens

Form tokens authenticate a signing session for a specific submitter. The sub claim contains the submitter ID, and the sid claim contains the submission ID. Full JWT claims:
Claim reference:

Builder tokens

Builder tokens authenticate access to the template editor for a specific template. The sub claim contains the template ID. Full JWT claims:
Claim reference: When opts.fields is populated, it contains field definition objects:

Expiration defaults

Tokens are validated on every request. An expired token returns a 401 Unauthorized response with:

Generating tokens via the API

Use POST /api/embed/token to generate embed tokens. Authenticate with your API token in the X-Auth-Token header.

Generate a form token

Response:

Generate a builder token

Response:

Security best practices

POST /api/embed/token needs your API token, so call it from your server and pass only the resulting embed token to the browser. Never put the API token in browser code.
Form and builder tokens last 4 hours. Request a fresh one each time you render the embed instead of storing one.
Each token should be scoped to exactly one submitter (form) or one template (builder). Never create tokens that grant access to multiple resources. The sub claim enforces this scoping.
SpitShake checks the aud claim: a form token is rejected on the template routes and a builder token on the signing routes. A form token also opens only the submission it was minted for. A builder token reads its template; edits go through PUT /api/templates/{id}.
Avoid passing JWT tokens as URL query parameters. URLs are logged in server access logs, browser history, and proxy logs. Instead, pass tokens via data-token attributes or JavaScript configuration objects.

Token flow diagram

The typical token flow for embedding:
1

Backend generates token

Your server calls POST /api/embed/token with the submitter/template ID and desired options.
2

Token sent to frontend

Your backend returns the token to the browser, either as part of an HTML page render or via an AJAX response.
3

Frontend passes token to embed

The token is set as a data-token attribute on the web component, or passed to SpitShake.mount() / SpitShake.mountBuilder().
4

Embed validates token

The SpitShake iframe receives the token, validates the signature and expiration, and loads the appropriate resource (form or builder).
5

Token expires

After the configured expiration time, the token is no longer valid. If the user’s session is still active, your backend should generate a fresh token.

Troubleshooting