Bitget has expanded its institutional trading API capacity, increasing the maximum configurable rate limit to 600 requests per second for eligible users and raising potential aggregate throughput to as high as 120,000 RPS across master and sub-accounts under its unified trading account framework. The change targets a common operational constraint for market makers and other high-frequency trading firms that rely on automated order management and rapid account monitoring.
While higher rate limits do not automatically improve execution quality, they can reduce throttling risk during periods of heavy quoting, order cancellations, and strategy-driven activity—an issue that becomes more pronounced as firms deploy multiple strategies across many instruments and account partitions.
Key takeaways
- Rate limits increased: Eligible institutional users can configure up to 600 RPS per UID, while top-tier aggregate capacity can reach 120,000 RPS across account groups.
- Catalyst: Bitget updated its institutional API framework to allow higher and more flexible API allocation across unified accounts and sub-accounts.
- Operational implication: Market makers running continuous quote updates may face fewer infrastructure bottlenecks from API throttling.
- Not an execution guarantee: The upgrade primarily increases communication capacity with the exchange rather than directly improving spreads or liquidity.
- Implementation detail matters: Higher theoretical ceilings still require per-UID quota configuration, and default limits may apply where quotas are not set.
What API rate limits do in institutional trading
An API rate limit caps how many requests a trading system can send to an exchange within a defined period. For institutional platforms, that constraint can extend beyond submitting orders. API calls also support routine operational needs such as cancelling and replacing orders, updating quotes, retrieving balances and positions, requesting account information, and running automated execution workflows.
For retail traders placing occasional orders manually, rate limits often remain invisible. For market makers and quantitative firms operating at scale, however, the number of requests can multiply quickly. A single strategy may need continuous bid-and-ask updates across many instruments, with each quote change potentially requiring separate API actions such as cancelling stale orders and submitting replacements.
Why higher capacity is being prioritized by market makers
Market makers generally aim to keep competitive prices while managing inventory and execution risk. When market conditions shift, stale orders may need to be removed and repriced quickly. In practice, that means more API activity—particularly when a firm runs across a large number of markets simultaneously.
In such setups, a low API ceiling can force prioritization decisions that are driven by technical throttling constraints rather than by the trading engine’s intended logic. By expanding available throughput, higher rate limits give automated systems more room to operate during elevated activity without being constrained by exchange-side request caps.
Importantly, the update is about enabling more messaging capacity. It does not inherently guarantee better trading results, since execution quality depends on a broader set of factors including market liquidity, order-book depth, spreads, network latency, matching-engine performance, order types, risk controls, and strategy design.
What Bitget changed in its institutional API framework
According to Bitget, the revised institutional framework allows qualifying MM1 market-maker and PRO6 users operating through its unified trading account to configure a maximum rate limit of up to 600 RPS per UID. The headline figure is not described as an automatic universal cap. Instead, eligible firms can allocate API capacity based on their account structure and trading requirements.
Bitget also indicated that other market-maker and PRO tiers receive lower limits consistent with their respective account levels, and its classic-account rate limits remain unchanged. The framework’s headline maximum is therefore presented as the top available tier rather than a guaranteed limit for every institutional account.
Beyond per-UID limits, Bitget said the framework introduces aggregate capacity across master accounts and associated sub-accounts, reaching up to 120,000 RPS at the top eligible tier. It further noted that aggregate limits are separately defined for unified-account spot and futures trading, creating a two-level structure: an individual UID can have its own configured rate limit, while the combined allocation for the account group remains subject to an aggregate ceiling.
Per-UID configuration and the operational requirements
Bitget’s approach emphasizes flexibility in how capacity is distributed across account partitions. The ability to assign different rate limits to different UIDs can be critical because not every strategy generates the same API traffic. A high-frequency market-making strategy spread across many instruments may require more request capacity than a slower execution strategy running under a different account slice.
The framework also aims to reduce incentives to open additional accounts solely to obtain more API throughput, since capacity can be increased for a particular UID without creating another account, provided total allocation stays within the applicable aggregate limit.
However, higher theoretical ceilings still require implementation work. Bitget states that institutions must configure quotas for individual UIDs. New sub-accounts created after initialization also need their own rate-limit configuration. Where no quota is assigned, Bitget said the mechanism applies a default limit of 10 requests per second.
That means the upgrade can remain underutilized if account permissions, API credentials, and configured quotas are not aligned with the strategies actually running across the account group.
What to watch as exchanges compete for institutional flow
Bitget’s update reflects a broader shift in crypto exchange infrastructure toward features designed for professional trading organizations, including unified accounts, sub-account management, API permission controls, and execution-oriented tooling. In this model, the exchange functions as an execution layer inside a wider institutional stack, where custody, portfolio management, risk systems, and reporting may be handled by separate providers.
For institutions evaluating exchange infrastructure, the practical focus is not only the maximum request rate but also how limits are calculated and enforced—whether per account or per endpoint, how sub-account capacity is allocated, what happens when thresholds are reached, and whether limits can be adjusted as trading activity grows. Firms operating multiple strategies will likely be most sensitive to whether the rate-limit architecture offers granular allocation rather than a single fixed allowance across all accounts.
Looking ahead, trading teams are likely to review how their own quoting and automation workflows interact with the new per-UID and aggregate ceilings, and whether they need to update quota configurations to realize the full benefit. For exchanges, the next competitive pressure point will increasingly be execution flexibility and infrastructure capacity alongside liquidity and trading fees.
Bitget’s updated framework increases the maximum configurable ceiling to 600 RPS for individual eligible MM1 and PRO6 UIDs and introduces aggregate master/sub-account capacity of up to 120,000 RPS for unified-account trading.
