# Deriv API rate limits

Independent and unofficial. Not affiliated with or endorsed by any broker or platform named here. Educational only: nothing here is advice, and nothing here recommends a broker or a trade.

This is the markdown version of https://openbrokerapi.com/brokers/deriv/rate-limits, written from the same records as that page.

Risk warning: CFDs and spread bets are complex instruments and come with a high risk of losing money rapidly due to leverage. You can lose money on these products, and each provider publishes its own loss figure under FCA rules. You should consider whether you understand how they work and whether you can afford to take the high risk of losing your money. Automated and API trading can amplify losses through bugs, connectivity failures and runaway orders.

What is recorded about how fast you may call the Deriv API: 1 limit record, the wording from the record and 1 related error code.

- Newest check: 2026-10-12

## Recorded limits

One record per limit. The scope is part of the limit: a figure is only useful once you know whether it applies to a key, an account, a session or an address.

- Headline limit: 80/min per logged in user (REST)
  - Scope: user, REST
  - Sources conflict: [developers.deriv.com](https://developers.deriv.com/llms/api-overview.md) states 60 REST requests per minute per token, checked 2026-10-12. Deriv's API overview in the text form it publishes for AI tools gives REST 60 requests a minute per token, where its Limits page gives 80 a minute per logged in user. The same overview also gives 100 WebSocket requests a second per connection, 100 active subscriptions per connection and 5 concurrent WebSocket connections per user, none of which the Limits page mentions. Deriv's own pages disagree; the conflict is labelled, not resolved. Pace against 60.
  - Status: conflicting. Source: [developers.deriv.com](https://developers.deriv.com/docs/limits/), checked 2026-10-12.
  - Note: From the Limits page: REST is also capped at 300 a minute and 1,000 per ten minutes per IP address. WebSocket budgets, each shared by the calls in its row, a minute and an hour: proposal, proposal_open_contract, buy and sell 360 and 14,400; balance and statement 100 and 2,000; portfolio and profit table 30 and 1,500; all other calls 220 and 14,400. ping sits outside these budgets at 10 a second per connection.

## Rate limits, as the record words them

- Rate limits, as worded: Websocket, per minute and per hour: proposal, buy and sell 360 and 14,400; balance and statement 100 and 2,000; portfolio and profit_table 30 and 1,500; everything else 220 and 14,400. REST: 300 a minute and 1,000 per 10 minutes per IP, and 80 a minute per logged in user, which is the binding constraint for most retail scripts. Deriv's API overview in the text form it publishes for AI tools gives different figures: REST 60 a minute per token, and on the WebSocket 100 requests a second and 100 active subscriptions per connection, with 5 concurrent connections per user. Deriv's own pages disagree.
  - Sources conflict: Deriv Limits page: REST 80 a minute per logged in user, 300 a minute and 1,000 per 10 minutes per IP, WebSocket budgets per group of calls. Deriv API overview (llms/api-overview.md): REST 60 a minute per token, WebSocket 100 requests a second and 100 subscriptions per connection, 5 connections per user.
  - Status: conflicting. Source: [Deriv API: limits](https://developers.deriv.com/docs/limits), checked 2026-10-12.
  - Status: conflicting. Source: [Deriv API overview, text form for AI tools](https://developers.deriv.com/llms/api-overview.md), checked 2026-10-12.

## Error codes that concern limits

These are the decoded Deriv errors whose record concerns a rate limit, an allowance or throttling. Each links to the full meaning and the fix.

- [RateLimit](https://openbrokerapi.com/errors/deriv/rate-limit) (HTTP status not recorded): Too many requests were sent.
  - Status: verified. Source: [developers.deriv.com](https://developers.deriv.com/llms/errors.md), checked 2026-10-09.

## Pacing and backoff, in general

This part is general advice and says nothing about Deriv in particular. The figures that apply are the recorded ones above, and the provider's own documentation is the authority.

Pace before you are refused. Work out the gap between requests that keeps you under the limit, then leave a margin, because a limit counted by a provider's clock will not line up exactly with yours. Spread calls evenly: a burst at the start of each window is the usual way to hit a limit while staying under it on average. The rate limit calculator at https://openbrokerapi.com/tools/rate-limit-calculator checks a polling plan against a limit and gives the shortest interval that fits.

When a request is refused for rate, stop sending and wait. Double the wait after each refusal in a row, add a small random amount so that several programs do not retry together, and cap the number of attempts. If the reply names how long to wait, use that figure in place of your own.

Take extra care with dealing requests. A refused or unanswered order may or may not have gone through, so check the state of the order before you send it again. Cache what does not change, such as instrument details and history you have already downloaded, and prefer a stream to polling where one is offered.

## Where to go next

- [The full Deriv record](https://openbrokerapi.com/brokers/deriv)
- [All Deriv error codes](https://openbrokerapi.com/errors/deriv)
- [Rate limits for every broker and platform](https://openbrokerapi.com/rate-limits)
- [The fact register](https://openbrokerapi.com/facts)

## Licence and how to cite

The limit records on this page come from the limits register, which is CC BY 4.0 (https://openbrokerapi.com/data/limits.json). Everything else on it comes from records that are all rights reserved. This file is the page itself, at its own address, in another format, and it is not part of the CC BY 4.0 downloads listed at https://openbrokerapi.com/data.

Cite as: Deriv API rate limits. Broker API Hub, https://openbrokerapi.com/brokers/deriv/rate-limits, newest check 2026-10-12.

Where you rely on a single figure, cite the source and the checked date printed beside it as well. Where this page and a broker's own documentation differ, the documentation wins.
