Sort the failures before you write the loop
Retry logic depends on what the server did with the request, and the error text rarely states it. Retry a call when you know it was not processed, and pause when the outcome is unknown and the call changes data.
- Connection failures before a response are safe to retry. A DNS failure, a refused connection or a timeout while opening the socket means the request never reached the application.
- A read timeout after the bytes were sent is not safe by default. The server may have processed the call and lost the response, so a second attempt can duplicate the change.
- 429 and 503 responses are retry signals. The server answered, so the request state is known, and it is telling you to come back later.
- 400, 401, 403, 409 and 422 need a fix rather than a repeat. Sending them again produces the same answer and adds load.
Two of those failures become retryable once a prerequisite is met. A 401 caused by an expired token is safe to repeat after a refresh, and a 403 caused by a stale signature is safe to repeat after the signature is rebuilt. Repeating either with the same values spends an attempt for nothing.
Rebuild the signature for every attempt
Extracted mobile APIs usually sign the method, the path, the body and a timestamp or nonce. A signature is therefore valid for the request that produced it, and a retry that reuses stored headers sends something the server already refused or a nonce it has already seen.
- Build the signed headers inside the attempt. Read the clock, draw a fresh nonce and compute the signature in the same function that performs the send. A signature cached at the client level is the most common retry bug in this work.
- Re-sign after any edit. If a retry changes the body, a query parameter or a header inside the signed set, compute the signature again over the new values.
- Draw a new nonce per attempt. A server that tracks nonces will refuse the second request even when every other field is correct.
- Keep the timestamp inside the accepted window. A long backoff can push a rebuilt signature past the window, so refresh the timestamp as part of the rebuild rather than at the start of the flow.
Use an idempotency key where the API offers one
An idempotency key is a client-generated value that identifies a logical operation. The server records the key and the result, so a repeat with the same key returns the first result instead of performing the work twice. Mobile APIs that submit payments, orders, bookings or finished uploads often support one.
Where the endpoint accepts a key, generate it once for the operation and reuse it across every attempt. Where it does not, treat a timeout on a state-changing call as unknown, and read the server's state before sending the write again. That read is the only reliable substitute for a server-side key.
Make retries respect rate limits
Retries add traffic to a service that is already struggling. Exponential backoff with jitter spreads the attempts, and a Retry-After header, when present, is the schedule the server wants. Cap the total attempts so a persistent failure surfaces instead of looping.
Refresh handling needs its own queue. When several calls fail with an expired token at once, one refresh should run and the rest should wait for its result. Parallel refreshes can rotate a one-time refresh token several times and leave every worker holding a token the server has already retired.
Test the retry path on purpose
Point the client at a local stub that returns a timeout, a 429 and a 503 in sequence, and confirm the attempt count, the backoff timing and the rebuilt signature. Log the attempt number and the signature inputs for each try, because the difference between two attempts is what proves the client regenerates values instead of replaying them.
A client that gets this right can run unattended for weeks. SReverse builds that client in Python, JavaScript or TypeScript from the APK, with the signing, session handling and error paths covered, and delivers it as a module plus an importable Postman collection and documentation. Projects start at $120, and most are delivered in 24 to 72 hours.
Related work
Reviewed 28 September 2026 · SReverse research desk