Skip to main content
Help API Security
API Security

Understanding Rate-Limit Response Headers

2 min read·2 views·100% found this helpful

G8KEPR API responses include headers that tell you how much of your rate limit remains and, if you've been throttled, how long to wait. Read them on every response and your integration will back off smoothly instead of hammering a limit.

The headers at a glance

  • `X-RateLimit-Limit` — the maximum number of requests allowed in the current window.
  • `X-RateLimit-Remaining` — requests you have left in the current window. When this hits 0, further calls are rejected until the window resets.
  • `X-RateLimit-Reset` — a Unix timestamp (seconds since epoch, UTC) marking when the window resets and Remaining returns to Limit.
  • `Retry-After` — sent only on a 429 Too Many Requests response. The number of seconds to wait before retrying.

A successful response looks like this:

bash
HTTP/1.1 200 OK
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 573
X-RateLimit-Reset: 1753372800

What happens when you hit the limit

Once X-RateLimit-Remaining reaches 0, the next request returns 429 with a Retry-After header:

bash
HTTP/1.1 429 Too Many Requests
Retry-After: 42
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1753372842

Always prefer Retry-After when it's present — it's the authoritative wait time. Fall back to computing X-RateLimit-Reset − now only if Retry-After is missing.

How to back off correctly

  1. 1.On every response, read X-RateLimit-Remaining. If it's low, slow your request rate before you're throttled.
  2. 2.On a 429, do not retry immediately. Read Retry-After and pause for that many seconds.
  3. 3.If Retry-After is absent, sleep until X-RateLimit-Reset, then retry.
  4. 4.Add a small random jitter (for example, 0–1s) to your wait so concurrent clients don't retry in lockstep.
json
{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Retry after the period indicated by Retry-After."
}

Retrying before the window resets wastes quota and can extend how long you stay throttled. Honor the wait every time.

Best practices

  • Treat any 429 as a signal to slow down, not as a hard failure — it's safe to retry after waiting.
  • Cache responses and batch calls where possible to stay well under X-RateLimit-Limit.
  • Reset timestamps are UTC; convert with your language's standard epoch utilities.

Need higher throughput? See Managing API keys and scopes or contact our team about a plan with a larger limit.

Was this helpful?Still stuck? Submit a request →

Related articles