PDF and image API pricing — you pay for renders, not for seats

Auto top-up: no hard stop, no overage bill

Paid plans are never billed for overage. Instead, when fewer than 200 renders are left in your workspace — included renders plus any prepaid ones — we add 1,000 renders at your plan's top-up price so your renders keep working. Stripe charges your card within about 24 hours, the renders are available at once, and you get an email for every top-up.

• Price per top-up of 1,000 renders: €6 on Starter, €4 on Growth, €3 on Pro, €2 on Scale, from €1.20 on Enterprise — all excluding VAT.
• Monthly top-up limit. The most your workspace can spend per cycle on plan plus top-ups. It defaults to twice your plan's monthly price and you can change it in the dashboard; 0 turns top-ups off. On Growth, for example, the default limit of €118 leaves €59 for top-ups — up to 14 top-ups, or 14,000 extra renders, per cycle.
• Order of use. Included renders first, then prepaid renders with the earliest expiry. Top-up renders roll over and expire 12 months after purchase; included renders reset every cycle.
• One at a time. A new top-up is only added after the previous one has been paid. If a payment fails, no further top-ups are added until it succeeds.
• When nothing can be added — limit reached, top-ups off, or a payment outstanding — and the renders run out, live renders fail with 402 render_limit_reached until the next period. Test keys keep working, so development is never blocked.
• You are told in time. Email and the usage.threshold_reached webhook at 50 %, 80 % and 100 % of the included renders, and when the limit stops further top-ups.

The API calls top-ups render_blocks and the limit spend_cap_cents; both show up in GET /v1/account. The contractual wording is in section 6 of the Terms of Service.

What counts as a render

One render is one generated document of up to 50 pages, or one image at one output size. Billing by the document rather than by the page keeps the cost of a long report predictable, and the 50-page unit keeps thousand-page exports from being priced like a one-page invoice.

Examples: a 12-page invoice is one render, and so is the same invoice as a Factur-X e-invoice; a 120-page report is three renders; a social image in two sizes is two renders. A signed render link is billed once, however often it is fetched: put one in an og:image tag and the crawlers, chat apps and timelines that load it a thousand times cost you a single render. The number billed is recorded per render in billed_renders and in the X-Billed-Renders response header, so your own cost dashboard can reconcile it.