Limits are typically expressed as requests per second with a burst allowance, and often separately for orders, cancellations and data queries. A system that polls positions every 200ms per instrument across 50 instruments will hit a limit it never encountered in testing with two symbols.
Design for it rather than reacting to it. Use streaming or websocket updates instead of polling, batch queries where the API allows, maintain your own position state and reconcile periodically, and implement exponential backoff with jitter on rejection.
The dangerous failure mode is throttling during volatility, when your system most wants to act and the event rate is highest. Reserve headroom: budget normal operation at well under half the limit so a busy day does not lock you out. Pair this with a kill-switch that flattens rather than retries blindly.
Related: kill-switch, idempotent-order, order-reconciliation, latency