Get started

Sandbox and testing

The sandbox is a full copy of the VerifyMe API and hosted UI with simulated providers. Nothing is billed, no real SMS is sent, and every outcome (success, mismatch, outage) can be triggered with specific test values.

Environments

Each environment is a separate deployment with its own data. A request, key or webhook endpoint created in the sandbox does not exist in production. The sandbox host is whatever your deployment uses; the samples here use https://kyc.example.com.

Test data

Enter these values in the hosted UI. All of them are deterministic.

Mobile and email OTP

Aadhaar via DigiLocker

The DigiLocker step opens a simulator consent page (/mock/digilocker/{txn}) clearly labelled as a sandbox simulator.

PAN

PAN format is five letters, four digits, one letter (ABCPK1234F). The 4th character gives the category (P individual, C company, F firm, H HUF, T trust, A AOP).

Bank account

IFSC format: four letters, a zero, six letters or digits.

Selfie, liveness and uploads

Address and pincode

The pincode lookup is simulated from the first two digits: 11 New Delhi, 12 Gurugram, 14 Ludhiana, 17 Shimla, 20 Lucknow, 30 Jaipur, 38 Ahmedabad, 40 Mumbai, 41 Pune, 45 Indore, 49 Raipur, 50 Hyderabad, 56 Bengaluru, 60 Chennai, 64 Coimbatore, 68 Kochi, 70 Kolkata, 75 Bhubaneswar, 78 Guwahati, 80 Patna. Other prefixes return not found, so the applicant fills city and state manually. Pincodes cannot start with 0.

Personal details and consent

• Full name accepts letters, spaces, dots, apostrophes and hyphens. Date of birth is YYYY-MM-DD; under the flow's minAge (18) gives UNDERAGE.
• The consent step requires accepted: true; otherwise CONSENT_REQUIRED.

Sandbox inbox

Because no real SMS or email leaves the sandbox, every message the simulated providers "send" is kept for one hour (the latest 30 per channel) and shown in the portal's developer sandbox inbox. The recipient is masked as it would be in logs. The API behind it is GET /api/portal/sandbox/messages, available only in the sandbox (404 in production). The OTP is also in the step response as sandboxCode, which is what the hosted UI displays under the input.

Webhook sink and simulated events

• Sink: POST /api/portal/webhooks/sandbox-sink (the portal button) creates an endpoint whose URL is /demo/sink/{endpointId} on the sandbox host. It verifies the signature like a correct consumer and records the last 30 deliveries. See Webhooks.
• Simulated events: POST /api/portal/sandbox/emit with { "type": "onboarding.approved", "requestId": "vm_req_..." } emits a single event with data.simulated: true. Useful to exercise your handler for events that normally need a human (approve, reject, revert).
• Real end-to-end: submit a request in the hosted UI, then approve or reject it as a reviewer in the portal's review queue. The review policy of your tenant decides whether decisions are manual (MANUAL, the default), automatic when no HIGH flag exists (AUTO) or when no flag other than INFO exists (HYBRID).

Simulating failures

Resetting

There is no one-click reset of sandbox data. To start clean: cancel open requests with POST .../cancel, use new externalReference values (or leave the block_active duplicate policy off), revoke old keys, and delete old webhook endpoints. Requests expire by themselves after the TTL.

Going live

1. Complete the go-live checklist.
2. Replace the sandbox host with the production host and vm_test_ with vm_live_ keys, and the publishable key if you embed.
3. Re-create webhook endpoints in production (they are not copied) and store the new secrets.
4. Re-save return URL allow-list and allowed origins for the production workspace.
5. Bind real providers and publish your flow in production, then run one real end-to-end verification yourself.
6. Remove any sandbox sink endpoints and demo credentials from shared environments.