API Rate Limits on FTX US

FTX US offers REST, WebSocket, and FIX APIs to suit your algorithmic trading needs. API is available for both retail and institutional customers on FTX US. 

API Docs can be found here.

Rate limits

Screen_Shot_2022-08-18_at_3.50.24_PM.png

Rate limits are enforced account-wide, not per subaccount.

Cancels do not count towards any of these rate limits, and hitting the rate limits won’t stop you from being able to cancel.  Similarly, market data calls do not contribute to the rate limits, only order placement. 

Soft and hard rate limits: hard rate limits always apply. Soft rate limits only apply when the matching engine gets close to a backlog. This means that, when orders become more in demand, rate limits help ensure that the most important orders still have room by reducing the room for less important ones; but when markets are quiet, users have more freedom to use the spare capacity.

 

Additional considerations for VIPs and Market Makers

Small orders: small orders will be subject to Fee Tier 6 limits (as described above). Small orders are those that are under largeOrderThreshold (typically $3000, see the response in this endpoint https://ftx.us/api/markets) in size and are on a market whose max order size is greater than $10k. Large orders will enjoy full VIP limits, which have been increased along with this restriction on small orders.

Very high limits: For users with volumes at least 2x the requirements of VIP7/MM7, the rate limits are 2x the VIP7/MM7 tier. For users with volumes at least 4x the requirements for VIP7/MM7, the rate limits are 4x the VIP7/MM7 tier. If you are in this category, please feel free to contact us. 

To see our VIP and Market Maker program, visit this page.

 

Additional Details

The relevant limits on order placement are mostly unaffected by other API calls; you can cancel orders and fetch private data without using your order placement rate limits.

You will likely begin to see longer latency if you send more than one order in a 50ms period in a particular subaccount; this means that you can theoretically get out roughly 20 orders per second per subaccount if they are evenly spaced out without experiencing higher latency.

In addition to this, there is a cap on how many requested-but-not-yet-risk-checked orders a given subaccount can have out at once. This limit is only relevant if you are sending at a rate that exceeds our risk-checking throughput for your subaccount. This is typically around 140 orders per second but may vary with market conditions. Again, you can send more if you split between subaccounts; and this restriction only applies to orders placed, not orders canceled.  Splitting between different API keys or IP addresses will not have any effect on this limit.

Furthermore, there will soon be a cap on orders sent overall for a user and per market per user (just orders, not cancels or marketdata).  A user in this instance means a full account on FTX US including all subaccounts.  To be clear this limit applies across an entire account--not just a subaccount--but to some extent you get individual limits for each market.

 

The context for these changes:

When markets move a lot, it can take longer to process orders.  This is because everyone wants to send lots of orders, and so everyone does--enough to cause a backlog.  There are two problems: first that it causes delays; but second, that it means that orders that would have traded end up getting backlogged in favor of orders that were going to be quickly cancelled anyway.

Each person sends all of their marginal orders (why not!), enough that the total number of orders sent is faster than the matching engine can process them.  And so only some of the orders are processed quickly (the first sent), including some marginal orders that the sender didn't really care about.  But this means that other orders--including some really important orders--end up at the back of the line.

The best solution is to increase capacity, and we're doing that. Improvements to the matching engine to increase throughput and efficiently handle load are constantly being worked on. But in addition, it's important that even when things are busy, (a) there isn't much lag, and (b) people can get their most important orders through.

That's why rate limits exist: to make sure that each person's most important orders get through quickly and aren't held back by others' marginal orders.

This is also why we're introducing soft and hard rate limits.  Hard rate limits always apply.  But soft rate limits only apply when the matching engine gets close to a backlog.  This means that, when orders become more in demand, rate limits help insure that the most important orders still have room by reducing the room for less important ones; but when markets are quiet, users have more freedom to use the spare capacity.

Note that, generally, these rate limits attempt to maintain a consistent $ volume traded per order ratio--that is, each user has roughly the same fill rate * order size threshold.