Rate Limit

Overview

All Public API traffic passes through two layers of traffic control before reaching the backend. Each layer protects against a different class of overload, and both are scoped per API key — meaning one client's excess traffic is isolated at the gateway and never impacts other clients.

Client ──▶ Inflight Control (Layer 1) ──▶ Rate Limit (Layer 2) ──▶ Backend

A request must pass both layers sequentially. If it fails either check, it is rejected immediately with HTTP 429 Too Many Requests.

For GraphQL APIs, a query complexity limit is also enforced on top of the per-key rate limit. This prevents individual queries from consuming disproportionate backend resources regardless of request volume.

---

Layer 1 — Inflight Concurrency Control

What it does

This layer caps the number of concurrent requests a single API key can have in flight at any given time. Unlike a simple rate limit, it detects situations where a client stays within the requests-per-second cap but accumulates many simultaneous long-running requests — a pattern that can saturate backend capacity without ever triggering a throughput limit.

Current limits

Note: Concurrency limits may be adjusted or endpoint-specific ceilings may be introduced in the future. Affected clients will be notified prior to any changes.

Request TTL

Each in-flight request slot has a 600-second TTL. If a request's response is never received (e.g., due to a dropped connection), the slot is automatically released after 600 seconds to prevent counter leaks.

Rejection

Requests that exceed the concurrency limit are rejected with HTTP 429 Too Many Requests.

---

Layer 2 — Throughput Rate Limit

What it does

This layer enforces a requests-per-second cap at the API gateway. It prevents burst traffic and runaway scripts from overwhelming the system.

Current limits

Trial API keys expire after 90 days.

Rejection

Requests that exceed the rate limit are rejected with HTTP 429 Too Many Requests.

---

Handling 429 Responses

When your client receives a 429 Too Many Requests response:

1. Implement exponential backoff — do not retry immediately. Use a backoff strategy with jitter to avoid thundering-herd effects.

2. Reduce concurrency for long-running operations — if you are calling endpoints that take several seconds to respond (e.g., order creation, bulk entity operations), limit the number of parallel requests your client sends. Staying within the requests-per-second limit does not guarantee your requests will succeed if concurrency is too high.

---

Best Practices

• Prefer sequential or lightly-parallelized calls for heavy endpoints (order creation, profile lookups, contact operations). These endpoints have longer response times and tighter concurrency ceilings.
• Prefer batch APIs — when a batch endpoint is available, use it instead of making many individual requests. This reduces the number of concurrent connections and avoids hitting both rate and concurrency limits.
• Respect both dimensions — staying under 30 req/s is necessary but not sufficient. If your requests take 10 seconds each, sending 10 req/s means 100 concurrent requests to the backend. The inflight control layer will reject excess concurrency even if your throughput is within limits.