Skip to main content
Work through the list in order. Each item says where to check it.

​
Access

  • Your workspace is enabled for the partner KYC API. In Settings, API Keys, the new-key form lists the kyc: scopes. If it says the workspace is not enabled, request sandbox access: it is switched on per workspace by Sahl.
  • One key per system, with the least scopes. A server that only verifies needs kyc:verify. Only kyc:extract spends reads.
  • Keys live in a secret manager on your server. No key in a browser, a mobile app or a repository. See Authentication.
  • You rotated a key once in sandbox. Rotate with a grace period, deploy the successor, confirm the old key returns 401 API key expired after the grace period.
  • Test keys are revoked. Keys you pasted into the playground or Postman for testing are revoked in the key list.
  • Optional: keys are bound to your Google service account. Then every call sends X-Partner-Identity.

​
Policy

  • A KYC policy exists for production if you want rules other than the default. The policy is saved per client kind and per environment, so the sandbox policy does not carry over. Review it in Settings, KYC policy: thresholds, required documents, locked items.
  • You know which switches are locked. Send a call with screen: false in sandbox and read policy.overrides_refused in the answer.
  • Your regime preset is what you expect. The policy.source and policy.regime in an answer tell you which policy ran.

​
Integration

  • Every call carries a stable reference. 1 to 64 characters of A-Z a-z 0-9 _ . : -, one per client, the same across /extract, /verify, /assess and /eid. Without it nothing is filed on your workspace and no webhook is sent.
  • You send documents[] entries back unchanged. See How the calls fit together.
  • You branch on critical_failures and flags, not only on passed. A file with warnings still has passed: true.
  • You match checks by id, not by label.
  • You handle reader_unavailable: true. Retry later and do not treat it as a blank document.
  • You handle all three error shapes, including a 422 whose detail is a list. See Errors.
  • You do not retry 4xx (except a rate-limit 429 with Retry-After), and you retry 5xx with a capped backoff. There is no idempotency key. See Retries.
  • You log X-Request-ID from each response and can find the call in Developers, Call log.

​
Limits

  • You know your monthly read allowance (2,000 by default) and you handle 429 kyc_extract_cap_reached. Sandbox reads count against it too.
  • Your servers stay under 100 requests a minute per client IP. Servers behind one address share the limit.
  • Your upload step enforces the file rules before sending: 1 to 5 files, JPEG, PNG, WebP, TIFF or PDF, 30 MB each by default.

​
Webhooks, if you use them

  • The endpoint is https and public. Add it in Settings, Webhooks and press Test.
  • You verify X-Sahl-Signature-V2 on the raw body and reject old timestamps. See Webhooks.
  • Your handler is idempotent on X-Sahl-Delivery or event_id, and answers 2xx quickly.

​
eID, if you use it

  • Your workspace has an eID provider account. Without it, POST /v1/kyc/eid returns 404.
  • Your clients are Canadian. Other countries get 422.
  • You use the same reference and environment for /eid and the later /verify.
  • You poll the check to the end and store the PDF within about seven days.

​
Console

  • Your staff can see production data. The console shows production cases and documents on every plan. The Free plan includes 10 Production cases a month and needs a verified work email (not Gmail or Yahoo); Starter and above get their plan quota. Sandbox is unlimited on every plan.
  • You sent a first production call with a fake client and found its case in Cases with environment production.
  • Real documents go to production only. Use fake data in sandbox.

​
Not on this list

Sahl does not publish an uptime figure, a support response time, a latency figure, or a certification claim in this documentation. Ask Sahl for those in writing.