An exchange API timestamp error concerns whether a signed request is timely; a signature error concerns whether its authentication matches the required request representation and key. Check the exact provider code, environment, signing machine's clock, units and serialized parameters before changing credentials. Increasing a receive window cannot repair every clock error, and neither error justifies blindly retrying an order whose outcome is unknown.
Two requests can fail with similar-looking authentication messages for entirely different reasons. One was signed with the correct secret but sat in a queue too long. The other arrived promptly but signed one JSON representation and sent another.
The distinction matters because the remedies differ. A broader time window does not repair altered bytes. A new secret does not synchronize a server clock. This diagnostic separates the two paths and gives you a compact, secret-free report for the service operating the connection.
Identify the failed check before editing settings
Keep the original provider code and message together. Binance Spot distinguishes invalid timestamp from invalid signature errors. It also has separate errors for key format and key, IP or permission problems. Treating every one as “bad API key” loses useful evidence. Binance Spot error definitions.
Record the venue, account label, product, environment, request type and observation time. A working public price request says little about signed account access. A failed order query says nothing by itself about whether an earlier order was accepted.
For a hosted application, investigate the machine that signs exchange requests. Your laptop's clock can be correct while the backend's clock, queue or serialization is wrong. Do not change your computer's time or repeatedly replace keys without evidence that either is relevant.
The connection-health guide explains how to separate public connectivity, authenticated access and account-state observations. If the failure clearly names an IP restriction, use the allowlist investigation instead of changing the signing algorithm.
A timestamp is part of an acceptance rule
A receive window is a provider-defined validity boundary, not a promise about order latency. Some APIs also reject timestamps too far in the future. The exact comparison and supported units must come from the relevant documentation.
Bybit documents a rule equivalent to server_time - recv_window <= timestamp < server_time + 1000, with millisecond timestamp and receive-window values. It recommends synchronized time. This rule is specific to that API; do not assume another venue uses the same comparison. Bybit authentication and timing.
Here is an original arithmetic illustration using a hypothetical server time of 1,000,000 milliseconds and a 5,000-millisecond window. These are simplified relative values, not a current production timestamp. Under the cited rule, the accepted range is from 995,000 inclusive to 1,001,000 exclusive.
| Request timestamp | Relationship to the fictional range | Diagnostic implication |
|---|---|---|
| 998,000 | Inside the range | The timestamp alone passes this modeled check |
| 994,800 | 200 milliseconds below the lower boundary | Investigate clock lag or request age |
| 1,001,400 | 400 milliseconds above the upper boundary | Investigate a clock that is ahead; widening the backward window does not move this upper bound |
This example illustrates why “set a very large receive window” is an incomplete fix. It can also increase how long a captured signed request remains timely under an API's rules. Use a supported value and correct the underlying clock or latency problem.
Distinguish clock offset from time spent waiting
A request can be stale even when the clock was accurate when it was signed. Consider another fictional case: a request begins only 200 milliseconds inside a 5,000-millisecond backward window. It then waits 300 milliseconds before the exchange evaluates it. Ignoring other changes, it is now 100 milliseconds beyond that boundary.
The arithmetic is 5,000 - 4,800 = 200 milliseconds of remaining validity, followed by 300 - 200 = 100 milliseconds of excess delay. Reusing the same signed request after another wait will not make it younger.
An operator should check clock synchronization on the signing system, timestamp units, time between signing and sending, network delays and any queue or retry that reuses an old timestamp. Fresh signing must still follow the exchange's rules and preserve the application's order identity and reconciliation behavior.
A server-time request can inform an offset estimate, but the round trip adds uncertainty. One observation during a slow network event is not a perfect clock measurement. Use the supported synchronization method for the client and environment, and watch whether the apparent offset remains stable across observations.
Do not intentionally alter a production clock to reproduce this example. A controlled test environment is appropriate for exercising a timing-error path. The testnet acceptance worksheet helps specify the exact behavior to verify without confusing it with production readiness.
A signature authenticates a particular representation
The signing input is not the abstract meaning of a request. It is the precise representation required by the venue: selected headers, parameters, method, path and body in a defined format, signed with the correct credential type.
Two JSON bodies can mean the same thing to a reader and contain different bytes. A client that signs compact JSON and later sends a differently spaced or reordered string can fail when the provider expects the transmitted representation. Similarly, query encoding can matter: a literal character and its encoded form are not automatically interchangeable in the signing input.
KuCoin's authentication guide specifies a prehash built from the timestamp, method, endpoint and body, followed by its required signing and header procedure. It also documents handling for query parameters and API passphrases. Follow that API's current encoding and key-version instructions rather than copying another exchange's recipe. KuCoin authentication.
An operator can compare a non-secret request template, body length, endpoint path and serialization behavior in a controlled diagnostic. Do not log the actual secret, full authorization headers or a reusable signed URL. A support ticket does not need a live request that another person might replay.
A diagnostic that changes one variable at a time
Begin with the least consequential supported request that exercises authentication, usually an account read. Use the provider or application's documented client rather than an unknown “API tester” that asks for credentials.
If the code indicates timing, inspect the signing system's time and request age. If it indicates a signature mismatch, inspect credential type, secret pairing, environment, method, parameter serialization and encoding. If it indicates account access, inspect the actual permission and IP requirements. Keep observations from each branch separate.
KLINEO's reviewed Binance client distinguishes timestamp and signature errors. Some supported account-read paths retry a timestamp failure once using exchange time. That is a narrow implementation behavior, not a guarantee that every API action will recover automatically or that an order should be resubmitted after any error.
KuCoin and BloFin also use an API passphrase, as described in KLINEO's connection policy. That API credential is not your exchange login password. Hyperliquid uses a different delegated signing model; a generic HMAC troubleshooting recipe should not be applied to its approved API wallet as though it were the same credential form.
If a secret pair was copied incorrectly, replace it through the supported flow. If it may have been exposed, use incident response and provider revocation. Do not treat a signature error as evidence that an exposed secret is harmless; a different request may still authenticate.
Avoid turning troubleshooting into a retry storm
Repeated identical failures consume time and may consume provider capacity. An authentication problem can become a second rate-limit problem if every process retries continuously. The rate-limit recovery guide explains why the combined workload matters.
Save a small diagnostic record: redacted code, first and last occurrence, request family, environment, application version, the signing-system time check and whether a supported read succeeded after correction. Explicitly mark any unknown order outcome.
For an earlier timed-out submission, the account-state question remains separate from the authentication fix. A newly successful read should be used to recover the original identified order, not to justify immediately sending another one. The exchange may already hold it even while subsequent requests fail.
The stopping condition for this investigation is a precise explanation and a repeatable supported check: the clock or representation was corrected, the intended authenticated request now works, and uncertain orders have been reconciled. “It eventually stopped erroring” is weaker evidence and leaves the next incident harder to diagnose.
Editorial method: Prepared with AI assistance on 20 October 2026 from current official authentication documentation and a source review of KLINEO's Binance and KuCoin clients. The timing examples are original constructions with independently checked arithmetic. No live credential, signed customer request or production clock change was used.