ComplyCube vs Plaid Identity Verification

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.

Plaid Identity Verification

Plaid Identity Verification has four typed endpoints in Plaid's public OpenAPI file, an idempotent create, a backend-only flow for data source checks and frequent changelog entries. Prices appear only after applying for Production, the secret has no scopes, and the rate-limit and error pages are disallowed to crawlers.

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

Plaid Identity Verification

1. Pass is_idempotent: true to /identity_verification/create so a retry returns the existing session
2. Use the backend-only flow (data source template, gave_consent: true) when you already hold the user's details. Documents and selfies need the person in Link
3. Wait for the STATUS_UPDATED webhook or poll /identity_verification/get. Link's onSuccess doesn't mean the user passed
4. Don't issue retries casually. Each retry is a new session billed again
5. Enable Sandbox for Identity Verification on the Dashboard Products page before the first call