> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blinkpdf.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Blink PDF API Rate Limits, Concurrency & Monthly Quotas
> Understand Blink PDF's per-plan rate limits, concurrency caps, daily quotas, and how to handle 429 responses gracefully in your integration.
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](/plans/pricing#how-billing-works-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/`](/concepts/markdown-rendering) 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](/plans/pricing#how-billing-works-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 theme={null}
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:
```python theme={null}
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](mailto:sales@blinkpdf.io) to discuss an Enterprise arrangement with dedicated capacity and custom throughput agreements.