Limits and usage

Rate limits

Requests that start work are limited per workspace: every POST under /renders (single renders and batches), under /pdf (merge, protect, watermark, convert and info) and under /compat/apitemplate. The limit is a token bucket: its size and its refill rate per second are both the plan's requests per second, so short bursts up to that size pass, and a steady stream is held to the rate. All keys of a workspace, live and test, share the bucket, and so does the app.

Reads (GET /renders/{id}, GET /jobs/{id}, listing templates) and the other writes (templates, webhooks, files) are not limited, so polling a queued render never trips the limit. A batch takes one token, however many items it has.

Every limited response carries the current state:

RateLimit-Limit: 15
RateLimit-Remaining: 12
RateLimit-Reset: 1

RateLimit-Limit is the size of the bucket, RateLimit-Remaining how many requests it holds right now, and RateLimit-Reset the seconds until it is full again.

Above the limit the API answers 429 rate_limited with Retry-After in seconds (the time until one request is allowed again, at least 1) and the bucket's size in limit. Wait that long and retry with the same idempotency key; a 429 is not stored as the key's answer. The SDKs do this automatically. If you hit the limit regularly, send the work as a batch: one request, up to 1,000 documents.

Test keys on the Free plan have a second limit of 30 requests per minute. The headers then describe whichever of the two buckets is closer to empty.

Plan limits

	Free	Starter	Pro	Business
Price	€0	€19 a month or €180 a year	€59 a month or €588 a year	€179 a month or €1,788 a year
Units per month	100	3,000	15,000	60,000
Overage	none, renders stop	€7 / 1,000 units	€5 / 1,000 units	€4 / 1,000 units
Requests per second	1	5	15	40
Concurrent renders	1	3	10	30
Pages per PDF	20	200	500	1,000
Output file size	10 MB	50 MB	100 MB	250 MB
Outputs kept (retention)	1 day	30 days	365 days	no limit
Templates	5	no limit	no limit	no limit
Workspaces	1	3	10	no limit
Members	1	3	10	no limit
Webhook endpoints	1	5	no limit	no limit
Custom fonts	none	5	no limit	no limit
Release channels per template, besides published	none	2	10	10
Canary releases	no	no	yes	yes
Keep render requests	no	up to 24 hours	up to 7 days	up to 7 days
Post-processing and PDF tools	no	yes	yes	yes
Word and PowerPoint templates, office to PDF	create and test-render to PDF only	yes	yes	yes
E-invoices (ZUGFeRD, Factur-X)	test renders, 20 a day	yes; test renders, 100 a day	yes; test renders, 500 a day	yes; test renders, 2,000 a day
Bring your own storage	no	no	yes	yes
Test mark on test renders	yes	only on e-invoices	only on e-invoices	only on e-invoices

The units, the plan and its limits belong to the organisation: all its workspaces share them. Current prices and the full comparison are on the pricing page.

Concurrent renders is how many queued renders of one workspace (async renders, batch items and sync renders that went to the background) render at the same time. Further renders wait in the queue; they are not rejected. A sync request does not wait for this limit, only for a free render slot (sync or async).

Release channels and canaries are explained in Release channels.

A document that exceeds the page or size limit fails with 422 page_limit_exceeded or 422 output_too_large and costs nothing. A feature the plan does not include answers 403 forbidden with its name in feature; post-processing, the PDF tools and office conversion are refused on Free with a test key too. A sixth template on the Free plan is refused when it is created.

Units

What	Units
PDF, 1–5 pages	1
PDF, each further 5 pages or part of them	+1 (6–10 pages: 2, 11–15 pages: 3, 200 pages: 40)
Image (PNG, JPG, WebP)	1
Word or PowerPoint document (docx, pptx) from an office template	1
PDF from an office template	as any PDF: 1 per started 5 pages
POST /pdf/convert	as any PDF: 1 per started 5 pages of the result, 0 with a test key
Deduplicated render	0
Render with a test key, preview or true render in the editor, offline validation, POST /templates/{id}/validate	0
Failed render	0
Post-processing step (merge, password, watermark), in a render's post or through the PDF tools	0.5 each, 0 with a test key
Pages appended by post.merge_after	0: only the render's own pages are counted
E-invoice (post.einvoice, or declared by the template)	+1 on top of the render, 0 with a test key
POST /pdf/info	0
A copy into the workspace's own bucket	0

Post-processing, e-invoices, live renders of Word and PowerPoint templates and office conversion need the Starter plan or higher. On the Free plan, test renders make up to 20 e-invoices a day, with the test mark, and test renders of Word and PowerPoint templates produce the PDF with the test mark only; asking for docx or pptx answers 403 test_output_unavailable. On the paid plans, test renders are unmarked except for e-invoices: those carry the test mark on every plan and count against the day's number in the table above.

Every render reports its cost in the units field and in X-Units-Charged; X-Units-Remaining is what the organisation has left in the period, including prepaid units.

Billing periods

The monthly units belong to a billing period that matches your subscription: it starts on the day you subscribed and renews on that day every month, the same days Stripe invoices. An upgrade starts a new period on the day of the upgrade with the new plan's units; a downgrade takes effect when the running period ends. On the Free plan without a subscription, periods are calendar months. Periods are counted in whole days in UTC.

When units run out

• Free plan: live renders stop with 402 quota_exceeded until the next period; the problem names the end of the period in period_end. A live batch needs at least as many units left as it has items. Test keys keep working.
• Paid plans: renders continue, first from your prepaid units, then as overage, billed per 1,000 units with the next invoice. Prepaid units are bought as packs by owners on the Billing page (Prepaid packs), at the plan's overage rate; they are used after the monthly units and never expire.
• Spending limit: to protect you from a runaway loop, overage stops at three times the plan's monthly price: 8,142 units of overage on Starter, 35,400 on Pro and 134,250 on Business, on top of the included and prepaid units. Then live renders answer 402 quota_exceeded with the limit in hard_cap_units until the next period starts or you buy a pack, which raises the limit by its units. The Usage page shows the limit.
• Webhook endpoints that subscribed to them receive quota.warning at 80 % of the included units and quota.exceeded when they are used up, each once per period (quota events); the owners and admins and the billing email address get an email as well.

Reading usage

GET /v1/usage (scope account:read) returns the organisation's current period, or with ?period=YYYY-MM the period that started in that month. overage_balance is the prepaid units you have left, and hard_cap_units the spending limit of the current period (null on Free):

{
  "period": "2026-09",
  "period_start": "2026-09-07",
  "period_end": "2026-10-07",
  "included": 15000,
  "used": 4210,
  "overage_used": 0,
  "overage_balance": 0,
  "hard_cap_units": 50400,
  "daily": [{ "date": "2026-09-07", "units": 128, "renders": 96 }],
  "by_template": [{ "template": "invoice", "units": 3980 }]
}

daily counts units and renders per UTC day, by_template units per template slug (html and url for renders without a template). Units can be fractions (0.5 for a post-processing step). Both are counted from the render log, which keeps its entries for 13 months, so a period older than that answers with its totals and without them.

GET /v1/account returns the workspace (with its region), the organisation, the plan with its limits, the current period's dates and its units. From the command line, formfeed whoami shows both.