Sandbox vs production
Understanding the boundary between environments keeps your integration safe and predictable.Test entity creation
You can create a test entity with minimal fields. The only hard requirements areentityType and isSubjectConsent. For a sandbox individual entity, the combination below is enough to get a scored, tracked record:
ent_… entity ID you can reference in all subsequent calls — verifications, transactions, cases, and signals all attach to the same ID.
Creating an entity from just an email is supported in sandbox and production, but is reserved for entities tagged as downstream entities (the payment-processor customer model, where only an email is initially known). For standard individual onboarding, provide at minimum a name.
Test IDs for Nigerian identity verification
Use the following synthetic IDs when testing KYC verification endpoints against Nigerian government document types. These values are recognised by the sandbox and return predictable mock responses without querying live government databases.- BVN
- NIN
- Driver's License
- Passport
The Bank Verification Number (BVN) is an 11-digit identifier issued by the Central Bank of Nigeria.
Submit this test BVN via the entity KYC verification endpoint, replacing
{entityId} with the ent_… ID you received when you created your test entity:Sandbox response behaviour
Keep these differences in mind as you build and test:Partial field coverage
Partial field coverage
Sandbox responses may return fewer fields than production. For example, a BVN lookup in production returns a full identity profile enriched from live NIBSS data; the sandbox equivalent returns a smaller mock payload. Build your integration to handle optional or absent fields gracefully.
Predictable risk scores
Predictable risk scores
Sandbox entities are scored on the synthetic data you provide. An entity with only an email receives a low but non-zero risk score reflecting the limited profile. Add more fields — name, date of birth, phone — to see the score adjust as the profile enriches.
AML screening results
AML screening results
PEP, sanctions, and adverse-media screening in sandbox returns mock results. Use test names known to return a hit (e.g.
"firstName": "Sanctioned", "lastName": "Person" in specific test scenarios) if your integration needs to handle AML alerts. Refer to the AML testing guide for a full list of trigger values.No real checks fired
No real checks fired
The sandbox never contacts live government databases, credit bureaus, or watchlist providers. You can run as many verifications as you need without any compliance or billing consequence.
Recommended sandbox workflow
Follow this sequence when setting up a new integration or testing a new verification type:1
Set your environment variables
2
Create a test entity
Use the minimal payload (entity type, consent, name, email) to get an
ent_… ID.3
Run the verification you want to test
Use the test IDs from the tables above. Pass the
entityId so the verification result attaches to the entity’s 360.4
Read the Entity 360
Call
GET /v2/api/entities/{id} to confirm the verification result has folded into the entity’s profile, risk score, and activity log.5
Repeat with edge-case inputs
Test missing fields, invalid ID formats, and duplicate submissions to confirm your error handling is robust before going to production.
Moving to production
When your sandbox integration is working correctly, switching to production requires two changes only:- Replace your sandbox API key with the production API key from cowork.youverify.co Settings → API Keys → Production.
- Replace the sandbox base URL with the production base URL:
https://api.youverify.co.
Production checks query authoritative government data sources and are billed. Run a small smoke test with one real subject before enabling high-volume production traffic.