Alloy vs Sumsub

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.

Sumsub

Per-token permissions, an IP allowlist, HMAC-signed requests and a public OpenAPI spec with Markdown docs suit an agent working on verification cases. No idempotency keys or Retry-After guidance were found, there is no server SDK, and production access needs a browser signup, a bank card and Sumsub's review of the integration.

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

Sumsub

1. Sign every request. X-App-Access-Sig is the lowercase hex HMAC-SHA256 of timestamp, uppercase method, path with query and raw body, and the timestamp must be within one minute of server time
2. Use a sandbox token (prefix sbx) for agent work. Sandbox and production tokens are separate, and Sumsub's own skills refuse any other prefix
3. Stay under 300 GET and 50 POST requests per 5 seconds, and under 500 new applicants per 24 hours in Sandbox
4. Token permissions can't be edited after creation. Generate a new token with the narrower set and delete the old one
5. Subscribe to the applicantReviewed webhook for results and verify x-payload-digest against the raw body before trusting it