Blink PDF API Rate Limits, Concurrency & Monthly Quotas

Blink PDF enforces rate limits to keep rendering quality consistent and fair for every customer. Limits are applied per API key and reset on a rolling basis. This page explains what each limit means, how to stay within it, and what to do when you hit one.

Limits by Plan

Plan	Sustained Rate	Concurrency	Max Input Size
Free	10 / min	1	128 KB
Pro	120 / min	10	2 MB
Business	600 / min	40	5 MB
Enterprise	Custom	Dedicated	Custom

There is no daily cap on any plan — usage is metered monthly in render units.

Understanding Each Limit

Sustained Rate

The sustained rate is the maximum number of render requests you can make in any 60-second window. POST /v1/render and POST /v1/templates/*/render share this bucket. Short bursts slightly above this rate may succeed, but requests that consistently exceed it will receive 429 Too Many Requests responses.

Concurrency

Concurrency controls how many render jobs can be in-flight simultaneously on your account (shared across POST /v1/render and template routes). A request occupies a concurrency slot from the moment the server accepts it until the PDF response is returned. If you hit the concurrency ceiling, new requests block until a slot frees up or return 429 depending on your client configuration.

If you need to render many PDFs quickly, pipeline your requests up to your concurrency limit rather than sending them sequentially. For example, a Pro account can keep 10 renders running at once, which is far more efficient than waiting for each one to finish before starting the next.

Validate has its own rate-limit bucket

POST /v1/render/validate is rate-limited per plan tier in its own bucket, kept independent from POST /v1/render. A burst of validation calls never spends your render throughput, and a burst of renders never throttles your validation — each can return 429 independently of the other. Validation still consumes no render units.

Max Input Size

The maximum size of the Markdown request body you can send in a single request. Requests that exceed this limit receive 413 Payload Too Large.

Input size limits apply to the request body, not the final PDF file size. Images staged out of band and referenced with blink://asset/<id> handles are fetched at render time and do not count toward this limit — only inline data: images and Markdown text do.

What Counts Toward Your Usage

Only successful renders consume render units. A render is counted only when the API returns a valid PDF response (HTTP 200) and its X-BlinkPDF-Billing header is counted — that includes both POST /v1/render and POST /v1/templates/*/render. Cache and idempotent replays on /v1/render (deduped-cache / deduped-idempotent) are not billed.

What Does NOT Count

The following never consume render units:

GET /health and any health-check endpoints
POST /v1/render/validate (though it has its own rate-limit bucket, above)
Font, theme, and style-target catalog listings
Requests that return any error status (400, 401, 402, 405, 413, 422, 429, 5xx)
Retried requests that ultimately fail

Handling HTTP 429 Too Many Requests

When you exceed your rate limit, the API responds with:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{
  "error": "rate_limited",
  "detail": "You have exceeded the sustained rate limit for your plan."
}

Retry Strategy

Use exponential backoff with jitter when retrying after a 429. A simple recipe:

wait = base_delay * (2 ^ attempt) + random_jitter

For example, in Python:

import time
import random
import httpx

def render_pdf(client, payload, max_attempts=5):
    base_delay = 1.0  # seconds

    for attempt in range(max_attempts):
        response = client.post("/v1/render", json=payload)

        if response.status_code == 200:
            return response.content

        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", base_delay))
            jitter = random.uniform(0, 1)
            wait = max(retry_after, base_delay * (2 ** attempt)) + jitter
            time.sleep(wait)
            continue

        response.raise_for_status()

    raise RuntimeError("Exceeded maximum retry attempts")

Always respect the Retry-After header value. Retrying immediately after a 429 will not succeed and may result in your key being temporarily throttled further.

Monthly Spending Cap

On Pro and Business plans, you can set a configurable monthly spending cap in your account dashboard. Each paid plan also has a fixed hard cap at 2× its included volume. When your usage reaches the cap:

The API returns a clear 402 error with the reason spend_cap_reached
No further charges are incurred for that billing period
The cap resets automatically at the start of your next billing cycle

The spending cap is optional. If you don’t set one, your account follows soft overage billing — you’re never cut off, but overage charges apply beyond your included quota.

Upgrading for Higher Limits

If you consistently hit rate or concurrency limits, the most effective solution is to upgrade your plan. Limits increase significantly with each tier. Need limits beyond the Business plan? Contact our team to discuss an Enterprise arrangement with dedicated capacity and custom throughput agreements.

Get Started

Core Concepts

Guides

MCP Server

Configuration

Plans & Limits

Help

Blink PDF API Rate Limits, Concurrency & Monthly Quotas

Limits by Plan

Understanding Each Limit

Sustained Rate

Concurrency

Validate has its own rate-limit bucket

Max Input Size

What Counts Toward Your Usage

What Does NOT Count

Handling HTTP 429 Too Many Requests

Retry Strategy

Monthly Spending Cap

Upgrading for Higher Limits

​Limits by Plan

​Understanding Each Limit

​Sustained Rate

​Concurrency

​Validate has its own rate-limit bucket

​Max Input Size

​What Counts Toward Your Usage

​What Does NOT Count

​Handling HTTP 429 Too Many Requests

​Retry Strategy

​Monthly Spending Cap

​Upgrading for Higher Limits

Limits by Plan

Understanding Each Limit

Sustained Rate

Concurrency

Validate has its own rate-limit bucket

Max Input Size

What Counts Toward Your Usage

What Does NOT Count

Handling HTTP 429 Too Many Requests

Retry Strategy

Monthly Spending Cap

Upgrading for Higher Limits