Reference
How to design a request queue so the bot does not hit Bybit's limits at the exact moment it urgently needs to cancel an order.
We do not sell signals. We do not manage your money. We develop software that executes your trading strategy.
| Operation | Typical limit |
|---|---|
| Order create / amend / cancel | 10 req/s per UID |
| Position and wallet queries | 10 req/s per UID |
| Public market data (REST) | 600 req / 5 s per IP |
| WebSocket connections | 500 per 5 min per IP |
| Args per WebSocket subscribe | 10 per request |
Practice
A separate bucket per IP and per UID — the limits are counted separately.
Cancels and risk reduction go ahead of quote refreshes. Always.
Exponential backoff with jitter; a tight retry loop only makes it worse.
A client order ID, so a retry after a timeout cannot create a second position.
The values are order-of-magnitude and are changed by the venue. Verify against Bybit's current documentation and the response headers, where the exchange returns the remaining quota.
Tell us the exchange, the market and the rules. We answer within one business day.
Brief
Four questions and your contact. No deposit required to talk — if the job is not a fit, we say so straight away.