Plataformas · Software · Proveedores · Mercados
Something you see in nearly every broker API setup: a client gets an HTTP 429, waits a fixed second, then sends the same request again. Under light load, it appears to work. During a market open or a reconnect surge, many clients do it at once, and the retry traffic keeps the limit exhausted.
The fault is not simply an aggressive client. It is usually a design that treats throttling as an error response instead of a shared capacity signal. The API may be limiting requests by account, application, endpoint, IP address or some combination. If callers do not know which resource is constrained, they cannot recover safely.
For a broker or prop firm, that ambiguity reaches beyond an integration team. It can hold up order amendments, delay position checks and swamp support with apparently inconsistent failures. The practical task is to control demand, preserve the most important operations and make recovery predictable.
The dashboard that hides the actual limit
A single requests-per-second figure is an incomplete description of a rate limit. Providers commonly enforce more than one bucket: a broad application limit, a per-user or per-account limit, and narrower limits for order placement, history or market data.
A burst allowance can sit on top of a refill rate. A concurrent-request ceiling may apply as well.
That means a service can remain below its average request budget and still receive 429 responses. For example, ten workers may each issue two requests per second, within a local setting of 20 requests per second. If the broker counts all workers against one application bucket with a smaller burst capacity, the combined traffic crosses the threshold immediately.
Read the provider's documentation and response headers, but verify their behaviour with controlled tests. Record the account and endpoint used, response status, reset or retry headers, latency and request ID.
If the limit is undocumented, ask whether limits are shared across credentials, whether reads and writes have separate buckets, and what happens after a limit is reached. Trading Technology's broker infrastructure coverage is useful context for comparing the operational assumptions built into trading platforms.
A benchmark is not a contract
There is no universal broker API quota. The ranges below are typical market ranges for planning tests, not guarantees or published limits for any named provider. Actual quotas vary with account tier, product, region, endpoint and commercial agreement. A broker's own response headers and written terms take precedence.
| API workload | Typical market range | Common constraint |
|---|---|---|
| Account and position reads | 5-30 requests per second per application | Shared application bucket or account-level cap |
| Order placement and amendment | 2-10 requests per second per account | Separate write quota, burst limit or concurrency cap |
| Historical data queries | 1-10 requests per second per application | Heavy queries may consume weighted quota |
| Concurrent requests | 5-20 in flight per credential | Excess requests may queue, time out or be rejected |
| Retry delay after throttling | 1-30 seconds, often increasing with repeated 429s | Retry-After header or provider-specific reset time |
Do not turn these figures into production defaults. The important questions are whether an endpoint has a separate budget, whether a request costs one unit or several, and whether a reconnect can consume the same allowance as live order handling.
A bulk history query may be weighted more heavily than a small account read. A market-data stream may not count as a REST call at all, while its subscription changes still do.
Build a quota map from observed responses and provider documentation. Include the scope of each limit, the refill behaviour, burst capacity, concurrency ceiling, reset semantics and the consequence of crossing it.
Mark uncertain values as uncertain. That stops an assumed per-account allowance from silently becoming a shared production limit.
Backoff is not a retry policy
Fixed-delay retries synchronise callers. If 300 sessions receive a 429 and all wait one second, they return together and create another burst. Exponential backoff reduces pressure, but without jitter the clients can still form waves.
Use full jitter: choose a random delay between zero and the current backoff ceiling, then increase that ceiling after each repeated failure. A typical starting ceiling might be 250-500 milliseconds, capped at 8-30 seconds, but honour a longer Retry-After value.
Backoff must also distinguish a rejected request from an ambiguous outcome. A 429 usually indicates that the request was not accepted, but a timeout or connection reset after submission may leave the result unknown. Replaying an order in that state can create a duplicate unless the API supports an idempotency key or the client first reconciles order state.
Set separate policies by operation:
- Retry idempotent reads with bounded exponential backoff and jitter. Stop when the caller's deadline expires.
- For order submissions, use the provider's idempotency mechanism where available. If the outcome is uncertain, query by client order ID before resubmitting.
- For cancels and amendments, reconcile current order state. A retry can race with a fill or a later amendment.
- Do not retry authentication, validation or permission failures as if they were throttling. They need a different response path.
Every queue needs a maximum age and a maximum attempt count. An order amendment delayed beyond its business deadline may be more harmful than a clear failure. Preserve the original intent and report that the action expired, rather than executing it late without a policy decision.
Shape traffic before it reaches the broker
Rate limiting belongs at the edge of the client system, where all workers can see the same budget. A central token bucket is useful when the provider allows short bursts but imposes a sustained rate.
A leaky-bucket queue smooths outbound traffic when steady pacing matters more than immediate dispatch. Neither helps if each pod maintains an independent counter against one shared broker quota.
Partition capacity by the limit the provider actually enforces. If limits are per account, key the limiter by account. If an application-wide cap is also present, enforce both. Keep headroom for reconnects and operational actions; running continuously at the stated maximum leaves no room for a burst, clock skew or a second service sharing the credential.
Traffic priority needs explicit rules. For example, protect order cancels and risk-reducing amendments ahead of routine position polling, then defer analytics and historical backfills. Do not let a background sync take every available token simply because its queue is longer. A typical operating target is to reserve 20-30% of known capacity for bursts and recovery, then tune against measured traffic and the provider's actual behaviour.
Track the signals that show whether the design is working:
- Requests and throttles by endpoint, credential, account and status code.
- Queue depth, oldest item age, attempts per request and dropped or expired work.
- Latency from enqueue to dispatch, plus end-to-end order acknowledgement time.
- 429 frequency, Retry-After values, timeout rate and the number of uncertain order outcomes.
Alert on the trend, not only a fixed count of 429s. A brief throttle during a planned test differs from a rising queue that is pushing order actions past their deadline. Trading Technology's platform and operations reporting also covers the wider infrastructure choices that shape API capacity and resilience.
Test the recovery path, not just steady state
Load tests often prove only that a client can sustain a smooth rate below a presumed quota. Test the failure modes: burst above the limit, simultaneous reconnects, delayed responses, missing Retry-After headers, a broker outage followed by recovery, and one slow endpoint while others remain healthy. Confirm that a history backfill cannot block an order cancel.
Use a test environment or a controlled mock to simulate limits. Do not discover a production ceiling by deliberately flooding a live broker API.
Inject 429s and timeouts at different points in the request lifecycle, including after the broker may have accepted an order. Check that deduplication, reconciliation, expiry and alerting behave as designed.
During an incident, operators need a clear way to reduce optional demand without stopping essential actions. A throttle switch can pause history jobs, reduce polling frequency or cap new subscriptions. Document who can activate it, which queues it affects and how normal service resumes. Gradually release deferred work after recovery; draining the entire backlog at once can trigger a second rate-limit event.
Most teams will still make the same mistake after reading this: they will tune each client's retry delay, but leave the shared quota, queue priority and order reconciliation unmanaged.
Preguntas frecuentes
What should a client do after a broker API returns HTTP 429?
Read Retry-After or reset headers and pause requests in the affected quota scope. If there is no usable header, apply bounded exponential backoff with jitter. Do not let each worker retry independently against a shared limit.
Should order requests be retried after a timeout?
Not blindly. The broker may have accepted the order even if the client did not receive the response. Use an idempotency key if supported, or reconcile the order by client order ID before submitting again.
How should a broker API rate limiter be designed?
Model every documented quota, including application-wide, account-level, endpoint and concurrency limits. Enforce shared budgets centrally, reserve capacity for critical actions and give queues deadlines and priority rules.
What is a reasonable backoff delay for API throttling?
There is no universal delay because broker limits and reset rules differ. Honour Retry-After where available; otherwise use exponential backoff with full jitter, a bounded maximum and a request deadline.
