Shufti vs Sumsub

Shufti

One endpoint covers document, face, address, AML and KYB checks, with a free plan of 10 verifications a month, and a hosted MCP server adds OAuth with three scopes. No OpenAPI file, server SDK or idempotency key was found, and the status page history could not be read.

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.

Shufti

1. POST every verification to https://api.shuftipro.com/ with a unique reference of 6 to 250 characters and one object per service. Read results from /status with that reference
2. Register the callback domain in the back office first. An unregistered callback_url is rejected
3. Stay under 60 requests a minute per IP on a production account and 20 on a trial account
4. Check the Signature response header. Accounts created after 15 March 2023 hash the Secret Key with SHA-256 before appending it to the raw response
5. Through MCP, identity checks return a verification_url for the person to open. No tool accepts an image, so use the REST API for offsite proofs

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