Why higher API rate limits matter for institutional crypto trading

Institutional cryptocurrency trading increasingly depends on infrastructure that can keep pace with automated execution strategies.

Market makers, quantitative funds and other professional trading firms may send thousands of API requests across multiple accounts and markets as they continuously update orders, monitor positions and respond to changing market conditions.

That makes API rate limits an important — if often overlooked — part of exchange infrastructure.

Bitget recently 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 why does that matter, and what does higher API capacity actually change for an institutional trader?

What is an API rate limit?

An API rate limit determines how many requests a trading system can send to an exchange within a specified period.

Those requests can include actions such as:

• submitting new orders;
• cancelling existing orders;
• 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 very different.

A firm could be quoting dozens or hundreds of markets simultaneously. Each market may require continuous updates on both the buy and sell sides as prices change.

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 process 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 try 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 raises the maximum to 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 can reach 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

Higher theoretical capacity does not mean every account automatically receives a higher limit.

Bitget's framework requires institutions to configure quotas for individual UIDs.

New sub-accounts created after initialization also require their own rate-limit configuration.

Where no quota has been assigned, the framework applies a default limit of 10 requests per second once the mechanism takes effect.

That makes API configuration an operational issue as well as a technical one.

Institutional trading teams need to make sure account permissions, API credentials and request limits are aligned with the strategy that will actually use the account.

Otherwise, a trading system capable of handling substantially more throughput could still be restricted by the default configuration.

API capacity is only one part of institutional execution

Higher API throughput should not be confused with trading performance itself.

Execution quality also depends on factors including:

• available market liquidity;
• order-book depth;
• bid-ask spreads;
• network latency;
• matching-engine performance;
• order types;
• risk controls; and
• the design of the trading strategy.

A system capable of sending hundreds of requests per second does not automatically achieve better prices.

Instead, API capacity determines how much freedom the trading system has to communicate with the venue.

For sophisticated firms, removing API bottlenecks can make it easier for their own execution logic to operate as intended.

The broader shift toward institutional exchange infrastructure

Crypto exchanges have increasingly moved beyond simple retail trading interfaces toward infrastructure designed for professional trading organizations.

That includes unified accounts, sub-account management, API permission controls, institutional lending, block trading and OTC execution.

Bitget's expanded API framework fits into that broader development.

Its unified trading account structure allows eligible institutional clients to manage spot and futures activity alongside configurable sub-account and API settings.

The exchange effectively sits at the execution layer of an institutional trading stack.

Custody, portfolio management, risk systems and reporting may still be handled through separate providers, particularly for institutions that deliberately separate asset custody from exchange execution.

What institutional traders should look at

When evaluating an exchange's API infrastructure, the headline maximum request rate is useful, but it should not be considered in isolation.

Institutions should also examine how limits are calculated, whether they apply per account or per endpoint, how sub-account capacity is allocated, what happens when a threshold is reached and whether limits can be adjusted as trading activity grows.

They should also verify whether spot and derivatives activity share the same limits or are managed independently.

For firms operating many strategies and accounts, the flexibility of the rate-limit architecture can ultimately matter as much as the absolute maximum.

Conclusion

API rate limits are one of the less visible components of institutional crypto trading infrastructure, but they can directly affect how quickly automated systems are able to interact with an exchange.

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.

The significance is not simply that institutions can send more requests.

It is that larger trading firms can allocate API capacity more granularly across their account structure, giving high-activity strategies more room to operate without creating additional accounts solely for request throughput.

As exchanges continue competing for institutional flow, infrastructure features such as API capacity, account architecture and execution flexibility are likely to become increasingly important alongside liquidity and trading fees.