ComplyCube vs Didit

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.

Didit

A self-serve verification API with public per-check prices, key registration by API, scoped keys and a 365-day audit log. The status page shows three incidents marked major between 22 July and 4 September 2026, each a partial outage of the core APIs, and the sub-processor list isn't public.

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

Didit

1. Register with POST https://apx.didit.me/auth/v2/programmatic/register/, then verify-email with the emailed 6-character code. Use a real inbox, because reserved test domains return 500.
2. Send the key as x-api-key to https://verification.didit.me/v3/. The JWT from registration works only on apx.didit.me.
3. Create a workflow before POST /v3/session/. workflow_id is the only required field, and an unfinished session with the same vendor_data is returned again.
4. Read results from webhooks and use GET /v3/session/{sessionId}/decision/ for back-fill. Every per-feature result is a plural array.
5. The MCP server at https://mcp.didit.me/mcp takes OAuth sign-in only, never an API key. Approve didit:verification alone when the task doesn't change workflows or keys.