API PDF/A pour archivage et conformité
API PDF/A : générer des profils PDF/A pour archivage, conformité et validation, sans rendu navigateur et avec une frontière claire entre le rendu gPdf et vos données métier.
/api/v1/pdf/render générer des profils PDF/A pour archivage, conformité et validation. 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 documents PDF/A 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 attendez de gPdf qu'il déduise un sens métier ou légal depuis des données brutes.
- Un contrat template_id publié serait plus adapté que l'envoi du layout à chaque requête.
Quel endpoint appeler
/api/v1/pdf/render
JSON Render est le chemin par défaut pour ce flux.
/api/v1/e-invoice/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 documents PDF/A.
{
"settings": {
"profile": "pdfa-2b"
},
"pages": [
{
"size": "a4",
"elements": [
{
"type": "text",
"x": 20,
"y": 24,
"content": "Archive-ready document",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
Ce que gPdf prend en charge
- Rendu de documents PDF/A 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.
- 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 documents PDF/A ; 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.
PDF/A est un choix de profil
Pour les documents d’archivage ordinaires, PDF/A se choisit dans les paramètres de rendu. Le flux reste proche de JSON Render : votre système décrit le document et définit le profil dont il a besoin.
Le packaging de facture électronique est différent. Quand le document doit porter Factur-X ou ZUGFeRD avec XML CII EN 16931 intégré dans un PDF/A-3b, utilisez l’endpoint E-Invoice Render.
FAQ
- API PDF/A 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[].
- 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.