ComplyCube vs Veriff

ComplyCube

A sandbox with its own key and scripted outcomes, a public OpenAPI spec, Markdown docs and an audit log API suit an agent running verification checks. Each environment has one unscoped key, no idempotency keys were found, and the only published terms are undated and read as website terms.

Veriff

Per-verification prices are public from $0.80, with a 15-day trial of 50 sessions and no card. Each endpoint page is Markdown with an OpenAPI 3.0 fragment. There is no server SDK, MCP server or idempotency key, most calls need an HMAC signature, and the status page shows nine incidents between 20 July and 7 October 2026.

ComplyCube

1. Send the key bare in the Authorization header, with no Bearer prefix. Keys start test_ or live_
2. Create a client first, then documents or live photos for it, then POST /v1/checks with the client and upload IDs
3. Stay under 10 requests a second live and 5 in the sandbox. On 429, back off exponentially with jitter, starting at 30 seconds
4. A badly formed filter returns 200 with no results, so check filter names before trusting an empty list
5. Checks are asynchronous. Subscribe to webhooks, verify the ComplyCube-Signature HMAC-SHA256 header, and expect duplicate and out-of-order events

Veriff

1. Take the base URL from the integration's API keys page. Send X-AUTH-CLIENT on every call and store verification.id from POST /v1/sessions
2. Sign POST and PATCH bodies, and the session ID on GET and DELETE, with HMAC-SHA256 in X-HMAC-SIGNATURE. POST /v1/sessions needs no signature
3. Stay under 30 session creations a minute on Self-Serve, 600 on Enterprise. A 429 carries code 1004
4. Don't blindly retry POST /v1/sessions. Each call makes a new session, which is billed on a live integration
5. Poll GET /v1/sessions/{id}/decision until verification is not null, or accept webhooks within 5 seconds and treat duplicates as normal