Testing with sandbox numbers

The sandbox lets you exercise every Konera API against synthetic numbers that return deterministic results — including the failure paths you can't easily trigger with a real device. Build and test your full integration before requesting production access, with no real subscribers and no cost.

What the sandbox gives you

• Deterministic responses. A given sandbox number always returns the same result, so your tests are repeatable.
• Every path, including failures. Trigger a SIM-swapped number, an unverified device, or a partial KYC match on demand — no waiting for real-world conditions.
• No real data, no cost. Synthetic MSISDNs only; nothing is billed and no real subscriber is touched.
• Same shapes as production. Request and response formats match production exactly, so code tested here works unchanged when you go live.

Sandbox vs. production

The synthetic number set

Each sandbox number maps to a fixed scenario. Use the number that triggers the path you want to test:

Example — trigger a SIM-swap hit

Call SIM Swap with the swap-scenario number to exercise your high-risk branch:

curl -X POST https://api.pxg.konera.com/camara/sim-swap/v2/check \
-H "Authorization: Bearer $SANDBOX_TOKEN" \
-H "Content-Type: application/json" \
-d '{"phoneNumber":"+14155550101","maxAge":2400}'

{ "swapped": true }

A testing checklist

• Cover the failure paths. Don't just test the happy number — wire tests for unverified, swapped, partial, and unavailable.
• Assert on the decision, not the raw field. Test that your risk logic returns BLOCK / STEP_UP / PROCEED, so refactors stay safe.
• Test token expiry. Confirm your client refreshes when a token expires (see OAuth2 with Konera).
• Test callbacks in QoD. Use the unavailable-scenario number to confirm your fallback fires (see Working with callbacks).
• Keep sandbox and production config separate. Different base URL / credentials per environment so you never test against live subscribers.

Moving to production

When your tests pass against the sandbox, request production access for your application. Swap the sandbox credentials for production ones — the request and response shapes are identical, so no code changes are needed beyond configuration. Start with low volume and watch your error rates as real network data replaces the synthetic set.

Next steps

• Your first verified API call — the basic call flow.
• Fraud prevention — the decision logic these numbers let you test.
• Rate limits & error handling — error shapes to assert against.