Segment has limits on the number of requests you can issue to the Public API at one time, and calculates these limits based on:
Every successful HTTP response contains the following HTTP headers:
X-RateLimit-Consumed
: the number of requests performed during the current rate limiting window.X-RateLimit-Remaining
: the number of requests remaining in the current rate limiting window.X-RateLimit-Reset
: a timestamp, in RFC 5322 format, denoting when the limit will be reset (that is, when a new window will begin).Rate limited requests fail with the 429
status code. The failure includes a descriptive response which contains metadata about the request limits.
Field | Description |
---|---|
message |
A message that explains the rate limit error. |
data.msBeforeNext |
A number of milliseconds before the rate limit is lifted. |
data.remainingPoints |
Same as the X-RateLimit-Remaining response header. The number of requests remaining in the current rate limiting window. |
data.consumedPoints |
Same as the X-RateLimit-Consumed response header. The number of requests performed during the current rate limiting window. |
The example below shows a response that shows the remaining and consumed points.
{
"errors": [
{
"type": "RequestError",
"message": "Too many requests",
"data": {
"remainingPoints": 0,
"msBeforeNext": 57647,
"consumedPoints": 21
}
}
]
}
The most common causes for rate limits include, but are not limited to:
for
loop with a large number of elements.The Segment Public API includes generous rate limits that allow normal workflows to complete. If you receive rate limit errors, review your requests for places where you can reduce the number of individual calls, and use the best practices listed below to avoid or mitigate rate limit overages.
for
loop. If you must use for
loops, consider stopping code execution briefly using sleep
calls between items in a list.