API ZUGFeRD est-elle un endpoint séparé ?

Non. Cette page explique comment utiliser /api/v1/e-invoice/render et les API gPdf associées pour ce workflow.

Que doit fournir mon système ?

Votre système fournit les données métier, le mapping, la validation et les règles avant rendu. gPdf prend en charge la génération PDF.

Quand utiliser Template Render ?

Utilisez Template Render lorsque la mise en page est stable et que les appelants doivent seulement envoyer template_id et data[].

Que vérifier avant la production ?

Testez les données réelles, cas limites, validations et systèmes aval qui lisent, impriment ou archivent le PDF.

Compliance and archival

API ZUGFeRD pour processus de facture électronique allemands

API ZUGFeRD : produire du PDF/A-3b ZUGFeRD avec XML CII EN 16931 intégré, sans rendu navigateur et avec une frontière claire entre le rendu gPdf et vos données métier.

API PRINCIPALE E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTÈMES ERP / backend facturation / workflow finance Allemagne / service d’automatisation conformité

Essayer dans le Playground → Lire la documentation

Tâche à accomplir

produire du PDF/A-3b ZUGFeRD avec XML CII EN 16931 intégré. Votre système fournit les données et règles ; gPdf les rend en PDF de manière reproductible.

Quand utiliser cette API

Votre système possède déjà les données nécessaires pour factures ZUGFeRD et attend une réponse PDF.
Vous voulez utiliser E-Invoice Render via /api/v1/e-invoice/render plutôt qu'un flux HTML vers PDF basé sur navigateur.
Mise en page, codes-barres, texte et métadonnées doivent être reproductibles depuis des données structurées.
Les payloads doivent pouvoir être testés dans le Playground ou en CI avant production.

Ce qu'elle ne remplace pas

Vous attendez de gPdf qu'il déduise la sémantique fiscale ou légale d'un XML incomplet.
Vous avez besoin d'un standard national non listé par l'endpoint de capacités.
Vous voulez seulement un PDF classique sans package de facture électronique.

Quel endpoint appeler

PRINCIPAL

/api/v1/e-invoice/render

E-Invoice Render est le chemin par défaut pour ce workflow.

SECONDAIRE 1

/api/v1/e-invoice/capabilities

À utiliser si le workflow a besoin d'un chemin API lié, d'un contrat de modèle ou d'une recherche de capacités.

Requête minimale

/api/v1/e-invoice/render - requête minimale pour factures ZUGFeRD.

{
  "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" }
        }
      ]
    }
  ]
}

Ce que gPdf prend en charge

Rendu de factures ZUGFeRD depuis des requêtes structurées.
Pages PDF, texte, tableaux, lignes, formes, images et codes-barres vectoriels selon le besoin.
Métadonnées, profils et limites de validation liés à PDF/A selon le contrat public de l'API.
Surface d'erreur API unifiée avec code API-XXX et req_id en cas d'échec.

Ce que votre système garde

Données métier, mapping des champs et sémantique du document.
Validation, idempotence, nommage, stockage et traçabilité après la réponse.
Exactitude du XML EN 16931 et tests d'acceptation côté destinataire.

Checklist de production

Ajouter request IDs et timeouts aux appels de production.
Valider les payloads avec OpenAPI, la documentation ou des tests Golden PDF.
Garder l'URL de base API et le bearer token configurables, hors du code source.
Tester les layouts critiques avec données réelles et cas limites.
Conserver les preuves de validation et de réimpression dans le système qui en a besoin.

Limites de la promesse

gPdf rend factures ZUGFeRD ; l'exactitude métier reste dans votre système.
Cette page décrit le bon chemin d'API gPdf, pas un endpoint spécifique supplémentaire.
Les autres noms de facture électronique ne sont natifs que s'ils apparaissent dans l'endpoint de capacités.

Comment ce workflow s’insère dans gPdf

API ZUGFeRD est un workflow de production bâti sur les API publiques de gPdf. La requête décrit explicitement la sortie : données, mise en page, paramètres et éléments à rendre en PDF. gPdf prend en charge le rendu, pas la décision métier derrière les données.

Chemin d’API et frontière de responsabilité

Dans la plupart des cas, E-Invoice Render via /api/v1/e-invoice/render est le bon point de départ. Votre système reste responsable des référentiels, de la validation, de la conservation et des règles métier. Le contrat reste lisible : gPdf produit le PDF, votre application pilote le sens et le processus.

Passage en production

Testez factures ZUGFeRD avec des données réelles, imprimantes, scanners, validateurs ou systèmes destinataires selon le workflow. Conservez les request IDs et preuves de validation pour le support, l’audit et les réimpressions.

FAQ

API ZUGFeRD est-elle un endpoint séparé ?: Non. Cette page explique comment utiliser /api/v1/e-invoice/render et les API gPdf associées pour ce workflow.
Que doit fournir mon système ?: Votre système fournit les données métier, le mapping, la validation et les règles avant rendu. gPdf prend en charge la génération PDF.
Quand utiliser Template Render ?: Utilisez Template Render lorsque la mise en page est stable et que les appelants doivent seulement envoyer template_id et data[].
Que vérifier avant la production ?: Testez les données réelles, cas limites, validations et systèmes aval qui lisent, impriment ou archivent le PDF.