Rechnungen, Berichte, Vertraege - ein POST, ein fertiges PDF mit Kopf- und Fusszeilen, Seitenzahlen und sauberen Umbruechen.
curl -H "x-api-key: KEY" -H "content-type: application/json" \
-d '{"html":"Rechnung 4711
","format":"A4"}' \
https://api.apiwerk.info/v1/pdf -o rechnung.pdf
Der Kunde will die Rechnung als PDF, dein System kann aber nur HTML. Also druckst du im Browser in eine Datei — und jedes Mal sitzt die Fußzeile woanders, die Tabelle bricht mitten in der Zeile um, und auf Seite zwei fehlt die Rechnungsnummer. Bei dreißig Rechnungen im Monat sind das dreißig kleine Handgriffe, die alle schiefgehen können.
format | Maße | Typischer Einsatz |
|---|---|---|
A5 | 148 × 210 mm | Beipackzettel, Gutscheine |
A4 | 210 × 297 mm | Rechnung, Angebot, Vertrag |
A3 | 297 × 420 mm | Pläne, breite Tabellen |
Letter | 216 × 279 mm | USA, Kanada |
Legal | 216 × 356 mm | US-Verträge |
Als Quelle nimmt die API entweder url oder html bis 2 MB, nie beides — sonst kommt ambiguous_input zurück. Andere Formatangaben werden stillschweigend zu A4: format=A2 erzeugt keinen Fehler, sondern eine A4-Seite. Die Ränder stehen ohne Angabe auf 12 mm rundum und lassen sich einzeln in CSS-Einheiten setzen, etwa margin_top: "25mm". Anders als im Browser-Druckdialog sind Hintergrundfarben und -bilder standardmäßig eingeschaltet; farbige Tabellenköpfe kommen also mit. Passt eine breite Tabelle trotzdem nicht, verkleinert scale zwischen 0,1 und 2 den ganzen Satzspiegel, und page_ranges gibt wie im Druckdialog einzelne Seiten aus, etwa 1-3,7.
Kopf- und Fußzeile sind eigene HTML-Schnipsel und werden nur ausgewertet, wenn du mindestens einen von beiden mitschickst. Chromium ersetzt darin fünf Klassen: date, title, url, pageNumber und totalPages. Zwei Stolpersteine, an denen fast jeder einmal hängt: Die Schnipsel erben dein Seiten-CSS nicht, Schriftgröße und Farbe musst du also inline setzen. Und die Zeilen sitzen im Seitenrand, nicht im Textbereich — was nicht in die voreingestellten 12 mm passt, wird abgeschnitten. Plane also margin_top beziehungsweise margin_bottom großzügiger, sobald die Zeile mehr als eine Zeile ist.
Seit dem 1. Januar 2025 gilt für Rechnungen zwischen inländischen Unternehmen der neu gefasste § 14 UStG: Eine „elektronische Rechnung“ ist nur noch eine Rechnung in einem strukturierten Format nach der Norm EN 16931 — in der Praxis XRechnung oder ZUGFeRD ab Version 2.0.1, wobei die Profile MINIMUM und BASIC-WL laut BMF nicht ausreichen. Ein PDF ist seitdem eine sonstige Rechnung. Solche strukturierten Rechnungen empfangen können muss jedes Unternehmen bereits heute.
Fürs Ausstellen gelten Übergangsfristen (§ 27 Abs. 38 UStG), die an das Jahr des Umsatzes anknüpfen:
Nicht betroffen sind Rechnungen an Privatkunden, Rechnungen ins Ausland, Kleinbetragsrechnungen bis 250 € (§ 33 UStDV) und Fahrausweise (§ 34 UStDV); Kleinunternehmer dürfen nach § 34a UStDV weiterhin sonstige Rechnungen ausstellen. Was diese API erzeugt, ist ein normales PDF — kein ZUGFeRD-Hybrid mit eingebettetem XML und kein PDF/A. Für die strukturierte Rechnung brauchst du zusätzlich einen XML-Erzeuger; das PDF bleibt dann das, was Mensch und Ablage lesen. Das hier ist keine Steuerberatung — den Einzelfall klärt dein Berater.
Mit HTML und CSS — der Vorlagen-Sprache, die dein Team schon kann. Was im Browser gut aussieht, wird als PDF gerendert: eigene Schriften, Logos, Tabellen, Seitenumbrüche per CSS. Kein proprietäres Vorlagen-Format.
Ja — eigene Kopf- und Fußzeilen-Vorlagen mit Seitenzahl, Datum und Titel, auf Wunsch ab Seite 2. Genau das, was Rechnungen und Berichte brauchen.
A4 als Standard, dazu Letter und weitere Formate, Hoch- und Querformat, einstellbare Ränder. Die Ausgabe ist ein normales PDF, das jeder Viewer öffnet.
Ja — dein System füllt die HTML-Vorlage mit den Rechnungsdaten und schickt sie an die API; zurück kommt das fertige PDF. Das funktioniert aus jeder Sprache, die HTTP kann, ohne PDF-Bibliothek im eigenen Code.
Über die üblichen CSS-Regeln wie page-break-inside: avoid — der Renderer ist ein echter Chromium, er verhält sich exakt wie der Druckdialog im Browser. Was dort stimmt, stimmt auch im PDF.
Aktuell ist alles in der Beta komplett kostenlos — keine Kreditkarte, keine Laufzeit. Nach dem Verkaufsstart beginnen die Tarife bei 4,50 € pro Monat (500 Aufrufe) — bewusst rund die Hälfte des üblichen Marktpreises. Wer in der Beta dabei ist, wird vor jeder Umstellung informiert.
E-Mail-Adresse in das Formular auf dieser Seite eintragen — der API-Schlüssel erscheint sofort, ohne Bestätigungs-Wartezeit. Damit hast du 1.000 Aufrufe pro Monat frei. Der Schlüssel wird als Hash gespeichert und nur einmal angezeigt, also direkt sicher ablegen.
Keine Kreditkarte, keine Wartezeit. E-Mail rein, Schlüssel raus.
Marktfuehrer: 9 $ für 500 Dokumente — wir starten bei der Haelfte.
| Stufe | Renders/Monat | später €/Monat |
|---|---|---|
| Frei | 50 | immer kostenlos |
| Start | 500 | 4,50 |
| Wachstum | 5.000 | 19,50 |
| Skala | 25.000 | 49,50 |
Alle vier Produkte · Betrieb in der EU · private Netze für Render-Ziele gesperrt
Verwandt: Screenshot-API · Bild-API · Website-Archiv · QR-Code-API · Alternative zu PDFShift
E-Mail eintragen, Schlüssel erscheint sofort auf der Seite. Kein Konto, keine Kreditkarte, keine Freischaltung durch uns.
Ein einziger HTTP-Aufruf mit deinem Schlüssel im Kopf — aus jeder Programmiersprache, jedem Framework, jedem Automatisierungswerkzeug.
Du bekommst sauberes JSON oder die fertige Datei zurück. Fehler kommen als klare deutsche Meldung, nicht als Rätsel.
curl -H "x-api-key: KEY" -H "content-type: application/json" \
-d '{"html":"<h1>Rechnung 4711</h1>","format":"A4"}' \
https://api.apiwerk.info/v1/pdf -o rechnung.pdf
Wir legen die Preise jetzt schon offen, damit du planen kannst. Beta-Nutzer werden rechtzeitig informiert, bevor sich etwas ändert — niemand wird automatisch in einen bezahlten Tarif überführt.
Alle Preise zuzüglich Umsatzsteuer. Monatlich kündbar, keine Mindestlaufzeit, keine Einrichtungsgebühr.