Ist ZUGFeRD API ein eigener Endpoint?

Nein. Diese Seite erklärt, wie Sie /api/v1/e-invoice/render und die zugehörigen gPdf APIs für diesen Workflow einsetzen.

Was muss mein System liefern?

Ihr System liefert Geschäftsdaten, Feldmapping, Validierung und alle Regeln vor dem Rendering. gPdf übernimmt die PDF-Erzeugung.

Wann sollte ich Template Render nutzen?

Nutzen Sie Template Render, wenn das Layout stabil ist und Aufrufer nur noch Daten über template_id und data[] senden sollen.

Was prüfe ich vor Produktion?

Testen Sie reale Daten, Grenzfälle, Validierung und die nachgelagerten Systeme, die das PDF lesen, drucken oder archivieren.

Compliance and archival

ZUGFeRD API für deutsche E-Rechnungsprozesse

ZUGFeRD API: ZUGFeRD PDF/A-3b mit eingebettetem EN 16931 CII XML erzeugen, ohne Browser-Rendering und mit klarer Grenze zwischen gPdf-Rendering und Ihren Geschäftsdaten.

PRIMÄRE API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTEME ERP / Billing-Backend / Deutscher Finanzworkflow / Compliance-Automatisierung

Im Playground testen → Dokumentation lesen

Aufgabe im Workflow

ZUGFeRD PDF/A-3b mit eingebettetem EN 16931 CII XML erzeugen. Ihr System liefert Daten und Regeln; gPdf rendert daraus reproduzierbare PDF-Ausgabe.

Wann diese API passt

Ihr System besitzt die Daten für ZUGFeRD-Rechnungen bereits und braucht eine PDF-Antwort.
Sie wollen E-Invoice Render über /api/v1/e-invoice/render statt eines browserbasierten HTML-zu-PDF-Flows nutzen.
Layout, Barcodes, Text und Metadaten sollen reproduzierbar aus strukturierten Daten entstehen.
Vor dem Produktivgang sollen Payloads im Playground oder in CI reproduzierbar geprüft werden.

Was sie nicht ersetzt

Sie erwarten, dass gPdf steuerliche oder rechtliche XML-Semantik aus unvollständigen Daten ableitet.
Sie brauchen einen nationalen E-Rechnungsstandard, der nicht im Capabilities-Endpoint steht.
Sie wollen nur ein normales PDF ohne E-Rechnungs-Paket.

Welchen Endpoint aufrufen

PRIMÄR

/api/v1/e-invoice/render

E-Invoice Render ist der Standardpfad für diesen Workflow.

SEKUNDÄR 1

/api/v1/e-invoice/capabilities

Nutzen Sie dies, wenn der Workflow den zugehörigen API-Pfad, einen Template-Vertrag oder eine Capability-Abfrage braucht.

Minimaler Request

/api/v1/e-invoice/render - minimaler Request für ZUGFeRD-Rechnungen.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "zugferd",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "ZUGFeRD invoice",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Was gPdf übernimmt

Rendering von ZUGFeRD-Rechnungen aus strukturierten Requests.
PDF-Seiten, Text, Tabellen, Linien, Formen, Bilder und Vektor-Barcodes nach Bedarf.
PDF/A-nahe Metadaten, Profile und Validierungsgrenzen gemäß öffentlichem API-Vertrag.
Einheitliche API-Fehlerfläche mit API-XXX-Code und req_id bei Fehlern.

Was Ihr System verantwortet

Fachliche Daten, Feldmapping und Semantik der Ausgabe.
Validierung, Idempotenz, Dateinamen, Speicherung und Nachverfolgung nach der Antwort.
Korrektheit des EN 16931 XML und Akzeptanztests beim Empfänger.

Produktions-Checkliste

Request IDs und Timeouts für produktive Aufrufe setzen.
Payloads gegen OpenAPI, Dokumentation oder Golden-PDF-Tests prüfen.
API-Basis-URL und Bearer Token konfigurierbar halten und nicht im Code speichern.
Kritische Layouts mit echten Daten und Randfällen testen.
Validierungs- und Reprint-Nachweise dort speichern, wo Ihr System sie braucht.

Aussagegrenzen

gPdf rendert ZUGFeRD-Rechnungen; die fachliche Richtigkeit bleibt bei Ihrem System.
Die Seite beschreibt den passenden gPdf-API-Pfad, keinen zusätzlichen workflow-spezifischen Endpoint.
Andere E-Rechnungsnamen sind nur nativ unterstützt, wenn der Capabilities-Endpoint sie aufführt.

Wie dieser Workflow in gPdf passt

ZUGFeRD API ist ein Produktionsworkflow auf Basis der öffentlichen gPdf-APIs. Der Request beschreibt die Ausgabe explizit: Daten, Layout, Einstellungen und die Teile, die als PDF gerendert werden sollen. gPdf übernimmt das Rendering, nicht die fachliche Entscheidung hinter den Daten.

API-Pfad und Verantwortungsgrenze

In der Regel ist E-Invoice Render über /api/v1/e-invoice/render der richtige Einstieg. Ihr System bleibt verantwortlich für Stammdaten, Validierung, Retention und fachliche Regeln. Dadurch bleibt der Vertrag klar: gPdf erzeugt das PDF, Ihre Anwendung steuert Bedeutung und Prozess.

Produktionsreife

Testen Sie ZUGFeRD-Rechnungen mit echten Daten, Druckern, Scannern, Validierern oder Empfängersystemen, je nach Workflow. Speichern Sie Request IDs und Validierungsnachweise so, dass Support, Audit und Reprint später nachvollziehbar bleiben.

FAQ

Ist ZUGFeRD API ein eigener Endpoint?: Nein. Diese Seite erklärt, wie Sie /api/v1/e-invoice/render und die zugehörigen gPdf APIs für diesen Workflow einsetzen.
Was muss mein System liefern?: Ihr System liefert Geschäftsdaten, Feldmapping, Validierung und alle Regeln vor dem Rendering. gPdf übernimmt die PDF-Erzeugung.
Wann sollte ich Template Render nutzen?: Nutzen Sie Template Render, wenn das Layout stabil ist und Aufrufer nur noch Daten über template_id und data[] senden sollen.
Was prüfe ich vor Produktion?: Testen Sie reale Daten, Grenzfälle, Validierung und die nachgelagerten Systeme, die das PDF lesen, drucken oder archivieren.