ComplyCube vs Jumio

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.

Jumio

Five OpenAPI 3.0 files, an llms.txt index and OAuth2 clients limited to initiating or to retrieving and deleting make the API readable and containable. Access starts with an account manager, with no public price, trial or service agreement, and the status page shows four processing degradations and a 35-minute Singapore outage between 14 August and 2 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

Jumio

1. Use the host for the tenant's region (amer-1, emea-1 or apac-1). Tokens come from auth.<region>.jumio.ai/oauth2/token with the client ID and secret as Basic credentials
2. Reuse the bearer token for its 60 minutes. Token requests are limited to 10 a second and new transactions to 1 a second per tenant
3. Send a User-Agent header on every call. The Account API marks it required
4. Don't blindly retry POST /api/v1/accounts. Each call creates an account and a transaction, and no idempotency key exists
5. Wait for the callback or poll the status endpoint until PROCESSED before retrieving. Jumio's retry schedule starts at 40 seconds and stops after 940