ComplyCube vs Middesk

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.

Middesk

A public OpenAPI 3.1 contract for 87 operations, llms.txt, Markdown docs and a dated weekly changelog make the REST API readable to an agent, and OAuth has a read-only scope. Access is sales-led. No price, self-serve signup or official SDK was found, and the hosted MCP server rejects sandbox keys.

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

Middesk

1. Match the key to the host. mk_test keys work only at https://api-sandbox.middesk.com/v1 and mk_live keys only at https://api.middesk.com/v1
2. Name the orders on POST /v1/businesses. Omitting them places a verification order plus every package the account runs automatically, all billed
3. Send address_line1 and address_line2. The API ignores address_line_1 without an error
4. A 201 means the business was created, not verified. Wait for the business.updated webhook or poll until status leaves pending
5. Stay under 20 requests a second per account, and in sandbox wait the seconds in Retry-After after a 429 on business creation