Alloy vs Veriff

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.

Veriff

Per-verification prices are public from $0.80, with a 15-day trial of 50 sessions and no card. Each endpoint page is Markdown with an OpenAPI 3.0 fragment. There is no server SDK, MCP server or idempotency key, most calls need an HMAC signature, and the status page shows nine incidents between 20 July and 7 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

Veriff

1. Take the base URL from the integration's API keys page. Send X-AUTH-CLIENT on every call and store verification.id from POST /v1/sessions
2. Sign POST and PATCH bodies, and the session ID on GET and DELETE, with HMAC-SHA256 in X-HMAC-SIGNATURE. POST /v1/sessions needs no signature
3. Stay under 30 session creations a minute on Self-Serve, 600 on Enterprise. A 429 carries code 1004
4. Don't blindly retry POST /v1/sessions. Each call makes a new session, which is billed on a live integration
5. Poll GET /v1/sessions/{id}/decision until verification is not null, or accept webhooks within 5 seconds and treat duplicates as normal