Environments and sandbox
Which host and key prefix to use, and what sandbox covers.
| Environment | Base URL | Key prefix | Behaviour |
|---|---|---|---|
| Sandbox | https://sandbox-api.verifisha.com | vrf_test_ | Deterministic fixtures where sandbox support exists. Paid providers are never called. |
| Production | https://api.verifisha.com | vrf_live_ | Production services. Can execute billable checks. |
The key prefix is what decides whether a paid provider can be called. Pair each key with its own host.
Older keys with a bare vrf_ prefix take their environment from the key
record, so the request itself gives no signal whether it will bill. Use an
explicit vrf_test_ or vrf_live_ key for new integrations.
What sandbox covers
Sandbox coverage is deliberately narrower than production. Fixtures exist for:
- creating, reading and launching reports
- reading check definitions
- pricing
Sandbox report fixtures include an IDENTITY result.
When there is no fixture
A sandbox request with no configured fixture returns
SANDBOX_ROUTE_NOT_FOUND or SANDBOX_FIXTURE_NOT_FOUND. It is not
forwarded to a paid provider — a missing fixture can never become a live charge.
Telling the two apart
Gateway responses carry X-Request-Id. Sandbox responses also carry:
X-Verifisha-Sandbox: trueAssert on that header in your integration tests. It is the cheapest guard against a live key reaching a test suite.