API rate limiting

Most api.telnyx.com endpoints enforce rate limits. Limits and scopes can differ by product and operation and can change as service capacity changes. Treat response headers and product documentation as authoritative rather than hard-coding a global request rate.

Rate-limit headers

When present, these headers describe the current request window:

Header	Meaning
`x-ratelimit-limit`	Applicable request limit for the current window.
`x-ratelimit-remaining`	Requests remaining in the current window.
`x-ratelimit-reset`	Reset timing signal. The representation and interpretation are product-specific.
`retry-after`	Delay before another attempt, when supplied.

Header availability and semantics can vary by endpoint. A missing header is not evidence that an endpoint has no limit. Follow the selected product’s documentation before interpreting x-ratelimit-reset as either a duration or a timestamp.

429 response

A throttled REST request returns HTTP 429 Too Many Requests:

{
  "errors": [
    {
      "code": "10011",
      "title": "Too many requests",
      "detail": "You have exceeded the maximum number of allowed requests."
    }
  ]
}

Recover safely

Stop issuing requests in the affected scope.
Honor Retry-After when present; otherwise use the documented reset signal or bounded exponential backoff with jitter.
Retry only when the original operation is safe to repeat.
Reduce concurrency and cache safe read results where appropriate.
Bound attempts and total elapsed retry time.

Do not distribute traffic across API keys to bypass a product limit. Contact Telnyx Support when normal operation consistently exceeds documented capacity.

Product-specific limits

Other products publish limits in their product guides or endpoint descriptions. Do not infer Messaging limits for Voice, Storage, Wireless, or other APIs.

​Rate-limit headers

​429 response

​Recover safely

​Product-specific limits

​Related

Rate-limit headers

429 response

Recover safely

Product-specific limits

Related