Sandbox to Production: Going Live with the VerifyAll API

Two keys, two environments

An approved VerifyAll account has exactly two API keys. The key you send decides what happens; there is no header, field or flag that makes a Production call free, or a Sandbox call real.

Both keys call the same address, https://api.verifyall.ai, with the same request fields and the same answer envelope. That is the point: code written against the Sandbox works in Production by changing the key.

What the Sandbox is good for

• Building the whole flow. Any well-formed request gets a sample answer, so you can build the request, parse the answer, store the checkResultId and read the result back with GET /check-results.
• Input validation. A missing or malformed field is refused in the Sandbox exactly as in Production, with a list of every problem in details.fields. Unknown fields are refused, never ignored.
• Permissions. The checks you may run are the same as in Production. Your account calls the APIs enabled for it, separately for Sandbox and Production, and a check that is not enabled is refused the same way.

What the Sandbox does not do

• It never tells you anything about a real person or business. Do not use a Sandbox answer for a decision.
• It does not reproduce every outcome, such as a no-record answer or a source error. Use the examples on each endpoint's page in the docs for those.
• It does not test your wallet, prices or the low-balance email.
• It cannot read your live records (saved credit reports, legal checks, background verifications, bulk batches or PDF reports), and it cannot switch on case watch. Those need the Production key.
• A step with no sample answer yet is refused with 503 provider_sandbox. That is a Sandbox limit, not an outage.

The go-live checklist

Work through this before the first Production call:

1. Keep the key on your server. Store the Production key in a secret store or an environment variable, never in a web page, a mobile app or a code repository.
2. Lock it down. Add an IP allow-list with your servers' outbound addresses (up to 50 addresses or CIDR ranges), and an expiry date if your policy rotates secrets.
3. Fund the wallet. Production calls are paid from the prepaid wallet. If the balance is too low, the call is refused with 403 balance_exhausted before anything is charged. Make sure someone watches the low-balance email.
4. Read message_code on every answer. success means a result; record_not_found means the lookup ran and found nothing, and it is charged. Errors carry success: false, a message you can show a person and a message_code your code can act on.
5. Send an Idempotency-Key with every check. A resend with the same key after a timeout returns the first answer and never charges twice.
6. Wait long enough. Most checks answer within seconds; set your HTTP client to wait at least 90 seconds.
7. Hold the consent. Every check about a person carries a consent object; a credit report also records when and how consent was given and the version of the consent text. Keep your own record of each consent.
8. Store what you need later. Keep the checkResultId (or the record id of a check that finishes later), your client_ref and the X-Request-Id with your own record.

Switching the key

Create the Production key under Developers in the dashboard. You type the account name to confirm, because every call with it runs a real check. The full key is shown once: copy it into your secret store straight away. VerifyAll keeps only a fingerprint, so a lost key is replaced by rotating it, never recovered.

Then swap the key and send a real identifier. The placeholder values the docs use, such as ABCDE1234F, are refused in Production with 400 invalid_request before anything is charged.

After go-live

• The usage page under Developers lists the calls of both keys.
• Checks that finish later (legal, background verification, full vehicle legal, MCA documents and bulk) answer with outcome: pending. Add a webhook under Developers > Webhooks to be told when they finish, or read their record every few minutes, not in a tight loop.
• If a key may have leaked, revoke or rotate it at once. Rotation issues a new key and stops the old one immediately.

For the full picture of the API, from access to pricing, see the Developer API page. For an example integration, read Integrating KYC and KYB checks into your ERP.