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

PlanRate LimitWindow
Free10 requestsper minute (sliding)
Starter50 requestsper minute (sliding)
Pro50 requestsper minute (sliding)
Business500 requestsper 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.")
AttemptWait Before Retry
1st retry1 second
2nd retry2 seconds
3rd retry4 seconds
4th retry8 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

ScopeBehavior
Per API keyEach key has an independent counter. Multiple keys under the same account do not share a bucket.
Sliding windowThe window rolls continuously — it does not reset at a fixed clock boundary.
Applies before credit deductionRate limit is checked before any credits are reserved. A 429 response never deducts a credit.
Isolated per userRedis 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.