Go live
The checklist before you switch a live key into production traffic
Going live is a key swap. Your account can process real applicants from day one, so nothing has to be unlocked and nobody has to approve you: create a live key in your dashboard and your traffic is live. That is exactly why the checklist below matters. Work through it first, because most of it is much harder to fix after real users are flowing through.
Integration checklist
Your secret key lives only on the server
Search your front-end bundle for TWK_. The browser should only ever hold a
client_token returned by the create call.
You verify webhook signatures
Compute the signature over the raw request body bytes, before any JSON parsing or re-serialization, and compare in constant time. Reject anything that does not match, and reject anything whose timestamp is outside your tolerance window. See Webhooks.
Your webhook handler is idempotent
The same event can arrive more than once. Deduplicate on the event id, and make the state
transition itself safe to repeat, keyed on the verification id.
You act only on terminal statuses
pending and processing are not decisions. Only approved, rejected and manual_review are,
and expired means the user never finished. See Statuses.
You send an Idempotency-Key on create
Network retries otherwise create duplicate verifications for the same user. See Idempotency.
You tolerate new fields
The API is additive. New properties can appear on existing responses without a version bump, so do not use strict object mappers that throw on unknown keys.
You handle the failure branches
Test a decline, a manual review and an expiry against the sandbox, not just the happy path, and confirm the message you show the user is right in each case.
Your consent flow is recorded
Biometric verification requires the user's explicit, informed consent before capture. Record it through the consent endpoint so the record is attached to the verification. The hosted flow does this for you.
Switching over
Create a live secret key in your dashboard, deploy it, and confirm the first live verification's
mode comes back as live. Keep the sandbox key in your staging environment so you can keep
exercising the failure branches after launch.
A live key also carries a narrower permission set than a sandbox one, so confirm nothing in your production path depends on a read that only a sandbox key is scoped for. See Permissions.