Alloy vs Jumio

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.

Jumio

Five OpenAPI 3.0 files, an llms.txt index and OAuth2 clients limited to initiating or to retrieving and deleting make the API readable and containable. Access starts with an account manager, with no public price, trial or service agreement, and the status page shows four processing degradations and a 35-minute Singapore outage between 14 August and 2 October 2026.

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

Jumio

1. Use the host for the tenant's region (amer-1, emea-1 or apac-1). Tokens come from auth.<region>.jumio.ai/oauth2/token with the client ID and secret as Basic credentials
2. Reuse the bearer token for its 60 minutes. Token requests are limited to 10 a second and new transactions to 1 a second per tenant
3. Send a User-Agent header on every call. The Account API marks it required
4. Don't blindly retry POST /api/v1/accounts. Each call creates an account and a transaction, and no idempotency key exists
5. Wait for the callback or poll the status endpoint until PROCESSED before retrieving. Jumio's retry schedule starts at 40 seconds and stops after 940