AU10TIX · Rate Limits

Au10Tix Rate Limits

AU10TIX does not publish public rate-limit values for its BOS REST API. Throughput, concurrency, and request quotas are governed by the customer's contract and provisioned capacity and are coordinated with AU10TIX during onboarding. The verification workflow is asynchronous: a session is created, media is submitted, and results are retrieved by polling the result endpoint (with retry/backoff) or via webhook callback. Specific RPM/RPS/concurrency values are not reconciled in this artifact.

Au10Tix Rate Limits is the machine-readable rate-limit profile for AU10TIX on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests and concurrent_sessions.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Identity Verification, Document Authentication, KYC, Biometrics, and Fraud Detection.

3 Limits Throttle: 429
Identity VerificationDocument AuthenticationKYCBiometricsFraud DetectionRate LimitingQuotasThrottling

Limits

Requests / Throughput account
requests
see provider documentation
Per-account throughput is contract- and capacity-governed; not publicly disclosed.
Concurrency account
concurrent_sessions
see provider documentation
Concurrent verification sessions are governed by provisioned capacity.
Result Polling session
requests
see provider documentation
Result retrieval is polled with retry/backoff (legacy BOS Maestro components documented ~3s retry up to ~30s, configurable) or delivered via webhook.

Policies

Asynchronous Workflow
Verification is asynchronous; clients create a session, then poll for a terminal result or receive a webhook callback rather than blocking on a single synchronous call.
Backoff Strategy
Clients should poll with retry/backoff and honor Retry-After on 429 responses.

Sources