Institutional crypto trading increasingly hinges on infrastructure that can keep pace with automated execution strategies. Market makers, quantitative funds, and other professional firms often send thousands of API requests across multiple accounts and markets as they continuously update orders, monitor positions, and react to shifting conditions. That makes API rate limits a critical—though frequently overlooked—component of exchange infrastructure.
Bitget has updated its institutional API framework, raising the maximum configurable rate limit for eligible users to 600 requests per second (RPS) per UID. At the account-group level, aggregate capacity can reach as high as 120,000 RPS across master and sub-accounts under its unified trading account framework. But what does this actually change for institutional traders?
Understanding API rate limits
An API rate limit dictates how many requests a trading system can send to an exchange within a specified period. These requests include submitting new orders, cancelling existing ones, replacing quotes, retrieving balances and positions, requesting account information, and managing automated execution workflows. For a retail trader placing a handful of orders manually, these limits may rarely become noticeable. For an institutional market maker, the situation is vastly different.
A firm could be quoting dozens or hundreds of markets simultaneously, each requiring continuous updates on both the buy and sell sides as prices move. If the trading engine wants to cancel an outdated quote and immediately replace it with a new one, both actions consume API capacity. Multiply that across many instruments, strategies, and sub-accounts, and request throughput can become a meaningful infrastructure constraint.
Why market makers need more API capacity
Market makers generally aim to maintain competitive bid and ask prices while controlling inventory and execution risk. When the underlying market moves, stale orders may need to be cancelled or repriced quickly. Suppose a trading firm operates across 100 markets. Even if it updates only a small number of orders per market each second, the total number of requests can rise rapidly once order submission, cancellation, account monitoring, and position management are included.
A low API ceiling can therefore create bottlenecks. Instead of allowing the trading engine to determine when an order should be updated, the firm may have to prioritize requests simply to remain within the exchange's technical limits. Higher rate limits give sophisticated trading systems more room to operate without being throttled during periods of elevated activity. They do not guarantee better execution, but they can remove one potential constraint from the execution process.
Bitget's new framework: 600 RPS per UID
Under Bitget's updated institutional framework, qualifying MM1 market-maker and PRO6 users operating through its unified trading account can configure a maximum rate limit of up to 600 RPS for an individual UID. The limit is not automatically applied to every institutional account. Instead, eligible firms can allocate API capacity according to their account structure and trading requirements. Other market-maker and PRO tiers receive lower limits according to their respective account level, while Bitget's classic-account rate limits remain unchanged. This distinction is important because the headline 600 RPS figure represents the maximum available tier rather than a universal limit for every API user.
Aggregate capacity reaches 120,000 RPS
The larger change becomes more apparent when sub-accounts are considered. Institutional trading firms commonly use multiple sub-accounts to separate strategies, teams, risk books, or trading activities. Bitget's framework introduces aggregate rate-limit capacity across a master account and its associated sub-accounts, reaching as high as 120,000 RPS at the top eligible tier. Aggregate limits are separately quoted for unified-account spot and futures trading.
This creates a two-level structure: an individual UID has its own configured rate limit, while the combined allocation across the account group must remain within the institution's aggregate ceiling. For larger trading operations, this can provide substantially more flexibility than relying on the same fixed request allowance across every account.
Why per-UID configuration matters
The ability to allocate different API limits to different UIDs may be just as relevant as the higher maximum itself. Not every trading strategy generates the same amount of API traffic. For example, a high-frequency market-making strategy operating across a large number of instruments may need significantly more request capacity than a sub-account running a slower execution strategy. A configurable system allows an institution to concentrate available capacity where it is needed instead of treating every account identically.
It can also reduce the incentive to create additional accounts purely to obtain more API throughput. According to Bitget's framework, institutions can increase the allowance for a particular UID without opening another account, provided the total allocation remains within the applicable aggregate limit. New sub-accounts still need to be configured, as Bitget's framework requires institutions to set quotas for individual UIDs. This granular control is particularly valuable for firms that run diverse strategies across multiple accounts, similar to how KuCoin's recent institutional lending changes and LayerZero's ATLAS initiative are reshaping institutional access to crypto markets.
For institutional traders, the practical takeaway is that higher API rate limits can reduce operational friction during peak activity. While they don't directly improve execution quality, they allow trading engines to operate without artificial throttling, which is essential for strategies that depend on rapid order updates. As the crypto derivatives space grows more competitive, infrastructure upgrades like this may become a key differentiator for exchanges courting institutional liquidity.
This article is for informational purposes only and does not constitute financial advice.
