The window is the shortest of several limits
A request carries several values with their own lifetimes, and the server stops accepting the request as soon as any one of them is no longer usable. The replay window is the smallest of those limits, which is why it is usually shorter than any single field suggests.
- A stated expiry. The request carries a time by which it must be received, so the window is written into the request itself and visible in the capture.
- A freshness tolerance. The request carries a timestamp with no expiry beside it, and the server accepts it only when its own clock is within a tolerance of that value. The window is the tolerance plus whatever clock skew the server allows.
- A session or access token lifetime. The value may be valid for minutes or for weeks, and it sets a ceiling on everything signed with it.
- A nonce retention period. The server remembers used values for a while and refuses a repeat during that period, so the value is single-use even though it has no expiry.
- Server policy. Rate limits, device binding and account state can end the window earlier than any timestamp does, without appearing anywhere in the request.
None of those limits is announced in the response. The only way to learn the effective window is to measure how the endpoint behaves over time.
Measuring the window empirically
The measurement is a controlled resend. Capture a request that succeeds, then send that exact byte sequence again at intervals and record the status and the body each time. The window sits between the last interval that passed and the first that failed.
A few details decide whether the measurement means anything. Use a fresh capture for each run, because a capture that has already been sent may have consumed a single-use value. Send nothing else against the endpoint between attempts, so a rate limit does not end the run early. Record the server's own clock where the response exposes it, since a Date header or a server timestamp shows which clock the tolerance is measured against. Repeat the run on a second capture before trusting the boundary, because a failure at the edge and a failure in the middle mean different things.
Intervals do not need to be fine. A few attempts spread over the plausible range, from seconds to hours, locate the boundary well enough for a client, and the precise boundary matters less than the order of magnitude.
Expiring values and single-use values
The failure pattern separates the two, and the distinction decides how much of the request a client has to generate.
An expiring value stays valid until its time is up and works every time inside that period. Send the identical request twice in quick succession and both attempts succeed, then the same request fails later with no other change.
A single-use value works once and is refused afterwards regardless of the clock. Send the identical request twice in quick succession and the first succeeds while the second fails, sometimes with the same status code and sometimes with a different message that names a repeated value. A short delay changes nothing in that pattern, which is what separates it from the expiring case.
Some schemes enforce both at once, and there the single-use rule dominates, because a window of zero is shorter than any tolerance. That is also the case that wastes the most time if it is misdiagnosed, since the obvious test of waiting and retrying produces a failure that looks like an expiry.
What this means for building a client
A capture is one request at one moment, so a client built on stored values inherits the window and stops when it closes. A client that runs on a schedule needs the values regenerated per request, and the measurement above says which ones those are.
- The generated values have to be reproduced per call. Timestamps, nonces, request identifiers and signatures are computed fresh, which means recovering the routine that produces them rather than copying its output.
- Session state has to be maintained. Where the window is really a token lifetime, the client needs the call that renews the token and the point in the flow where it is renewed.
- Repeated or parallel calls need distinct values. A nonce that works once forces the client to hold a counter or a pool and to avoid reusing a value across two requests.
- Clock handling has to match the server. A client that generates timestamps from a drifting clock produces values outside the tolerance while the code itself is correct.
The end state is a client that can make the call at any time, which is the difference between a reproduced request and a reproduced API. Measuring the window is the first step, because it tells you which values are worth the effort of recovering and which are stable enough to compute once.
Verification follows the same logic. Compare a live request from the client with a live request from the app on the same account and the same inputs, sent close together. If the app succeeds at the same moment, the values the client generated are the values the server expected, and the window is no longer part of the problem.
Related work
Reviewed 28 September 2026 · SReverse research desk