Compliance and archival
Factur-X API for hybrid PDF/A-3b e-invoices
Generate Factur-X PDF/A-3b invoices with embedded EN 16931 CII XML through the public E-Invoice Render endpoint.
PRIMARY API E-Invoice Render
ENDPOINT
/api/v1/e-invoice/render SYSTEMS ERP / billing backend / compliance workflow / finance automation service
Job to be done
Package a rendered invoice PDF as Factur-X PDF/A-3b with embedded EN 16931 CII XML after your ERP or billing system has produced the correct structured invoice data.
When to use this API
- You need native Factur-X output from the public E-Invoice Render endpoint.
- Your system already has valid EN 16931 CII XML for the invoice.
- You need PDF/A-3b packaging with Factur-X metadata and associated-file wiring.
- You want the capabilities endpoint to confirm the currently published e-invoice contract.
What it does not replace
- You need gPdf to create invoice business semantics or tax decisions for you.
- You need native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, or other standards not listed in OpenAPI.
- You need direct submission to Chorus Pro or another government portal.
Which endpoint to call
/api/v1/e-invoice/render
E-Invoice Render is the default path for this workflow.
/api/v1/e-invoice/capabilities
Use this when the workflow needs the related API path, template contract, or capabilities lookup.
Minimal request
POST /api/v1/e-invoice/render - minimal Factur-X package shape.
{
"settings": {
"profile": "pdfa-3b",
"e_invoice": {
"standard": "factur_x",
"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": "Factur-X invoice",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
What gPdf handles
- Factur-X packaging through E-Invoice Render.
- PDF/A-3b profile handling for the hybrid invoice PDF.
- Embedding CII XML as an associated file with standard metadata.
- Inline PDF delivery or object-delivery job behavior as documented.
What your system owns
- Correct EN 16931 CII XML, invoice numbers, tax logic, buyer and seller data, and eligibility.
- External validation, recipient rules, portal submission, and legal interpretation.
- Storage, audit trail, retry logic, and delivery to the customer or portal.
Production checklist
- Validate the CII XML before sending it to gPdf.
- Set settings.profile to pdfa-3b or omit it so the e-invoice default applies.
- Use settings.e_invoice.standard = factur_x and settings.e_invoice.profile = en16931.
- Run the returned PDF through your Factur-X validator workflow.
- Keep submission and recipient routing outside the render API.
Claim boundaries
- Native public e-invoice output is Factur-X or ZUGFeRD with EN 16931 CII XML.
- gPdf does not submit invoices to government or buyer portals.
- Your system owns business, tax, and XML correctness.
Factur-X is an e-invoice packaging workflow
Factur-X combines a human-readable PDF with machine-readable EN 16931 CII XML. The public gPdf endpoint packages that combination into PDF/A-3b output. It does not decide the invoice semantics or submit the file to a portal.
FAQ
- Which endpoint renders Factur-X?
- Use POST /api/v1/e-invoice/render with settings.e_invoice.standard set to factur_x.
- Does gPdf generate the EN 16931 XML?
- Your system supplies the CII XML and owns its business correctness. gPdf packages it into the hybrid PDF.
- Does gPdf support XRechnung on this page?
- No. This page is limited to the public Factur-X contract listed in OpenAPI.
- Does gPdf submit Factur-X invoices to portals?
- No. Submission and recipient routing remain outside the render API.