API Rate Limits, Retries and Duplicate Order Prevention

Understand the limits before sending requests

Broker APIs may limit how frequently an application can request quotes, positions or order actions. Limits can apply per second, user, endpoint or account, and the broker can update them. Read the current official documentation and design around the stated constraints instead of discovering them during active trading. Separate essential order and risk checks from optional refreshes, and avoid polling aggressively when an event stream or slower refresh is sufficient. If several tools share the same account, their combined activity may contribute to a limit. Keep track of request volume and learn how the API signals throttling so the application can respond deliberately.

A timeout does not mean an order failed

Network timeouts create ambiguity: the request may have failed before reaching the broker, or the broker may have processed it while the response was lost. Automatically repeating every timed-out order can create duplicate exposure. Before retrying an action with financial consequences, query the broker using the documented order status or order book process and reconcile the account. Use client-generated identifiers or idempotency features only if the broker officially supports them. Never invent a retry mechanism based on an assumed API behavior. For read-only requests, a bounded retry may be reasonable; for order actions, require a status check and clear state transition.

Use bounded backoff and circuit breakers

When an API reports throttling or temporary unavailability, repeated requests at the same interval can make the problem worse. A bounded backoff increases the pause between attempts and caps the number of retries. A circuit breaker pauses repeated calls after a defined pattern of failures and alerts the operator. The exact values should follow broker guidance and the application’s needs; there is no universal safe timing for all endpoints. Keep the user informed when automated actions are paused. Do not let a retry loop silently continue while prices or positions are stale. Backoff is a reliability technique, not a substitute for validating account state.

Review the failure path before production

Create a test checklist for rate-limit responses, connection drops, late acknowledgements, application restarts and broker maintenance. For each case, define whether the strategy pauses, what data must be reconciled, who receives an alert and what the operator does next. Store timestamps and safe request identifiers so events can be diagnosed later. Confirm the terminal does not create a second order simply because it did not receive the first response. After recovery, verify positions and open orders through broker records. These practices help make integration behavior more predictable, but they cannot prevent all outages, slippage or market losses.