ComplyCube vs Entrust Identity Verification (formerly Onfido)

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.

Entrust Identity Verification (formerly Onfido)

The v3.6 API has a public MIT OpenAPI file, server libraries in five languages, OAuth client credentials with scopes and an 18-month deprecation notice. Entrust's own site answered 403, so terms, privacy notice, pricing and security.txt weren't read. There is no idempotency key, and live tokens need a Dashboard account with billing details.

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

Entrust Identity Verification (formerly Onfido)

1. Use the regional host for the account (api.eu, api.us or api.ca.onfido.com/v3.6). v3.6 has no default region
2. Prefer an OAuth client with only the scopes the task needs over a live API token, and refresh the 60-minute access token
3. Stay under 400 requests a minute live and 120 in sandbox, and back off on a 429 rate_limit error
4. Check before retrying a POST. There is no idempotency key, so a retry can create a second applicant or check
5. Treat webhook events as duplicates or out of order, and verify X-SHA2-Signature over the raw body