Ist Rechnungs-PDF API ein eigener Endpoint?

Nein. Diese Seite erklärt, wie Sie /api/v1/pdf/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.

Invoicing and finance

Rechnungs-PDF API für Backend-Systeme

Rechnungs-PDF API: aus Rechnungsdaten konsistente PDF-Rechnungen erzeugen, ohne Browser-Rendering und mit klarer Grenze zwischen gPdf-Rendering und Ihren Geschäftsdaten.

PRIMÄRE API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEME Billing-Backend / ERP / Buchhaltungssystem / SaaS-App

Im Playground testen → Dokumentation lesen

Aufgabe im Workflow

aus Rechnungsdaten konsistente PDF-Rechnungen erzeugen. Ihr System liefert Daten und Regeln; gPdf rendert daraus reproduzierbare PDF-Ausgabe.

Wann diese API passt

Ihr System besitzt die Daten für Rechnungs-PDFs bereits und braucht eine PDF-Antwort.
Sie wollen JSON Render über /api/v1/pdf/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 brauchen willkürliche HTML-zu-PDF-Konvertierung mit Chromium.
Sie erwarten, dass gPdf geschäftliche oder rechtliche Bedeutung aus Rohdaten ableitet.
Ein veröffentlichter template_id-Vertrag ist passender als Layoutdaten pro Request.

Welchen Endpoint aufrufen

PRIMÄR

/api/v1/pdf/render

JSON Render ist der Standardpfad für diesen Workflow.

SEKUNDÄR 1

/api/v1/template-render

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

SEKUNDÄR 2

/api/v1/e-invoice/render

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

Minimaler Request

/api/v1/pdf/render - minimaler Request für Rechnungs-PDFs.

{
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 18, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "text",
          "x": 20,
          "y": 42,
          "content": "Bill to: Example Customer\nAmount due: USD 245.00",
          "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "line",
          "x1": 20,
          "y1": 62,
          "x2": 190,
          "y2": 62
        }
      ]
    }
  ]
}

Was gPdf übernimmt

Rendering von Rechnungs-PDFs aus strukturierten Requests.
PDF-Seiten, Text, Tabellen, Linien, Formen, Bilder und Vektor-Barcodes nach Bedarf.
Deterministische PDF-Ausgabe für Reprints, Audits und Backend-Automatisierung.
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.
Steuer-, Compliance-, Kunden- oder Plattformregeln vor dem Rendering.

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 Rechnungs-PDFs; die fachliche Richtigkeit bleibt bei Ihrem System.
Die Seite beschreibt den passenden gPdf-API-Pfad, keinen zusätzlichen workflow-spezifischen Endpoint.
Externe Zertifizierung, Akzeptanz und operative Freigaben liegen außerhalb des Renderers.

Wie dieser Workflow in gPdf passt

Rechnungs-PDF 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 JSON Render über /api/v1/pdf/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 Rechnungs-PDFs 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 Rechnungs-PDF API ein eigener Endpoint?: Nein. Diese Seite erklärt, wie Sie /api/v1/pdf/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.