Sandbox

Sandbox is a parallel environment for building and testing integrations. It runs the same API, on the same host, with a separate set of vaults, envelopes, templates and contacts.

Read this page before you point a sandbox token at real data. Two things behave differently from what most people assume.

Getting in

There is no separate URL and no extra header. You create a sandbox token in the app, and the API serves sandbox data for every request made with it.

Sandbox requires the Business plan or above, the same as production. If sandbox is switched off for your account, requests return 403 with Sandbox mode is disabled. — an account administrator turns it back on in Account settings.

Read this before you test

Signers really are contacted. Only one-time codes are suppressed. Invitations and reminders are sent for real — by email, SMS and WhatsApp — to whatever address or number you put on the signer. Use addresses you control.

Publishing consumes a real envelope from your balance. The envelope balance has no sandbox dimension: a sandbox publish debits the same pool as production, and there is no refund.

Together these mean a sandbox test with a colleague's address and a live plan behaves, from the outside, exactly like production.

One-time codes

In sandbox the code is always 123456. It is accepted for email, SMS and WhatsApp validation, and it works without requesting a code first — you can submit it straight away.

Factor	Sandbox behaviour
`shouldEnforceEmailValidation`	`123456`
`shouldEnforceSmsValidation`	`123456`
`shouldEnforceWhatsAppValidation`	`123456`
`shouldEnforcePixValidation`	The Pix charge is marked paid automatically; request it and it succeeds
`shouldEnforcePasscodeValidation`	Identical to production — you set the passcode when creating the signer

Selfie, identity document and face match run against the real providers in sandbox; there is no shortcut for them.

Documents are not signed in sandbox

A sandbox envelope reaches Signed, but no cryptographic signature is applied to its documents. GET /documents/{id}/signed returns the file with the markup stamp and nothing else — no certification seal, no timestamp, and the signed-file hashes are never populated.

The audit certificate, however, is produced and sealed for real — same PAdES certification, same timestamp, same LTV. So in sandbox you get a genuinely signed certificate describing documents that are not signed. Use sandbox to exercise your workflow, never to inspect a signature.

What is isolated, and what is not

Isolated: vaults, envelopes, templates and contacts. A sandbox token cannot list or open production ones, and the reverse holds too.

Not isolated:

Documents. A document carries no environment flag — only an account. One uploaded with a production token can be attached to a sandbox envelope, and the other way round.

File storage. Both environments share the same buckets and key layout.

Envelope balance. One pool, as above.

Rate limits. Sandbox tokens get the same 1,000 requests per 10-minute window, counted separately per token.

Webhooks are configured separately per environment, and every payload carries an env field of production or sandbox, so a shared endpoint can tell them apart.

Owner notifications are off by default

The account-level notification settings that mirror production events into sandbox all default to off. If you expect an email when a sandbox envelope is signed and nothing arrives, that is why — enable them in Account settings.

Moving to production

Swap the token. Nothing else in your integration changes: same host, same paths, same payloads. Register your production webhooks first — they are a separate configuration and do not carry over.

Getting in#

Read this before you test#

One-time codes#

Documents are not signed in sandbox#

What is isolated, and what is not#

Owner notifications are off by default#