Veriff · Rate Limits

Veriff Rate Limits

Veriff applies dynamic rate limiting on the Public API at stationapi.veriff.com. Numeric per-second ceilings are not exhaustively published, but Veriff's docs acknowledge that abusive volume returns 429 Too Many Requests. Authentication is via X-AUTH-CLIENT (API Key) and X-HMAC-SIGNATURE (request body HMAC SHA-256 with the shared secret). Webhook delivery is signed with the same shared secret and retried on transient receiver failure. Reconciliation against a published numeric ceiling pending - confirm with Veriff Solutions Engineering for high-volume integrations.

3 Limits Throttle: 429
KYCIdentity VerificationBiometricsFraud PreventionAMLRate LimitingThrottling

Limits

Per-API-Key Throttle api_key
requests ยท minute
dynamic
Numeric ceiling not published; sustained excessive request volume returns 429 Too Many Requests.
Session Lifecycle session
state_transitions
standard
A session moves from created to submitted to a terminal decision. PATCH to mark submitted must follow media uploads or the decision logic will run with missing data.
Webhook Delivery Retry subscription
events
best-effort with retry
Veriff retries webhook delivery on receiver failure. Customers should respond with 2xx promptly to avoid retries; persistent failures pause the subscription.

Policies

429 Throttling
Excessive throughput against the Public API returns 429 Too Many Requests. Clients should back off before retrying.
HMAC Signature Verification
Every request must include X-AUTH-CLIENT and X-HMAC-SIGNATURE; webhooks must be verified using the same shared secret before the decision is treated as authoritative.
Backoff Strategy
Implement exponential backoff with jitter on 429 / 5xx responses. Cache decisions locally to avoid repeated session lookups.
Submit Once Media Is Uploaded
Do not PATCH a session to submitted before all media has been uploaded - the decision logic will run on the captured state.

Sources