Ever been stopped cold by the message: “You’ve hit your API rate limit”?
Whether you're running real-time dashboards, backtests, or trading systems, hitting a limit can interrupt your workflow. This guide explains how CoinAPI API rate limits, REST Credits, WebSocket limits, and FIX sessions work, how to monitor your usage, and what to do when you receive a 429 error.
API Rate Limits and Quotas: CoinAPI Guide
API rate limits control how much traffic an API key can send or consume within defined conditions.
When a limit is exceeded, requests may be rejected or restricted, commonly with a 429 Too Many Requests response.
CoinAPI applies plan-based quotas and protocol-specific limits. Depending on the product and protocol, these can include:
- REST Credit limits
- REST concurrency limits
- WebSocket request and connection limits
- WebSocket subscription limits
- FIX session limits
- Usage Credit or plan allowances
CoinAPI infrastructure is designed to scale, but each API key remains subject to product-specific quotas, concurrency rules, and billing limits.
Quotas and limits are evaluated according to the rules of the relevant product and plan, so check the current documentation for reset windows and exact operational limits.
What Types of API Limits Does CoinAPI Use?
Different access methods are controlled differently.
1. REST Credit Limits
Market Data API REST usage is measured in REST Credits.
The number of HTTP calls alone does not always tell you how much usage you have consumed. For endpoints using the limit parameter, the amount of data returned matters.
2. Concurrency Limits
Concurrency limits control how many API requests can be processed simultaneously for a key or account.
This is different from REST Credit consumption. You can have enough credits remaining and still hit a concurrency restriction if too many requests are sent at once.
3. WebSocket Limits
WebSocket has its own operational controls, including limits related to:
- Requests per IP
hellomessages per IP- Concurrent connections or subscriptions associated with an API key
Exact WebSocket limits can change and may depend on the current product configuration, so verify the values in the latest Market Data API documentation rather than hard-coding them into your integration.
4. FIX Session Limits
Market Data FIX uses a session-per-API-key model.
A Market Data FIX API key supports one active session. Opening another session with the same key disconnects the existing session.
If your infrastructure requires additional FIX sessions or more complex connectivity, discuss the appropriate plan or enterprise setup with CoinAPI.
5. Account and Plan Limits
Your available usage also depends on your account configuration and plan.
Depending on the product and setup, usage above included quotas may be billed as metered usage or require additional Usage Credits. Some operational limits may instead require a plan upgrade or manual approval.
CoinAPI Market Data API Rate Limits
CoinAPI Market Data API access is governed by the limits associated with your account and access method.
REST, WebSocket, and FIX should not be treated as if they use the same quota model:
| Access Method | Main Usage Model | Additional Limits |
| REST | REST Credits | Concurrency |
| WebSocket | Data transferred | Request/IP, hello/IP, connection and subscription limits |
| FIX | Connection/session-based | Session/API key |
| Flat Files | Usage Credits / data transfer | Separate Flat Files pricing and access rules |
CoinAPI Market Data API no longer uses a traditional Free tier. New users can start with $25 in free credits and then continue with PAYG credits or a committed plan.
For current allowances and pricing, see the Market Data API pricing page.
How REST Credits Work
One of the most important distinctions is between an API call and a REST Credit.
They are not always the same thing.
If an endpoint uses the limit parameter, each 100 data points returned generally counts as 1 REST Credit.
A useful way to think about it is:
REST Credits = ceil(returned data points / 100)
If limit is not used or is unavailable for the endpoint, the API call generally counts as 1 REST Credit, unless endpoint-specific billing rules apply.
Example
If a request returns 200 records:
ceil(200 / 100) = 2 REST Credits
If it returns 500 records:
ceil(500 / 100) = 5 REST Credits
A request using limit=1000 does not necessarily consume 10 credits simply because 1,000 was requested. Actual consumption depends on the number of data points returned and the endpoint's billing behavior.
Always verify actual usage through the response headers and current pricing documentation.
REST Credit Example: OHLCV
Suppose you request one-minute OHLCV data:
A full day of one-minute OHLCV can contain up to 1,440 bars, depending on market activity and data availability.
Rather than assuming the query has a fixed credit cost, check the number of records returned and the X-Credits-Used header.
CoinAPI OHLCV can also contain bars with volume_traded=0 and trades_count=0 where there were no trades but relevant order book activity was present.
REST Credit Example: Trades
A targeted recent-trades request might look like this:
If 1,000 data points are returned and the standard REST Credit calculation applies, that corresponds to:
ceil(1000 / 100) = 10 REST Credits
If fewer records are returned, actual consumption can be lower.
The important point is to measure returned data, not simply count HTTP requests.
What About Historical Queries?
Historical requests should not be assumed to have a universal fixed maximum cost.
Some endpoints can have endpoint-specific billing behavior, but your application should not rely on an assumed “10-credit maximum” for date-bounded queries unless that behavior is explicitly documented for the endpoint you are using.
Instead:
- Check current endpoint documentation
- Use
limitwhere supported - Log actual
X-Credits-Used - Test a small time range first
- Estimate larger jobs based on observed consumption
For very large historical backfills, REST may not be the most efficient access method at all.
When to Use Flat Files Instead of REST
If you need several years of trades, quotes, OHLCV, or granular order book data, optimizing thousands of REST calls is usually the wrong problem to solve.
CoinAPI Flat Files are designed for bulk historical retrieval.
Use Flat Files for workloads such as:
- Multi-year backtesting
- Large ML training datasets
- Historical tick-data archives
- Full order book research
- Large cross-exchange datasets
- Reproducible historical research
Flat Files are a separate bulk historical product with their own access and Usage Credit pricing model.
REST remains useful for targeted historical queries. Flat Files are better suited to large-scale downloads.
How WebSocket Usage Is Different
WebSocket usage is not measured using the same REST Credit formula.
For Market Data API, WebSocket usage can include:
- Tier 1 Data — trades, quotes, and order book data transferred
- Tier 2 Data — metadata, OHLCV, and exchange-rate data transferred
Quotas and pricing depend on your plan and the amount of data transferred.
WebSocket also has protocol-specific operational limits related to requests, hello messages, connections, and subscriptions.
For applications that need continuous real-time data, WebSocket is generally more appropriate than repeatedly polling REST endpoints.
How FIX Usage Is Different
Market Data FIX is intended for institutional real-time market data workflows.
FIX usage follows its own connectivity and plan rules rather than the standard REST Credit model. Market Data FIX supports one session per API key, and opening another session with that key disconnects the current session.
Also keep the product distinction clear: Market Data FIX delivers market data. CoinAPI EMS handles trading and execution workflows.
How to Monitor Your API Usage and Quotas
The easiest place to manage your account is the API BRICKS Console.
Use the API BRICKS Console to manage:
- API keys
- Usage Credits
- Billing
- Subscriptions
- Usage
- Quotas
The Console provides centralized visibility into current and historical account usage. Checking usage there does not require making additional Market Data API calls.
Monitor Response Headers
CoinAPI responses can also provide useful usage information.
When available, log headers such as:
X-Credits-UsedX-Credits-RemainingX-RateLimit-Request-Cost- Relevant
X-RateLimit-*headers
However, rate-limit and usage headers may not appear on every response or every endpoint.
Your application should therefore not depend on these headers always being present.
Use them for observability when available, while keeping account-level monitoring in the API BRICKS Console.
How to Reduce REST Credit Consumption
Credit optimization is mostly about requesting the right data through the right interface.
1. Request Only What You Need
Avoid requesting thousands of data points when your application only needs the latest few observations.
Start with smaller limit values during development.
2. Cache Historical Responses
Historical data should not be repeatedly downloaded if it has already been stored locally.
Caching can substantially reduce unnecessary API usage.
3. Batch Where Supported
If an endpoint supports retrieving more useful data in one request, use that functionality instead of making many tiny calls.
But don't assume every endpoint supports multi-symbol batching.
For example, order book endpoints may require separate requests for individual symbols.
4. Use WebSocket for Continuous Data
If your application needs continuous real-time updates, repeatedly polling REST can generate unnecessary requests.
Use WebSocket for supported live streaming workflows.
5. Use Flat Files for Bulk History
If your job requires millions or billions of historical records, use Flat Files instead of trying to optimize an enormous sequence of paginated REST requests.
Common Triggers for API Limit Errors
Limit errors can occur even when you still have account credits available.
Common causes include:
- Too many simultaneous REST requests
- Exceeding a protocol-specific request limit
- Too many WebSocket connections or subscriptions
- Excessive reconnect or
helloactivity - Exhausted REST or Usage Credits
- Exceeding plan allowances
- Attempting to open another FIX session with the same key
Understanding which limit was hit is more useful than treating every error as a generic quota problem.
What Should You Do After a 429 Error?
A 429 Too Many Requests response means your client should reduce its request rate rather than immediately retrying as fast as possible.
A safer retry strategy is:
- Stop sending immediate retries.
- Use exponential backoff with jitter.
- Cap the number of retries.
- Respect server-provided retry guidance where available.
- Cache repeated requests.
- Reduce concurrency if necessary.
For WebSocket clients, avoid aggressive reconnect loops. A connection failure followed by hundreds of immediate reconnect attempts can create an additional rate-limit problem.
What Happens If I Exceed My CoinAPI Limits?
First, identify what happened.
Common responses can include:
429 Too Many Requests— rate or concurrency restriction403 Forbidden— can indicate insufficient access, permissions, or another account/product restriction
Do not assume every 403 means you have simply exhausted a quota.
Next, check your API BRICKS Console and application logs to determine:
- Remaining credits
- Request volume
- Concurrency
- Protocol usage
- Response headers
- Recent errors
Then adjust your application or account setup accordingly.
Depending on the issue, you may need to:
- Reduce request frequency
- Reduce concurrency
- Cache more data
- Switch continuous workloads from REST to WebSocket
- Move bulk historical workloads to Flat Files
- Add Usage Credits
- Choose a different committed plan
- Discuss higher-throughput or custom-limit requirements with CoinAPI
CoinAPI can review custom requirements case by case.
How Do I Request Higher Limits?
If you're running high-volume queries, handling many symbols across multiple exchanges, or operating large production pipelines, your requirements may exceed the defaults of a standard setup.
Instead of relying on hard-coded assumptions about overage or quota increases, review your actual usage first.
Use the API BRICKS Console to understand your current consumption, then contact CoinAPI if you need:
- Higher throughput
- Additional FIX connectivity
- Larger committed usage
- Enterprise infrastructure
- Custom connectivity or deployment requirements
For current pricing and plan options, use the Market Data API pricing page.
Build with CoinAPI
If you're backfilling historical data, running real-time models across multiple markets, or scaling a cross-exchange trading system, choose the CoinAPI access method that matches the workload instead of trying to force everything through REST.
👉 Talk to CoinAPI about volume pricing and higher-throughput requirements.
