What a 401 means on a replayed request
A 401 shows that the request arrived, that the server parsed it, and that the identity it presented was not accepted. That is a decision about credentials rather than a network problem, and it is a different answer from a 403. A 403 shows the server understood the request and refused it on other grounds, often a signature, a timestamp or a permission rule.
The distinction decides where to look first. A 401 sends you to the credential path. A 403 sends you to the signed material and the authorization rules. Mixing the two leads to editing headers that were never checked. Replay 4xx triage sets out the full decision table.
The credentials a replayed request carries
One captured request can carry more than one form of identity, and the server applies them in an order you cannot see.
- A bearer token expires on the server's schedule. A token copied from a capture stops working when its lifetime ends, and the header looks identical before and after it stops working.
- A refreshed session retires the previous token. Apps that rotate tokens on refresh leave earlier captures holding a credential the server has already invalidated, so a capture from this morning can fail this afternoon with no other change.
- A signed request carries its own proof of identity. When the signature covers a stale timestamp, the server can reject the request before it ever examines the token, which returns a 401 that has nothing to do with the token.
- Device binding ties a token to one installation. A token issued to the app is refused when the request arrives without the values the server recorded at issue time.
- Missing custom headers can surface as 401. Some servers answer a request that lacks a required header with 401 rather than 400, which makes a formatting mistake look like a login failure.
- Cookie state is easy to lose. A session cookie set during login has to be sent on every later request, and a client that drops it fails from the second call onwards.
Tell the credential failures apart
Three experiments separate the common cases, and each takes a minute.
- Replace the token with a deliberately invalid one. If the response changes from your 401, the server was checking the token. If the response stays the same, the request is failing an earlier check.
- Send the request twice with no edits. The first succeeding and the second failing points at a one-time value such as a nonce.
- Log in from the script instead of replaying a token. A freshly issued token that works proves the credential path, and it removes the token from the list of suspects.
Run the experiments in that order. Each one eliminates a mechanism rather than confirming a guess. Android API 401 and 403 replay covers the same sequence on the service side.
Rebuild the session in order
Replaying a single captured request rarely works for long, because the credential in it belongs to a session that has moved on. Reproduce the session instead: call the login endpoint, keep the token it returns, call the refresh endpoint on the same schedule the app uses, and let every later request take its credential from that state.
A session module that owns the token makes this automatic. It refreshes before expiry, retries once on a 401 with a new token, and logs enough to show whether a failure came from an expiry or from a signature. That structure also handles the case where the server rotates the refresh token on every use, which invalidates any stored copy.
Store the token in one object and hand it to the transport rather than writing it into individual calls. A single owner makes the refresh path testable, and it turns an expiry failure into a visible event instead of a request that quietly reuses a retired credential.
When the credential cannot be copied
Some tokens are useless away from the device that obtained them, because the server also checks evidence that the device produced. That case needs its own treatment, since no amount of token handling will satisfy it. Device-bound API reverse engineering describes the options, including reproducing the check rather than copying its output.
Related work
Reviewed 28 September 2026 · SReverse research desk