Limits und Verbrauch
Rate-Limits
Anfragen, die Arbeit auslösen, sind pro Workspace begrenzt: jedes POST unter /renders (einzelne Renderings und Batches), unter /pdf (Zusammenführen, Schützen, Wasserzeichen, Umwandeln und Info) und unter /compat/apitemplate. Das Limit ist ein Token-Bucket: Seine Größe und seine Nachfüllrate pro Sekunde entsprechen beide den Anfragen pro Sekunde des Plans. Kurze Spitzen bis zu dieser Größe kommen also durch, und ein gleichmäßiger Strom wird auf die Rate begrenzt. Alle Schlüssel eines Workspace, Live und Test, teilen sich den Bucket, ebenso die App.
Lesende Anfragen (GET /renders/{id}, GET /jobs/{id}, das Auflisten von Vorlagen) und die übrigen schreibenden (Vorlagen, Webhooks, Dateien) sind nicht begrenzt. Das Abfragen eines eingereihten Renderings löst also nie das Limit aus. Ein Batch nimmt ein Token, gleich wie viele Einträge er hat.
Jede begrenzte Antwort trägt den aktuellen Stand:
RateLimit-Limit: 15
RateLimit-Remaining: 12
RateLimit-Reset: 1
RateLimit-Limit ist die Größe des Buckets, RateLimit-Remaining, wie viele Anfragen er gerade hält, und RateLimit-Reset die Sekunden, bis er wieder voll ist.
Oberhalb des Limits antwortet die API mit 429 rate_limited, Retry-After in Sekunden (die Zeit, bis wieder eine Anfrage erlaubt ist, mindestens 1) und der Größe des Buckets in limit. Warten Sie so lange und wiederholen Sie die Anfrage mit demselben Idempotenz-Schlüssel; ein 429 wird nicht als Antwort des Schlüssels gespeichert. Die SDKs tun das automatisch. Wenn Sie regelmäßig an das Limit stoßen, senden Sie die Arbeit als Batch: eine Anfrage, bis zu 1.000 Dokumente.
Test-Schlüssel im Free-Plan haben ein zweites Limit von 30 Anfragen pro Minute. Die Header beschreiben dann den der beiden Buckets, der näher an leer ist.
Plan-Limits
| Free | Starter | Pro | Business | |
|---|---|---|---|---|
| Preis | 0 € | 19 € im Monat oder 180 € im Jahr | 59 € im Monat oder 588 € im Jahr | 179 € im Monat oder 1.788 € im Jahr |
| Einheiten pro Monat | 100 | 3.000 | 15.000 | 60.000 |
| Mehrverbrauch | keiner, Renderings stoppen | 7 € / 1.000 Einheiten | 5 € / 1.000 Einheiten | 4 € / 1.000 Einheiten |
| Anfragen pro Sekunde | 1 | 5 | 15 | 40 |
| Gleichzeitige Renderings | 1 | 3 | 10 | 30 |
| Seiten pro PDF | 20 | 200 | 500 | 1.000 |
| Größe der Ausgabedatei | 10 MB | 50 MB | 100 MB | 250 MB |
| Aufbewahrung der Ausgaben (Aufbewahrung) | 1 Tag | 30 Tage | 365 Tage | ohne Limit |
| Vorlagen | 5 | ohne Limit | ohne Limit | ohne Limit |
| Workspaces | 1 | 3 | 10 | ohne Limit |
| Mitglieder | 1 | 3 | 10 | ohne Limit |
| Webhook-Endpunkte | 1 | 5 | ohne Limit | ohne Limit |
| Eigene Schriften | keine | 5 | ohne Limit | ohne Limit |
Release Channels pro Vorlage, neben published | keine | 2 | 10 | 10 |
| Canary-Releases | nein | nein | ja | ja |
| Render-Anfragen aufbewahren | nein | bis 24 Stunden | bis 7 Tage | bis 7 Tage |
| Post-Processing und PDF-Tools | nein | ja | ja | ja |
| Word- und PowerPoint-Vorlagen, Office zu PDF | nur anlegen und als PDF test-rendern | ja | ja | ja |
| E-Rechnungen (ZUGFeRD, Factur-X) | Test-Renderings, 20 pro Tag | ja; Test-Renderings, 100 pro Tag | ja; Test-Renderings, 500 pro Tag | ja; Test-Renderings, 2.000 pro Tag |
| Eigener Speicher | nein | nein | ja | ja |
| Testmarkierung auf Test-Renderings | ja | nur auf E-Rechnungen | nur auf E-Rechnungen | nur auf E-Rechnungen |
Die Einheiten, der Plan und seine Limits gehören zur Organisation: Alle ihre Workspaces teilen sie. Aktuelle Preise und den vollständigen Vergleich finden Sie auf der Preisseite.
Gleichzeitige Renderings gibt an, wie viele eingereihte Renderings eines Workspace (asynchrone Renderings, Batch-Einträge und synchrone Renderings, die in den Hintergrund gewandert sind) zur selben Zeit laufen. Weitere Renderings warten in der Warteschlange; sie werden nicht abgelehnt. Eine synchrone Anfrage wartet nicht auf dieses Limit, nur auf einen freien Render-Slot (synchron oder asynchron).
Release Channels und Canaries erklärt die Seite Release Channels.
Ein Dokument, das das Seiten- oder Größenlimit überschreitet, schlägt mit 422 page_limit_exceeded oder 422 output_too_large fehl und kostet nichts. Eine Funktion, die der Plan nicht enthält, ergibt 403 forbidden mit ihrem Namen in feature; Post-Processing, die PDF-Tools und die Office-Umwandlung werden im Free-Plan auch mit einem Test-Schlüssel abgelehnt. Eine sechste Vorlage im Free-Plan wird schon beim Anlegen abgelehnt.
Einheiten
| Was | Einheiten |
|---|---|
| PDF, 1–5 Seiten | 1 |
| PDF, je weitere 5 Seiten oder ein Teil davon | +1 (6–10 Seiten: 2, 11–15 Seiten: 3, 200 Seiten: 40) |
| Bild (PNG, JPG, WebP) | 1 |
Word- oder PowerPoint-Dokument (docx, pptx) aus einer Office-Vorlage | 1 |
| PDF aus einer Office-Vorlage | wie jedes PDF: 1 je angefangene 5 Seiten |
POST /pdf/convert | wie jedes PDF: 1 je angefangene 5 Seiten des Ergebnisses, mit Test-Schlüssel 0 |
| Dedupliziertes Rendering | 0 |
Rendering mit Test-Schlüssel, Vorschau oder echtes Rendering im Editor, Offline-Validierung, POST /templates/{id}/validate | 0 |
| Fehlgeschlagenes Rendering | 0 |
Post-Processing-Schritt (Zusammenführen, Passwort, Wasserzeichen), im post eines Renderings oder über die PDF-Tools | je 0,5, mit Test-Schlüssel 0 |
Mit post.merge_after angehängte Seiten | 0: Gezählt werden nur die eigenen Seiten des Renderings |
E-Rechnung (post.einvoice oder von der Vorlage festgelegt) | +1 zusätzlich zum Rendering, mit Test-Schlüssel 0 |
POST /pdf/info | 0 |
| Eine Kopie in den eigenen Bucket des Workspace | 0 |
Post-Processing, E-Rechnungen, Live-Renderings von Word- und PowerPoint-Vorlagen und die Office-Umwandlung setzen den Starter-Plan oder höher voraus. Im Free-Plan erzeugen Test-Renderings bis zu 20 E-Rechnungen pro Tag, mit der Testmarkierung, und Test-Renderings von Word- und PowerPoint-Vorlagen nur das PDF mit der Testmarkierung; eine Anfrage nach docx oder pptx beantwortet die API mit 403 test_output_unavailable. In den bezahlten Plänen sind Test-Renderings ohne Markierung, außer E-Rechnungen: Diese tragen in jedem Plan die Testmarkierung und zählen gegen die Tageszahl in der Tabelle oben.
Jedes Rendering meldet seine Kosten im Feld units und in X-Units-Charged; X-Units-Remaining ist das, was der Organisation in der Periode bleibt, einschließlich Prepaid-Einheiten.
Abrechnungsperioden
Die monatlichen Einheiten gehören zu einer Abrechnungsperiode, die zu Ihrem Abonnement passt: Sie beginnt an dem Tag, an dem Sie abonniert haben, und verlängert sich jeden Monat an diesem Tag, an denselben Tagen, an denen Stripe abrechnet. Ein Upgrade beginnt am Tag des Upgrades eine neue Periode mit den Einheiten des neuen Plans; ein Downgrade wirkt, wenn die laufende Periode endet. Im Free-Plan ohne Abonnement sind die Perioden Kalendermonate. Perioden zählen in ganzen Tagen in UTC.
Wenn die Einheiten aufgebraucht sind
- Free-Plan: Live-Renderings stoppen bis zur nächsten Periode mit
402 quota_exceeded; das Problem nennt das Ende der Periode inperiod_end. Ein Live-Batch braucht mindestens so viele verbleibende Einheiten, wie er Einträge hat. Test-Schlüssel funktionieren weiter. - Bezahlte Pläne: Renderings laufen weiter, zuerst mit Ihren Prepaid-Einheiten, dann als Mehrverbrauch, abgerechnet pro 1.000 Einheiten mit der nächsten Rechnung. Prepaid-Einheiten kaufen Inhaber als Pakete auf der Seite Abrechnung (Prepaid-Pakete), zum Mehrverbrauchspreis des Plans; sie werden nach den monatlichen Einheiten genutzt und verfallen nie.
- Ausgabenlimit: Zum Schutz vor einer außer Kontrolle geratenen Schleife endet der Mehrverbrauch beim Dreifachen des monatlichen Planpreises: 8.142 Einheiten Mehrverbrauch im Starter-Plan, 35.400 im Pro-Plan und 134.250 im Business-Plan, zusätzlich zu den enthaltenen und den Prepaid-Einheiten. Danach antworten Live-Renderings mit
402 quota_exceededund dem Limit inhard_cap_units, bis die nächste Periode beginnt oder Sie ein Paket kaufen, das das Limit um seine Einheiten erhöht. Die Seite Verbrauch zeigt das Limit. - Webhook-Endpunkte, die sie abonniert haben, erhalten
quota.warningbei 80 % der enthaltenen Einheiten undquota.exceeded, wenn sie aufgebraucht sind, jeweils einmal pro Periode (Kontingent-Ereignisse); die Inhaber, die Admins und die Rechnungs-E-Mail-Adresse erhalten zusätzlich eine E-Mail.
Verbrauch lesen
GET /v1/usage (Scope account:read) liefert die aktuelle Periode der Organisation oder mit ?period=YYYY-MM die Periode, die in diesem Monat begann. overage_balance sind Ihre verbleibenden Prepaid-Einheiten, hard_cap_units das Ausgabenlimit der aktuellen Periode (null im Free-Plan):
{
"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 zählt Einheiten und Renderings pro UTC-Tag, by_template Einheiten pro Slug der Vorlage (html und url für Renderings ohne Vorlage). Einheiten können Bruchteile sein (0.5 für einen Post-Processing-Schritt). Beide werden aus dem Render-Protokoll gezählt, das seine Einträge 13 Monate aufbewahrt; ein älterer Zeitraum antwortet daher mit seinen Summen und ohne sie.
GET /v1/account liefert den Workspace (mit seiner region), die Organisation, den Plan mit seinen Limits sowie Beginn, Ende und Einheiten der aktuellen Periode. Auf der Kommandozeile zeigt formfeed whoami beides.