Rate Limits
All API requests are rate-limited per API key to protect service stability and ensure fair usage across all users. Limits are enforced using a sliding window algorithm backed by Redis, so they apply to rolling 60-second windows — not fixed clock-minute resets.
Limits by Plan
| Plan | Rate Limit | Window |
|---|---|---|
| Free | 10 requests | per minute (sliding) |
| Starter | 50 requests | per minute (sliding) |
| Pro | 50 requests | per minute (sliding) |
| Business | 500 requests | per second (dedicated) |
Rate limits are enforced per API key, not per account. If you have multiple API keys under the same account, each key has its own independent limit bucket.
How the Sliding Window Works
Unlike fixed-window counters that reset at the top of every minute, the sliding window tracks requests over the last 60 seconds at all times. This prevents burst abuse that fixed windows allow at window boundaries (e.g. 10 requests at 00:59 + 10 more at 01:01 = 20 requests in 2 seconds).
t=0s t=30s t=60s t=90s
|──────────|──────────|──────────|
↑ request at t=45s
window: [t=−15s … t=45s] ← 60 seconds rolling
Every incoming request evaluates the count of requests within the past 60 seconds. If that count meets or exceeds the limit, the request is rejected with 429.
Rate Limit Response
When your request exceeds the limit, the API returns:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
{
"error": "Rate limit exceeded (10 req/min). Retry after 2025-01-01T12:00:30.000Z."
}
The error message includes:
- Your plan's request limit per minute
- An ISO 8601 timestamp indicating when the current window resets and a retry is safe
Handling 429 in Your Code
Always implement retry logic with exponential backoff when consuming the API at volume. Do not retry immediately — the window is rolling, so a tight retry loop will continue hitting the limit.
JavaScript
async function generateBarcode(apiKey, format, data, retries = 3) {
for (let attempt = 0; attempt < retries; attempt++) {
const response = await fetch(
`https://www.barcodegen.net/api/barcode/${format}/${encodeURIComponent(data)}`,
{ headers: { Authorization: `Bearer ${apiKey}` } }
);
if (response.ok) return response;
if (response.status === 429) {
const body = await response.json();
// Parse retry time from error message, or fall back to exponential backoff
const retryAfterMs = Math.pow(2, attempt) * 1000; // 1s, 2s, 4s
console.warn(`Rate limited. Retrying in ${retryAfterMs}ms…`);
await new Promise(resolve => setTimeout(resolve, retryAfterMs));
continue;
}
// Non-retryable error
const body = await response.json();
throw new Error(body.error);
}
throw new Error('Max retries reached after rate limiting.');
}
Python
import requests
import time
def generate_barcode(api_key, format, data, retries=3):
url = f"https://www.barcodegen.net/api/barcode/{format}/{data}"
headers = {"Authorization": f"Bearer {api_key}"}
for attempt in range(retries):
resp = requests.get(url, headers=headers)
if resp.status_code == 200:
return resp
if resp.status_code == 429:
wait = 2 ** attempt # 1s, 2s, 4s
print(f"Rate limited. Retrying in {wait}s…")
time.sleep(wait)
continue
resp.raise_for_status() # raise for other errors
raise Exception("Max retries reached after rate limiting.")
Recommended Backoff Strategy
| Attempt | Wait Before Retry |
|---|---|
| 1st retry | 1 second |
| 2nd retry | 2 seconds |
| 3rd retry | 4 seconds |
| 4th retry | 8 seconds |
Add a small random jitter (e.g. ±200ms) to prevent thundering herd problems when multiple workers retry simultaneously.
Batch Generation
If you need to generate many barcodes at once, the Pro and Business plans support batch requests of up to 100 barcodes per request. Batching reduces the number of individual API calls, making it the most effective way to stay within rate limits at high volume.
See the Quick Start for batch endpoint details.
High-Volume Use Cases
Starter / Pro Plans (50 req/min)
At 50 requests per minute, you can sustain up to 72,000 requests per day without hitting rate limits. For workloads that spike beyond this — such as bulk label printing jobs or nightly batch exports — consider:
- Spreading requests across multiple API keys (each key has its own limit bucket).
- Using the batch endpoint (Pro plan) to encode up to 100 barcodes per call.
- Queuing generation tasks and draining the queue at a controlled rate (e.g. one request per 1.2 seconds).
Business Plan (500 req/s dedicated)
The Business plan provides a dedicated rate limit of 500 requests per second, suitable for real-time label generation in logistics and factory environments. This limit is isolated per account and is not shared with other users.
Rate Limit Scope
| Scope | Behavior |
|---|---|
| Per API key | Each key has an independent counter. Multiple keys under the same account do not share a bucket. |
| Sliding window | The window rolls continuously — it does not reset at a fixed clock boundary. |
| Applies before credit deduction | Rate limit is checked before any credits are reserved. A 429 response never deducts a credit. |
| Isolated per user | Redis keys are namespaced by userUuid, so one user's traffic never affects another's limit. |
Relationship to Credits
Rate limits and credits are independent systems:
- Rate limits control how fast you can make requests (requests per unit time).
- Credits control how many total requests you can make in a billing period.
A request rejected by the rate limiter (429) does not consume a credit. Credit deduction only happens after the rate limit check passes and authentication succeeds.
Request
│
├─ Rate limit exceeded? → 429 (no credit consumed)
│
├─ Auth failed? → 401 (no credit consumed)
│
├─ Credits insufficient? → 402 (no credit consumed)
│
└─ All checks pass → 1 credit deducted → barcode generated
Frequently Asked Questions
Does the rate limit reset every 60 seconds at a fixed time? No. The sliding window evaluates the last 60 seconds from the moment of each request. There is no fixed reset boundary.
Do all API keys under my account share the same rate limit? No. Each API key has its own independent limit counter. You can distribute load across multiple keys (within your plan's key limit) to increase effective throughput.
I'm getting 429 even though I'm well under the limit. Why? Very short bursts (e.g. 10 requests in 100ms) can trigger the limit because the sliding window is precise to the millisecond. Spread requests over time or add a small delay between calls.
Does a 429 response count against my credit balance? No. Credits are never deducted for rate-limited requests.
I need more than 50 req/min. What are my options? Upgrade to the Business plan for a dedicated 500 req/s limit, use the batch endpoint (Pro), or distribute requests across multiple API keys.
Related
- Quick Start — Authentication, endpoints, and first request
- Pricing & Credits — Plan comparison and credit deduction model
- Supported Formats — Full barcode format reference