Authentication
API keys, the two accepted headers, and what each scope unlocks.
Every authenticated endpoint accepts either header. Send one, not both.
Authorization: Bearer vrf_live_...X-API-Key: vrf_live_...What the gateway checks
Before forwarding a request the gateway validates that the key is active, unexpired, in the correct environment, and permitted by any endpoint allowlist attached to it. It then adds signed workspace and scope headers of its own.
Those internal headers belong to the gateway. Do not generate them, and do not depend on them.
Scopes
A key carries scopes. A request whose scope is missing gets 403, not 401.
Each operation in the reference states the scope it needs.
| Scope | Capability |
|---|---|
reports:create | Create and launch reports; add or resend reference requests. |
reports:read | List and read reports, consent state and references. |
reports:write | Delete reports. |
monitoring:read | Read recurring checks and alerts. |
monitoring:write | Create and remove recurring checks, and update alerts. |
webhooks:manage | Read and change outbound webhook configuration. |
Dashboard-only actions
Some workspace actions — reviewing, approving and rejecting reports — are available only to people signed in to the Verifisha dashboard. They are not part of this API.
Keeping keys safe
- Use
vrf_test_keys everywhere except production. - Restrict a key's endpoint allowlist to the routes that key actually calls.
- Rotate by issuing a new key, moving traffic, then deactivating the old one — deactivation takes effect at the gateway immediately.