Parse rate-limit response headers and calculate reset time
A limit of 100 with 42 remaining and a reset of 60 at 12:00 UTC means requests open again at 12:01, in 60 seconds. Paste the three header values and the time you received them to plan a safe retry. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Limit
- 100
- Remaining
- 42
- Reset
- 60
- Current time
- 2026-07-25T12:00:00Z
- Limit
- 100
- Remaining
- 42
- Reset kind
- seconds_offset
- Reset at unix
- 1,784,980,860
Rate-limit headers look simple until different services express reset time in different ways. This parser accepts a limit, remaining count, reset value, and explicit current time, then returns normalized numeric values and the number of whole seconds until requests become available again. It recognizes common Unix-second and Unix-millisecond timestamps, strict UTC ISO 8601 timestamps, and short numeric reset offsets.
Normalize response headers before scheduling retries
APIs commonly expose a maximum request count, a remaining count, and a reset value, but client code still has to turn those strings into a safe retry decision. The parser validates that limit and remaining are non-negative integers and rejects a remaining value larger than the stated limit. It preserves the original reset text, reports whether it interpreted that value as an absolute timestamp or a seconds offset, and produces a normalized Unix reset time.
If the reset moment is already in the past, the wait is zero rather than negative.
Understand how timestamps and offsets are distinguished
Numeric reset values are interpreted using conventions found in rate-limit response headers. Values of at least one billion are treated as Unix seconds, while values of at least one hundred billion are treated as Unix milliseconds and converted to seconds. A reset may also be a strict ISO 8601 UTC value such as 2026-07-25T12:01:00Z, with optional milliseconds.
Calendar validation catches impossible dates, invalid clock fields, missing values, negative numbers, and unrelated strings. Most importantly, an unparseable reset is returned as an invalid-input error instead of being silently replaced with zero, because an accidental immediate retry can amplify throttling and prolong an outage.
Use deterministic output in clients and automated tests
A retry policy should separate parsing from policy decisions. Use this capability to establish the quota facts, then let your application decide whether to sleep, enqueue work, reduce concurrency, or surface a message. For example, a reset offset of 60 paired with a current time at exactly noon always produces a reset timestamp one minute later and sixty seconds remaining.
The parser does not infer vendor-specific headers, perform requests, or choose exponential backoff parameters. It handles the standard values you already extracted and returns a compact result.
What you can do with it
Debug vendor throttling
Normalize captured headers and compare the reset instant with the exact time at which a response was received.
Build deterministic retry tests
Supply a fixed current time and assert stable reset calculations without mocking a system clock.
FAQ
Which reset formats are accepted?
Use non-negative seconds offsets, Unix timestamps in seconds or milliseconds, or strict ISO 8601 UTC timestamps ending in Z.
Does this tool make a request or wait for the reset?
No. It only validates and normalizes values you provide; your application remains responsible for retry and backoff policy.
What happens if the reset time has already passed?
The wait is zero, never negative. That helps when you review archived logs or late notifications, because the result tells you a retry is already possible without inventing a delay.
Why do I have to enter the current time?
So that no system clock can change the answer: the same input always gives the same result. Use the moment the response arrived, as Unix seconds, Unix milliseconds or a UTC date; it is never treated as an offset.
What if the remaining count is higher than the limit?
The input is rejected. Both values must be whole numbers of zero or more, and the remaining count cannot exceed the limit. An unreadable reset also returns an error instead of zero, to avoid an immediate retry.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/security/rate-limit-header-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/security/rate-limit-header-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/rate-limit-header-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/rate-limit-header-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/rate-limit-header-parse", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.rate_limit_header_parse",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Because the current time is supplied rather than read from a clock, the same input always produces the same result in tests, browser tools, queues, and API integrations.
Normalize response headers before scheduling retries
Paste or pass the three header values as limit, remaining, and reset, then provide current_time for the instant at which the response was received. The seconds_until_reset field is rounded upward to a whole second so a caller does not retry during the final fraction of a waiting interval.
Understand how timestamps and offsets are distinguished
Smaller non-negative numbers are seconds offsets added to current_time. This makes familiar values such as 30 or 900 behave as retry delays while contemporary epoch timestamps remain absolute. The explicit UTC suffix avoids hidden timezone assumptions. current_time accepts the same absolute Unix-second, Unix-millisecond, or UTC ISO forms, but it is never treated as an offset.
Use deterministic output in clients and automated tests
Supplying current_time is intentional: no system clock, network request, locale setting, or random value can change the answer. Absolute reset times that precede the supplied current time produce zero seconds, which is useful when processing delayed webhook deliveries or archived response logs. The browser version is free, while automated API calls use the displayed base price of $0.002 per item.
Integration use cases
Schedule a safe API retry
Convert response header strings into a whole-second delay before placing failed work back on a queue.
Technical questions
What does an API call cost?
Each item uses the base price shown as $0.002; the browser tool can run the same deterministic calculation locally.
Why must I provide current_time?
An explicit current time keeps offset calculations deterministic and makes results reproducible across clients and tests.
What happens when reset is already past?
seconds_until_reset is clamped to zero, while reset_at_unix still reports the parsed absolute reset instant.