API Clock Errors: How a Few Seconds of Drift Can Reject Every Order

Your key permissions are correct and the balance is sufficient, but API orders keep getting rejected. The error includes timestamp or recvWindow. The cause may be neither an exchange outage nor the key: your computer clock differs from the exchange clock by a few seconds.

The Exchange Asks When Each Request Was Created

API orders carry signatures. A signature alone seems sufficient, but it can be copied and sent again. If someone intercepts your request and replays it an hour later, the same order could be submitted again. Exchanges therefore require a creation time and accept the request only when it is close to the current time.

The second condition is crucial. A slow clock reduces remaining window capacity, but a fast clock describes a request created at a time that has not yet arrived. It is rejected regardless of window width. Just a few seconds can therefore block 100% of orders.

What a Three-Second Difference Does

Assume an exchange defaults to recvWindow = 5,000ms, or five seconds.

A slow clock produces the more confusing symptom of sometimes working and sometimes failing.

Latency rises when trading activity surges. A narrow allowance therefore causes failures specifically during sharp moves. Quiet-period logs look normal, making the cause harder to identify afterward.

Four Ways Clocks Drift

You might expect Windows to keep time automatically, but synchronization is less frequent than it may seem.

The fourth case is especially troublesome. Failed synchronization does not necessarily show a warning. Drift grows over days until it crosses the window and orders suddenly stop. Since no code changed that day, investigation often looks in the wrong place.

Network Delay Uses the Same Budget

recvWindow is not reserved solely for clock error. The time taken to reach the server consumes the same allowance.

Moving working code from a domestic server to an overseas host, or switching from wired to wireless networking, can therefore suddenly trigger rejections. Queues associated with rate-limit errors, HTTP 429, consume the allowance even faster.

Diagnose It by Querying Server Time

Measure the offset instead of guessing. Most exchanges provide an unauthenticated server-time endpoint.

If the difference is within a few hundred milliseconds, investigate other causes: API-key permissions, IP allowlists, or other order-rejection reasons. If the discrepancy measures whole seconds, the clock is the likely cause.

Fix the OS Clock First, Then Add Offset Correction

There are two layers. Addressing only one allows recurrence.

A common mistake is omitting periodic remeasurement. An offset measured at startup becomes stale when a program runs for days. Even with correction, synchronize the OS clock: inaccurate fill and log timestamps make later position reconciliation or P&L verification ambiguous.

Simply Increasing recvWindow Does Not Resolve the Cause

The easiest response is widening the window. Rejections may disappear, but only the symptom has gone.

A market entry delivered 20 seconds late has an uncertain fill price. Its cost resembles slippage. The window is a safeguard for discarding stale requests, not a tool for hiding clock drift, so avoid increasing it far beyond the default.

A More Dangerous Case: The Order Arrived, but Its Response Did Not

Immediate retry logic after an error can, depending on the circumstances, submit the same order twice.

Exchanges commonly accept client-specified order IDs and reject duplicates using the same ID. Include one when implementing retries. A local failure and a successful order whose response was lost may be indistinguishable locally; querying before retrying resolves that uncertainty. Partial fills complicate quantity reconciliation further.

Bot Checks

For automated trading, implement the following checks as standard behavior.

An error code alone is insufficient for reconstructing the cause later. Once the clock is corrected, this kind of fault leaves no visible trace unless the offset was logged.

Key Points

Time is part of API authentication, not optional metadata. If the code looks correct but orders fail, measuring the clock before inspecting more code may be faster.

Notice

The recvWindow values, latencies, offsets, and quantities are hypothetical examples, not measurements from a particular exchange. Default and maximum windows, server-time endpoints, and support and validity periods for client order IDs vary by exchange. Check your exchange's documentation and test with small amounts. Leveraged trading can lose all principal. Investment decisions and their consequences are your responsibility.