Broker API rate limits: backoff, throttling and queues

In nearly every broker API setup, one service starts with a simple loop: request data, receive a response, then request more. It works in development, until a market open, reconnect or batch job makes several workers ask at once. The broker returns HTTP 429, requests slow down, and the integration has to decide what can wait.

Rate limits are not just an inconvenience to code around. They are a shared capacity control across endpoints, accounts, applications or network addresses. A production design needs to know which resource is limited, how long to pause, and which work must keep moving while it waits.

What a rate limit measures

A limit usually sets the number of requests allowed in a period, but the quota may be enforced across several dimensions. A broker might count calls per API key, user account, IP address, endpoint group or trading session. Limits can also differ for reads and writes. The published figure is only useful once the applicable scope is clear.

Common enforcement models include a fixed window, a sliding window and a token bucket. A fixed window allows a set number of calls per interval, such as 60 requests per minute, and resets at the interval boundary.

That can allow a sharp burst on either side of the reset. A sliding window smooths the count over time. A token bucket accumulates capacity up to a cap and spends one or more tokens per request, allowing limited bursts while controlling the sustained rate.

Some APIs expose headers such as remaining quota or reset time. Others return only a 429 response and, sometimes, a Retry-After value.

Treat these as signals, not as a complete specification. A response may identify only the endpoint that rejected the call, while another shared quota is close to exhaustion.

The following are typical market ranges, not universal limits. Actual quotas vary by broker, product, account tier and endpoint, so confirm them with the provider and test the deployed credentials.

Where throttling becomes an operational problem

A single worker receiving a 429 is easy to handle. The harder case is correlated demand.

A market-data reconnect can trigger subscription restoration, while account polling, risk checks and order workflows continue. If every worker retries immediately, the client creates another burst just as the broker is trying to recover.

Limits also create a prioritisation problem. A position or order-status query may be needed to reconcile risk, while a historical candle refresh can wait.

If both use one undifferentiated queue, low-priority reads can delay operationally important calls. The same applies inside a prop firm: a firm-wide key may be shared by several strategies, and one noisy process can consume capacity needed by others.

Look for patterns that reveal the actual failure mode:

• 429 responses clustered around market open, scheduled jobs or reconnects.
• Latency rises before errors appear, suggesting queues are building upstream.
• One endpoint group hits its limit while other calls continue normally.
• Workers repeatedly fetch unchanged data or retry requests that are already in flight.
• A burst of authentication failures leaves otherwise healthy services unable to reconnect.

Track request rate, response code, latency, queue depth and retry count by endpoint and credential scope. Record the provider's quota headers when available. Avoid logging access tokens or account-sensitive payloads. An aggregate metric can show that a shared limit is being approached without exposing client details.

"A 429 is a capacity signal. Repeating the same request faster does not make it clear sooner."

Backoff that does not amplify the failure

Backoff spaces retries out. Exponential backoff increases the wait after each failed attempt; jitter adds randomness so that many clients do not retry together. A common full-jitter calculation is a random delay between zero and the smaller of a cap and base × 2attempt. A base of 100-250 milliseconds and a cap of 2-5 seconds can be a starting point for non-critical reads, subject to the broker's guidance and observed latency.

If the response includes Retry-After, honour it. Do not let a local retry timer override a longer provider-specified pause. Add a retry budget, such as three to five attempts for a read, then move the task to a delayed queue or report a failure. Endless retries conceal an outage and consume capacity that other work needs.

Writes need different treatment. If an order submission times out, the client may not know whether the broker accepted it. Blindly sending the same request again can create a duplicate order. Use a provider-supported idempotency key where available.

Otherwise, reconcile by querying order state or using a client order identifier before resubmitting. Keep order intent, submission result and reconciliation state separate in the application.

For ordinary reads, stale data may be preferable to a retry storm. Cache responses where the product allows it, coalesce identical in-flight requests, and serve the last known value with its timestamp when a refresh is delayed. A circuit breaker can pause calls to a persistently failing endpoint, then allow a small number of probes after a cool-down.

Shape traffic before it reaches the API

Backoff is a recovery mechanism, not a traffic plan. Put requests through a central scheduler or a coordinated limiter when multiple workers share a credential.

A local limiter in each process can appear compliant while the combined fleet exceeds the broker's account-level quota. Where coordination is too costly, allocate each worker a conservative slice and leave headroom for bursts and manual operations.

Separate queues by purpose, then give them explicit weights or priorities. Order submission, cancellation and risk reconciliation may need reserved capacity.

Market-data refresh and historical queries can be delayed or dropped when the queue grows. Do not assume cancellations have a separate quota unless the broker confirms it.

1. Identify each quota scope and endpoint group from provider documentation, response headers and controlled tests.
2. Measure normal and peak request rates, including reconnects, batch jobs and failover behaviour.
3. Set a client-side budget below the documented ceiling, then reserve capacity for urgent actions.
4. Apply backoff with jitter to retryable reads, and make write retries conditional on idempotency or state reconciliation.
5. Load-test throttling and recovery. Check that queues drain without starving order and risk workflows.

Typical operating targets are to keep sustained traffic below roughly 70-80% of a confirmed quota, with enough headroom for short bursts. This is a starting range, not a rule: the right buffer depends on whether traffic is predictable, whether quotas are shared, and how quickly the broker resets capacity. A useful dashboard shows quota utilisation beside queue age, not just request count. A 30-request-per-second service may be healthy at 25 requests per second with a short queue, or already failing if work waits several seconds.

For teams comparing platform and connectivity design choices, Trading Technology's broker infrastructure coverage provides broader context. In day-to-day operations, alert on sustained utilisation, repeated 429s, growing queue age and exhausted retry budgets. Page an operator when a critical workflow is affected, not for every isolated throttling response.

Run limits as an operational control

Assign an owner for each integration's quota map and retry policy. Keep provider changes, credential changes and new endpoints in the same review process as capacity planning. A new reporting job can compete with order services even if it runs outside trading hours, because catch-up work often continues into the next session.

Review these controls during normal operations and incident exercises:

• Can the team see which quota scope returned a 429?
• Can low-priority work be paused without stopping order and risk functions?
• Do retries respect provider instructions and stop after a defined budget?
• Can the system distinguish an accepted order from an unknown submission outcome?
• Does failover avoid making every worker reconnect and resubscribe at once?

Test failure behaviour with a deliberately low client-side limit before relying on provider throttling as the test. Confirm that queues remain bounded, stale data is labelled, and alerts reach the right operator. Document recovery steps, including how to inspect outstanding orders and restart delayed work without replaying completed actions.

Which API quota, retry path or shared queue should the team test together in the next team meeting?

#limitação de requisições da API do broker #API backoff strategy #HTTP 429 handling #trading API quotas #order API retries #token bucket rate limiting #broker API reliability #request queue design