ComplyCube vs Shufti

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.

Shufti

One endpoint covers document, face, address, AML and KYB checks, with a free plan of 10 verifications a month, and a hosted MCP server adds OAuth with three scopes. No OpenAPI file, server SDK or idempotency key was found, and the status page history could not be read.

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

Shufti

1. POST every verification to https://api.shuftipro.com/ with a unique reference of 6 to 250 characters and one object per service. Read results from /status with that reference
2. Register the callback domain in the back office first. An unregistered callback_url is rejected
3. Stay under 60 requests a minute per IP on a production account and 20 on a trial account
4. Check the Signature response header. Accounts created after 15 March 2023 hash the Secret Key with SHA-256 before appending it to the raw response
5. Through MCP, identity checks return a verification_url for the person to open. No tool accepts an image, so use the REST API for offsite proofs