ComplyCube vs Sumsub

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.

Sumsub

Per-token permissions, an IP allowlist, HMAC-signed requests and a public OpenAPI spec with Markdown docs suit an agent working on verification cases. No idempotency keys or Retry-After guidance were found, there is no server SDK, and production access needs a browser signup, a bank card and Sumsub's review of the integration.

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

Sumsub

1. Sign every request. X-App-Access-Sig is the lowercase hex HMAC-SHA256 of timestamp, uppercase method, path with query and raw body, and the timestamp must be within one minute of server time
2. Use a sandbox token (prefix sbx) for agent work. Sandbox and production tokens are separate, and Sumsub's own skills refuse any other prefix
3. Stay under 300 GET and 50 POST requests per 5 seconds, and under 500 new applicants per 24 hours in Sandbox
4. Token permissions can't be edited after creation. Generate a new token with the narrower set and delete the old one
5. Subscribe to the applicantReviewed webhook for results and verify x-payload-digest against the raw body before trusting it