Alloy vs ComplyCube

Alloy

Alloy's public docs cover journeys, evaluations, entities, documents, cases and investigations, with llms.txt, Markdown pages, OpenAPI fragments and rate-limit headers with retry-after. Access is sales-led with no public price or trial, credentials have no scopes, there is no idempotency key or server SDK, and inputs vary by each customer's workflow.

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.

Alloy

1. Get the account's base URL from the customer. Defaults are api.alloy.co and sandbox.alloy.co, and some accounts have their own hosts
2. Use unique, prefixed external IDs in sandbox. Sandbox and Production share one data store
3. Read alloy-ratelimit-remaining, and on 429 or 5xx wait for retry-after with exponential backoff and jitter
4. Expect running after about 25 seconds on journey applications and wait for the webhook instead of resubmitting
5. Send the workflow header with account-level keys, since inputs depend on the workflow configured

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