Ist Packzettel-PDF API ein eigener Endpoint?

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

Logistics and labels

Packzettel-PDF API für Fulfillment-Teams

Packzettel-PDF API: aus Bestellpositionen und Lagerdaten Packzettel-PDFs erzeugen, ohne Browser-Rendering und mit klarer Grenze zwischen gPdf-Rendering und Ihren Geschäftsdaten.

PRIMÄRE API Template Render

ENDPOINT /api/v1/template-render

SYSTEME OMS / WMS / 3PL-Backend / Shopify-App-Backend

Im Playground testen → Dokumentation lesen

Aufgabe im Workflow

aus Bestellpositionen und Lagerdaten Packzettel-PDFs erzeugen. Ihr System liefert Daten und Regeln; gPdf rendert daraus reproduzierbare PDF-Ausgabe.

Wann diese API passt

Ihr System besitzt die Daten für Packzettel bereits und braucht eine PDF-Antwort.
Sie wollen Template Render über /api/v1/template-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/template-render

Template Render ist der Standardpfad für diesen Workflow.

SEKUNDÄR 1

/api/v1/pdf/render

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

Minimaler Request

/api/v1/template-render - minimaler Request für Packzettel.

{
  "template_id": "packing_list",
  "data": [
    {
      "shipment": {
        "number": "PL-2026-1001",
        "date": "2026-05-29"
      },
      "shipper": {
        "name": "Acme Warehouse",
        "address": "1200 Logistics Pkwy"
      },
      "consignee": {
        "name": "Receiver Inc.",
        "address": "123 Main St"
      },
      "items": [
        {
          "item_no": "1",
          "description": "Replacement filter",
          "quantity": "2",
          "unit": "pcs",
          "gross_weight": "1.2 kg",
          "net_weight": "1.0 kg"
        }
      ]
    }
  ]
}

Was gPdf übernimmt

Rendering von Packzettel 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.
Template-Vertrag, Feldnamen und Versionierung vor dem Rollout fixieren.
Validierungs- und Reprint-Nachweise dort speichern, wo Ihr System sie braucht.

Aussagegrenzen

gPdf rendert Packzettel; 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

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