API PDF de reçu est-elle un endpoint séparé ?

Non. Cette page explique comment utiliser /api/v1/pdf/render et les API gPdf associées pour ce flux.

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[].

Est-ce la même chose que l'API de facture électronique ?

Non. Les PDF de reçu ordinaires utilisent JSON Render ou Template Render. Le packaging Factur-X et ZUGFeRD passe par l'endpoint E-Invoice Render.

Facturation et finance

API PDF de reçu pour POS et SaaS

API PDF de reçu : générer reçus et justificatifs PDF depuis des données transactionnelles, avec QR codes, codes-barres, paramètres PDF/A et modèles réutilisables.

API PRINCIPALE JSON Render

ENDPOINT /api/v1/pdf/render

SYSTÈMES backend e-commerce / backend facturation / plateforme SaaS / service export POS

Essayer dans le Playground Lire la documentation

Tâche à accomplir

générer reçus et justificatifs PDF depuis des données transactionnelles. 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 des reçus et attend une réponse PDF.
Vous voulez utiliser JSON Render via /api/v1/pdf/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 avez besoin d'une conversion HTML vers PDF arbitraire avec Chromium.
Vous avez besoin d'un packaging légal de facture électronique. Utilisez E-Invoice Render pour les sorties Factur-X ou ZUGFeRD.
Un contrat template_id publié serait plus adapté que l'envoi du layout à chaque requête.

Quel endpoint appeler

PRINCIPAL

/api/v1/pdf/render

JSON Render est le chemin par défaut pour ce flux.

SECONDAIRE 1

/api/v1/template-render

À utiliser si le flux 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/pdf/render - requête minimale pour des reçus.

{
  "pages": [
    {
      "size": "a6",
      "elements": [
        {
          "type": "text",
          "x": 10,
          "y": 12,
          "content": "Receipt R-2026-1001",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "text",
          "x": 10,
          "y": 28,
          "content": "Order total: $82.40\nPaid by card ending 4242\nTax: $6.10",
          "style": { "font_size": 10, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "barcode",
          "format": "qrcode",
          "content": "https://example.com/receipts/R-2026-1001",
          "x": 10,
          "y": 58,
          "width": 28,
          "height": 28
        }
      ]
    }
  ]
}

Ce que gPdf prend en charge

Rendu de reçus depuis des requêtes structurées.
Pages PDF, texte, totaux, lignes d'articles, QR codes, codes-barres, métadonnées et paramètres PDF/A optionnels.
Sortie PDF déterministe pour réimpression, audit et automatisation backend.
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.
Règles fiscales, conformité, client ou plateforme avant le rendu.

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 des reçus ; 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.
Certification externe, acceptation et validations opérationnelles restent hors du renderer.

Les PDF de reçu sont des sorties de rendu

Ce n’est pas un endpoint de paiement ou de POS séparé. Votre backend e-commerce, facturation ou POS décide qu’un reçu existe, puis envoie le contenu du reçu à gPdf sous forme de DocumentRequest ou de données pour un modèle publié.

La couche de rendu doit rester déterministe. Si un agent support redemande le même reçu, votre système peut rejouer les données source ou renvoyer un PDF déjà stocké, selon votre politique de conservation.

Chemin template pour les reçus répétés

Les mises en page de reçu se stabilisent généralement vite. Une fois le design approuvé, publiez un modèle et appelez POST /api/v1/template-render avec les champs du reçu. Les systèmes de paiement restent concentrés sur les données, et la propriété de la mise en page reste au même endroit.

FAQ

API PDF de reçu est-elle un endpoint séparé ?: Non. Cette page explique comment utiliser /api/v1/pdf/render et les API gPdf associées pour ce flux.
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[].
Est-ce la même chose que l'API de facture électronique ?: Non. Les PDF de reçu ordinaires utilisent JSON Render ou Template Render. Le packaging Factur-X et ZUGFeRD passe par l'endpoint E-Invoice Render.