// GLOSSARY
Rate limit
A cap on how many API requests you may send per time window. Exceeding it returns errors (often HTTP 429) and, if abused, can get keys restricted. Well-built bots budget requests, batch reads, and prefer WebSockets to polling.
Both Kalshi and Polymarket meter API usage — per key, per endpoint class, per time window. Limits differ by venue and access tier and get revised, so read the current docs rather than hard-coding numbers.
How limits bite trading bots
The failure mode isn't usually browsing markets — it's the hot path: a bot that polls order books in a tight loop, or re-quotes aggressively, burns its budget exactly when the market is moving and then can't place the order that mattered. Order placement and cancellation share the same budget as your reads on some tiers.
Engineering around them
- Subscribe, don't poll: a WebSocket feed delivers book updates without spending request budget.
- Handle 429s with backoff and jitter, and treat them as expected weather, not exceptions.
- Reserve headroom for actions: always leave budget for cancels — being unable to exit is worse than being unable to enter.
- Batch and cache metadata reads.
Concrete numbers, headers, and retry patterns for both venues are collected in rate limits and order types.