Broker API rate limits need controls for risk and compliance

At the end of a bad week, an operations lead is looking at a dashboard full of 429 responses, rising order queues and retries that have outlived the market event that triggered them. The API has stayed up.

Some client actions have not reached it promptly, while others have been submitted more than once. The incident review needs to explain not just the outage, but who was affected and why.

Rate limits are often treated as a vendor constraint or a capacity problem. For a broker or prop firm, they are also part of order handling, client fairness and operational control.

A retry policy can amplify a provider slowdown. A queue can protect a shared connection, but delay a cancellation. A dashboard can show the average response time while hiding a small group of accounts stuck behind a noisy neighbour.

The control objective is not to eliminate throttling. It is to keep demand inside known limits, handle excess work predictably and retain evidence of decisions made during pressure.

Define the limit before designing around it

A rate limit may apply per API key, account, user, IP address, connection, endpoint or a combination of these. Read requests and order actions may have separate budgets.

A provider may also enforce a rolling window, a fixed interval, a burst allowance or a concurrent-request cap. Treating all of these as one number leads to inaccurate capacity planning.

Ask the provider which limits are hard, which are shared across sub-accounts, and whether rejected calls count towards the quota. Confirm how limits reset and whether responses include a retry-after value or remaining-capacity headers.

These details affect the client's behaviour at the boundary. A 429 normally signals throttling, while a 5xx response can indicate service failure, but neither response alone tells the caller whether an order was accepted before the connection failed.

Typical market ranges are useful for sizing a first test, not as a substitute for a contract or a provider's current documentation. The figures below are broad operating examples across broker APIs. Actual limits vary by venue, account tier, endpoint and infrastructure arrangement.

Separate limits from your own service objectives. A broker may permit a certain request rate, but your platform may set a lower internal budget to leave room for bursts, recovery and other consumers. That budget should be explicit, versioned and reviewed when account structure or provider terms change.

Make retries bounded, informed and safe

Uncoordinated retries turn a slowdown into a traffic surge. If hundreds of workers retry on the same fixed interval, they can arrive together as the provider recovers.

Use exponential backoff with random jitter, respect retry-after instructions, and cap both the delay and the number of attempts. For example, an initial delay of 100-250 milliseconds, doubling on each retry and capped around 2-5 seconds, is a starting point for many non-urgent calls. It is not suitable for every order path or provider.

Before retrying an order submission, establish whether the first attempt was accepted. A client timeout is ambiguous: the broker may have received and processed the request even though the response was lost. Use provider-supported idempotency keys where available, or reconcile by client order ID and status before resubmission.

Without that check, a retry can create a second live order. A backoff algorithm cannot solve an uncertain execution state. A practical retry policy should make these decisions in order:

1. Classify the response. Treat throttling, connection failure, validation rejection and server error as separate cases. Do not retry a deterministic rejection as if it were transient.
2. Check order state. For an ambiguous submit, query or reconcile status before attempting another submission. Keep the original client order ID where the provider's rules allow it.
3. Apply the shared budget. Reduce or pause low-priority calls when the account or connection is close to its limit. Per-worker backoff alone does not coordinate a fleet.
4. Set an expiry. Stop retrying when the request is no longer useful, and route unresolved order state to an operator or recovery process.
5. Record each decision. Store the response class, attempt count, delay, order identifier and final outcome for later review.

Different request types need different retry rules. A market-data refresh can often be skipped and replaced by the next update. An order-status query may be safe to repeat, subject to the provider's limits.

A submit or amend may need reconciliation first. A cancel should be retried only with an understanding of whether the order remains live and whether repeated cancellation requests are permitted.

Backoff controls traffic. Reconciliation controls order uncertainty.

Use queues to preserve capacity and fairness

A central token-bucket limiter is often a practical way to enforce a known rate while allowing a controlled burst. Set the refill rate below the provider's stated maximum and cap the bucket size so a reconnect or batch job cannot release an excessive burst. Where limits are per account, enforce budgets at that scope as well as at the shared connection or API-key scope.

Queues add control, but they also add delay and ordering risk. A single FIFO queue is simple, yet it lets market-data polling or routine amendments hold up an urgent cancellation. Separate work by function and priority, then apply per-account fairness so one strategy cannot occupy the full shared budget. Priority must be documented and tested. It should not become an informal mechanism for favouring a client or desk.

Common controls include:

• Reserve a defined share of request capacity for order actions, status reconciliation and risk-reducing operations.
• Apply per-account and per-strategy ceilings beneath the provider-wide limit, with a fair-share policy for unused capacity.
• Give queued work a maximum age. Drop expired market-data refreshes; escalate order actions that cannot safely be discarded.
• Keep order sequencing intact where the strategy or provider requires it. Do not reorder an amend and cancel simply because one has a higher queue priority.
• Use a circuit breaker when errors or throttles persist. Pause non-essential traffic, expose the degraded state and allow controlled recovery rather than releasing the whole backlog at once.

Trade-offs should be visible to operations. A reserved cancellation budget can leave some capacity idle during quiet periods, but can reduce the chance that routine reads crowd out risk-reducing actions during a burst.

Strict per-account caps protect fairness, but can constrain a client with a legitimate short-lived spike. Any exception should be time-limited, authorised and logged, rather than implemented by raising a global limit.

Test queue behaviour under load, including a full queue, a slow provider, a reconnect and a burst from one account. Measure queue age by action type, not just total depth. A queue of 1,000 market-data refreshes may be harmless; a queue of 20 order cancels may require immediate intervention.

Connect throttling to conduct and compliance controls

Rate-limit handling can change the service a client receives. If one account's retries consume a shared budget, other accounts may see slower order acknowledgement or status updates. If a firm silently prioritises one desk, its policy may have conduct and governance implications. The engineering design should therefore state how capacity is allocated, which actions take priority and how exceptions are approved.

Keep an event record that can reconstruct the sequence around a disputed or delayed order. Useful fields include:

• Account, strategy, API key and endpoint, with credentials masked.
• Request type, client order ID, correlation ID and submission timestamp.
• Provider response code, response headers relevant to throttling and whether acceptance was confirmed.
• Queue entry and exit times, assigned priority, retry count and chosen delay.
• Order-state checks, operator intervention, exception approval and final outcome.

Retain records under the firm's existing data-retention and access-control policies. Avoid logging secrets or unnecessary personal data. Make sure incident tooling can join application events to provider status and internal order records without relying on a single service's local clock.

Compliance and operations teams should agree what counts as a material delay for each action type and what escalation follows. The threshold can depend on product, market session and order state.

A delayed quote refresh and a delayed cancellation are not equivalent. Document the rationale, test it in incident exercises and review exceptions for repeated use.

Trading Technology's coverage of trading infrastructure can help teams track how platform and provider changes affect operational dependencies. The control design itself should remain grounded in the firm's own flow mapping, provider terms and documented risk appetite.

Monitor the failure mode, not only the API

A green availability check does not mean order handling is healthy. Monitor throttled responses alongside request volume, retry amplification, queue age, order acknowledgement latency and unresolved order state. Break the measures down by account, endpoint and action type. An aggregate success rate can conceal a concentrated impact on a small client group or one critical workflow.

As initial alerting thresholds, teams might investigate a sustained 429 rate above 1% for five minutes, a retry-to-original-request ratio above 1.5, or an order-action queue older than 500 milliseconds. These are starting points, not universal standards. Tune them to normal volume, provider behaviour and the service objectives for each product. For a low-volume API, a single throttle may matter more than a percentage threshold.

Exercise the controls with realistic failure scenarios. Inject 429 responses with and without retry-after headers. Simulate timeouts after a request may have reached the broker.

Test whether a circuit breaker recovers gradually, whether queues shed expired work and whether operators can identify accounts affected by the incident. Review the runbook after provider limit changes, new account routes or changes to strategy traffic.

Keep a named owner for limit configuration and a controlled change process. A useful review record shows the provider limit, internal budget, expected peak, safety margin, alert thresholds and approval date. When a limit is raised, confirm that downstream queues, connection pools and risk controls can handle the additional throughput. More permitted requests do not automatically mean more safe capacity.

After an incident, compare the intended policy with actual behaviour: which requests were delayed, which were retried, which orders needed reconciliation, and whether capacity was allocated as documented. Which client action could your system delay today before your team knew who was affected?

#limitação de requisições da API do broker #estratégia de backoff de API #rate limit monitoring #trading API rate limits #order management controls #API retry policy #broker API compliance #order queue design