Definition

A burst limit sets the maximum number of API requests or messages that a user, application, or system can send to an API endpoint during a short window of time (usually measured in seconds). While long-term quotas (per-minute, per-hour, or daily) manage sustained access, burst limits specifically regulate momentary spikes in traffic, protecting the underlying system from instability.

On the API BRICKS platforms (such as CoinAPI and FinFeedAPI), burst limits ensure stability and predictable performance during traffic spikes. For example:
An API key may allow up to 100 requests within any rolling 10-second window. If this threshold is momentarily exceeded, requests are blocked or delayed until activity falls below the burst limit.

Key Points:

- Short-term control: Limits apply to brief timeframes (e.g., 10–100 requests per 1–10 seconds).
- Algorithms involved: Token bucket or leaky bucket algorithms often enforce these limits.
- Rolling window: Burst limits typically use a rolling (sliding) window.

Why Burst Limiting Exists 

- Prevents sudden server overloads that may cause slowdowns or outages.
- Ensures fair resource allocation—no single client can monopolize capacity.
- Deters abusive or buggy clients from overwhelming shared infrastructure.
- Maintains low-latency API responses during periods of high demand.

Burst Limit vs. Overall Rate Limit

| | Burst Limit | Overall Rate Limit / Quota |
|------------------------|-----------------------------|-----------------------------------|
| Purpose | Control short-term spikes | Regulate sustained usage |
| Example | 20 requests per second | 1,000,000 requests per month |
| Scope | Seconds/minutes (rolling) | Per-hour, per-day, per-month |
| Block Condition | Too many requests, too fast | Too many requests, too long |

Error Handling and Throttling

- The API returns an HTTP 429 Too Many Requests error.
- Response headers (like X-RateLimit-Remaining, X-RateLimit-Reset) indicate when requests can resume.
- Persistent overages may trigger stricter throttling or a temporary ban.

Developer Tip: Always handle 429 errors gracefully, use header information, and slow down request rates automatically in client code.

Best Practices for Developers

- Use exponential backoff and retry logic on 429 errors.
- Distribute requests over time—avoid simultaneous mass requests.
- Monitor quota/limit headers in every API response.
- Utilize SDK libraries (API BRICKS SDKs) with built-in rate limit handling.

Customization and Limit Increases

Need custom burst capacity? 
Enterprise/special-use cases can request higher burst limits. Contact API BRICKS Support or your account manager for evaluation and upgrade options.

Use Case Examples

| Scenario | Impact If Exceeded | Best Practice |
|-----------------------------|---------------------------------------|--------------------------------------|
| Sudden batch job starts | Requests blocked until window resets | Throttle jobs, add delay per request |
| High-frequency trading | Critical orders/data delayed/dropped | Real-time pacing, monitor headers |3:56| Dashboard auto-refresh | Excessive refreshes get throttled | Stagger or debounce refresh actions |

Summary Table: Typical Burst Limits

| Plan | Typical Burst Limit* | Reset Window | Notes/Reference |
|-------------|-----------------------|-----------------|-------------------------------------------------------------------|
| Free Tier | 5 req/sec | 1 sec | CoinAPI Docs |
| Enterprise | 100+ req/sec | 10 sec | Customizable via support |
| Flat Files | N/A (file download) | — | — |*Subject to change—please check documentation for your plan or ask support.

Further Reading & References

- CoinAPI Rate Limiting Guide
- FinFeedAPI Rate Limit Glossary
- CoinAPI Blog: API Rate Limits & Credit Guide
- API BRICKS SDKs
- API BRICKS Acceptable Usage Policy