API header reference
RateLimit-Limit, Remaining, and Reset: calculate a safe request pace
Interpret standardized and X-RateLimit API response headers, epoch resets, delta resets, multi-window policies, and inconsistent provider implementations.
Limit is capacity, Remaining is the current budget, and Reset describes the time boundary—but provider dialects differ. Some X-RateLimit-Reset fields are Unix epoch seconds while newer RateLimit policies can express relative timing and multiple windows. Parse the named dialect before doing arithmetic.
Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.
Diagnostic procedure
Work from evidence to recovery.
- 01
Identify the dialect
Check provider documentation and header prefix before deciding whether reset is an epoch timestamp or delta-seconds.
- 02
Calculate a conservative pace
Spread remaining capacity over the remaining window and reserve headroom for concurrent workers and clock skew.
- 03
Coordinate callers
A per-process counter is insufficient when multiple instances share the same account or token limit.
remaining=60, reset=30 → send 60 requests now
safe baseline ≈ 60 / 30 = 2 req/s, then subtract shared-worker headroom
- 100
- window limit
- 0
- remaining
- 17s
- Retry-After
- 0
- safe req/s
Precedence Honor Retry-After when supplied. Treat reset and remaining fields as pacing evidence, not permission to burst.
Clock form X-RateLimit-Reset is often epoch seconds; the standardized RateLimit-Reset field may represent delta-seconds depending on the provider implementation.
No account · no upload · no endpoint calledOpen the full rate-limit analyzer and operating notes →
FAQ
Before you ship
Does APITC send this evidence to an API?
No. The matching and calculations in the linked workbench run in the active browser tab.
Should every rate limit response be retried?
No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.
Protocol behavior checked against the GitHub REST API rate limit headers. Recheck your pinned provider/API version before production deployment.