01.Stream what changes, request what does not
Split your data by how often it actually changes. Order books and trades change constantly and belong on a websocket. Market metadata — titles, resolution criteria, end dates — changes rarely and should be fetched once and cached. Most rate limit trouble is one of these being treated as the other.
- Order books and trades: websocket, always.
- Market metadata: fetch once, cache, refresh on a slow schedule.
- Positions and history: request on demand, not in a loop.
02.Cache with a deliberate lifetime
Give every cached item an explicit expiry chosen from how fast it really changes, rather than caching everything for the same arbitrary duration. Resolution criteria for a settled market never change at all; the list of open markets changes hourly. Treating both the same is either wasteful or wrong.
- Pick each expiry from the data's real rate of change.
- Immutable data — settled market details — can be cached indefinitely.
- Cache negative results too, so a missing id is not refetched in a loop.
03.Back off properly when you are limited
If you are rate limited, retrying immediately makes it worse and can extend the block. Use exponential backoff with jitter — the jitter matters, because without it every instance of your bot retries in lockstep and recreates the spike. Respect any retry-after the response gives you rather than guessing.
- Exponential backoff, with jitter so retries do not synchronise.
- Honour retry-after headers rather than inventing your own delay.
- Never retry in a tight loop; it converts a pause into a longer block.
04.Batch and scope your requests
Ask for many things in one request where the endpoint allows it, and ask only for what you use. A dashboard fetching each market individually in a loop will hit limits that the same dashboard fetching them in batches will not, and subscribing to markets you never display costs you parsing time as well as quota.
- Use batch endpoints instead of per-item loops.
- Subscribe only to the markets you actually render or trade.
- Request only the fields you need where the API supports narrowing.
05.Fail visibly, not silently
A bot that silently stops receiving data is more dangerous than one that crashes, because it keeps acting on a view of the world that stopped updating. Log rate limit responses, alert on repeats, and treat a stale feed as a reason to stop trading rather than a cosmetic problem.
- Log and alert on rate limit responses rather than swallowing them.
- Track data age and refuse to trade on stale state.
- Silent degradation is the failure mode that costs money.