Data egress API rate limits

Relativity applies rate limits and data egress controls across select APIs to keep the platform reliable, performant, and secure for every customer. These controls promote consistent performance and fair access to shared resources. The table below defines the enforced limits for each API as they relate to data egress.

API	Rate Limit
Object Manager API: StreamLongText Endpoint	0.5 GB / tenant / rolling 24 hours

Note the following considerations regarding the rate limits:

• This is a per-tenant limit, measured in aggregate across all third-party API traffic. Every third-party application (including RAPs), integration, and service account in the tenant shares one 0.5 GB rolling 24-hour allowance, therefore requests spread across multiple applications or credentials all count toward the same total.
• Regarding the rolling window: there is no fixed reset time. The quota recovers gradually as older usage ages out of the 24-hour window. The Retry-After header on a 429 tells you exactly how many seconds until enough prior usage has aged out for your request to be accepted - you don't need to guess.
• For the Object Manager API, the GB ceiling is in addition to, and separate from, the existing Object Manager concurrency rate limit which continues to apply to all calls including to the StreamLongText endpoint.

Exceeding the limit

When a tenant reaches its egress allowance, the API returns HTTP 429 (Too Many Requests) for further requests in that tenant. Requests succeed again once earlier usage ages out of the rolling 24-hour window and the tenant returns under the limit.

Rate limit response headers

Rate-limited APIs return response headers that consuming applications can use to implement proactive throttling, rather than reacting to HTTP 429 errors. The headers returned depend on whether the request succeeded or was rejected. On an HTTP 429 (rate-limited) response, the following headers are included:

Response Header	Description
Retry-After	Seconds to wait before retrying. The value is the earliest point at which enough usage has aged out of the rolling window for the request to be accepted.
X-RateLimit-Reason	Machine-readable reason code for the rejection. For egress quota exhaustion this is always bytes_per_day.

HTTP status codes

HTTP Code	Status	Meaning
200	OK	Request succeeded. For third-party callers, egress byte usage has been recorded against the tenant's rolling 24-hour quota.
429	Too Many Requests	The tenant's rolling 24-hour egress byte quota has been exhausted, or the existing concurrency rate limit has been reached. The response includes a Retry-After header with the number of seconds to wait. For egress quota rejections, the response body is: {"message": "API rate limit exceeded. Reason: Daily egress bytes."} and the X-RateLimit-Reason: bytes_per_day header is present. For concurrency rate limit rejections, the body is: {"message": "API rate limit exceeded."} with no X-RateLimit-Reason header. A request that completes while the tenant is near the limit will still receive its full response. The quota is charged after the stream finishes, so the 429 applies to the next request that arrives after the limit is exceeded

Handling rate limit errors

On receiving a 429, read the Retry-After value and wait that many seconds before retrying. Do not retry immediately as the limit is enforced at the tenant level, and retries from any application in the tenant will continue to receive 429 until the window clears.