Sandbox
Sandbox API keys for identity verification.
A sandbox key runs the identical API, hosted page and webhook flow as production, on a key that is never billed. It's the fastest way to see whether ShieldID fits before you talk pricing.
How it works
Same pipeline. Different key. No invoice.
Sandbox isn't a simplified demo mode — it's the real verification pipeline, gated purely by which key you send.
| Key prefix | vk_sand_… identifies a sandbox key at the moment you authenticate. There's no separate sandbox account or dashboard to configure. |
|---|---|
| Environment stamp | Every session, result and webhook created with a sandbox key carries environment: "sandbox", so nothing sandbox-created can be mistaken for a real verification downstream. |
| Billing | Sandbox sessions are never billed, on every plan, for as many sessions as you need to build and test your integration. |
| The verification itself | Real: your own document, your own face, the same checks. There's no separate set of fake test documents — you verify yourself to see how the product behaves. |
Getting a key
Request one today. Self-serve is coming.
Self-serve sandbox key creation on qualifying plans is planned but not yet scheduled. Until it ships, a request through the contact form gets you a key directly.
Today
Tell us a little about what you're building on the contact form and we'll turn a sandbox key around — most requests the same business day.
Soon
Coming soonSelf-serve sandbox key creation, on qualifying plans, is planned but not yet scheduled, so you can generate a key the moment you sign up.
Try it yourself
Test scenarios you can run on your own phone.
No fake documents needed — run these against your own ID to see how each path actually behaves.
A clean pass
Create a session, open the hosted page, photograph your own ID and complete the liveness challenge. Watch checks.document, checks.liveness, checks.antispoof and checks.face_match each come back PASS.
A declined camera
Deny the camera permission when the hosted page asks. The session resolves to FAILED with a failure_reason you can build a real error message around.
A retry after failure (coming soon)
Reopening a FAILED session's verification_url to reset it to PENDING for a second attempt isn't live yet. Today, treat FAILED as terminal — create a new session if the applicant wants to try again.
An expired session
Create a session and leave it untouched. After the default window it moves to EXPIRED, with no person or checks data — a good state to test your UI's timeout messaging.
A cancelled session
Call DELETE /v1/sessions/{id} on a PENDING session, then try to open the verification_url. Confirm your app treats a cancelled session as done, not as an error.
French locale
Create a session with locale: "fr" and confirm the hosted page and your own return-URL handling read correctly for a French-speaking applicant.
Limits
What sandbox doesn't do.
Plain answers, not fine print.
- Sandbox has no separate rate limit from production — no request is currently throttled by plan-level limits at all; that enforcement is not live yet.
- Sandbox and production are separate purely by key prefix, not by separate accounts, dashboards or document sets.
- A sandbox session is a real verification of a real document. Don't use someone else's ID to test — verify your own.
Questions
Sandbox FAQ.
Get a key
Request a sandbox key.
Tell us what you're building and we'll get you a key to start testing.
Sandbox sessions are never billed.