Sift · Rate Limits

Sift Rate Limits

Sift does not publish fixed numeric public rate limits for its REST APIs. Throughput is governed by your commercial agreement (contracted event / request volume) rather than a documented per-minute request cap. Sift's client libraries and documentation indicate that requests may be throttled under load, and clients should handle 429 (Too Many Requests) and 5xx responses with exponential backoff and retries. The synchronous Score path (Events API with return_score=true, or the Score API) is the most latency- and volume-sensitive surface and should be batched or rate-managed on the client side.

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

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

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

Tagged areas include Fraud Detection, Trust and Safety, Rate Limiting, and Quotas.

3 Limits Throttle: 429
Fraud DetectionTrust and SafetyRate LimitingQuotas

Limits

REST API Requests account
requests
not published
No fixed numeric request-rate limit is documented; governed by contract volume.
Synchronous Scoring account
requests
not published
Events API with return_score=true and the Score API are latency-sensitive; manage concurrency client-side.
Contracted Event Volume account
events
per agreement
Monthly event / transaction / user assessment volume is set by the commercial agreement.

Policies

Backoff Strategy
On 429 or 5xx responses, retry with exponential backoff and jitter, as implemented in Sift's official client libraries.
Idempotency
Events carry a client-supplied identity; resending the same event is used to correct or update prior data rather than being rejected as a duplicate.
Client-Side Throttling
High-volume ingestion should be batched and rate-managed by the client, since Sift does not publish a hard public QPS cap.

Sources