Is PDF/A-3b always an e-invoice?

No. PDF/A-3b is an archival PDF profile. Factur-X and ZUGFeRD e-invoices use PDF/A-3b as the wrapper for embedded EN 16931 XML.

Which endpoint creates PDF/A-3b?

Use POST /api/v1/pdf/render with settings.profile for ordinary PDF/A-3b. Use POST /api/v1/e-invoice/render when the output must be a Factur-X or ZUGFeRD e-invoice.

Can I attach arbitrary files through this page?

Do not assume arbitrary attachment support unless the public API docs list that workflow. This page focuses on documented PDF/A-3b and e-invoice use.

How do I verify PDF/A output?

Use /validator/ or your own reference-engine pipeline. For e-invoices, validate both the PDF/A layer and the embedded XML layer.

Compliance and archival

PDF/A-3b API for archival and e-invoice workflows

Generate PDF/A-3b output with gPdf and understand when PDF/A-3b is only an archival profile versus an e-invoice wrapper.

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS compliance backend / finance system / legal archive / audit workflow

Try in Playground → Read the docs

Job to be done

Generate PDF/A-3b documents for archival workflows and choose the e-invoice endpoint when PDF/A-3b must carry embedded Factur-X or ZUGFeRD EN 16931 XML.

When to use this API

You need a PDF/A-3b archival profile for a rendered document.
You need to explain the boundary between ordinary PDF/A and e-invoice packaging.
Your compliance workflow validates generated PDFs with veraPDF or another reference engine.
You need a public page to route PDF/A-3b search intent to the correct endpoint.

What it does not replace

You need arbitrary file-attachment workflows not documented in the public API.
You need Factur-X or ZUGFeRD e-invoices through JSON Render. Use E-Invoice Render.
You need a validator API. The current public validator surface is the /validator/ page.

Which endpoint to call

PRIMARY

/api/v1/pdf/render

JSON Render is the default path for this workflow.

SECONDARY 1

/api/v1/e-invoice/render

Use this when the workflow needs the related API path, template contract, or capabilities lookup.

Minimal request

POST /api/v1/pdf/render - request PDF/A-3b output for a rendered document.

{
  "settings": {
    "profile": "pdfa-3b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive copy",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

What gPdf handles

PDF/A profile selection through JSON Render settings.
PDF/A-3b e-invoice packaging when using POST /api/v1/e-invoice/render.
Renderable PDF output suitable for external reference-engine validation.
Clear separation between archival profile and legal e-invoice workflow.

What your system owns

The retention policy and reason PDF/A-3b is required.
Any business data, XML semantics, and external compliance acceptance criteria.
Validation evidence, audit records, and long-term storage after rendering.

Production checklist

Choose JSON Render for ordinary PDF/A-3b output.
Choose E-Invoice Render when embedded EN 16931 XML is required.
Validate PDF/A output with /validator/ or your own veraPDF workflow.
Record the requested profile and request ID with the stored document.
Avoid claiming support for arbitrary attachments unless the public docs list it.

Claim boundaries

PDF/A-3b is an archival profile; e-invoice packaging is a narrower workflow on top of it.
Do not imply every arbitrary embedded-file workflow is supported.
The e-invoice route is required for Factur-X and ZUGFeRD PDF/A-3b packages.

PDF/A-3b is the wrapper, not the whole workflow

PDF/A-3b is a PDF archival profile. It matters because it can act as the wrapper for hybrid e-invoices, but the profile alone does not make a document a legal e-invoice. An ordinary archived document can use PDF/A-3b without embedded invoice XML.

For Factur-X and ZUGFeRD, use POST /api/v1/e-invoice/render. That endpoint is responsible for the e-invoice-specific metadata and associated-file wiring.

Choose the endpoint by intent

Use JSON Render when your goal is “render this document as PDF/A-3b.” Use E-Invoice Render when your goal is “package this invoice as Factur-X or ZUGFeRD with EN 16931 CII XML.” The distinction keeps code clear and prevents ordinary archival jobs from accidentally carrying e-invoice assumptions.

Validate externally

PDF/A should be verified with a reference engine, not with a marketing claim. Use the public validator or your own validation pipeline and store the report with your audit evidence.

FAQ

Is PDF/A-3b always an e-invoice?: No. PDF/A-3b is an archival PDF profile. Factur-X and ZUGFeRD e-invoices use PDF/A-3b as the wrapper for embedded EN 16931 XML.
Which endpoint creates PDF/A-3b?: Use POST /api/v1/pdf/render with settings.profile for ordinary PDF/A-3b. Use POST /api/v1/e-invoice/render when the output must be a Factur-X or ZUGFeRD e-invoice.
Can I attach arbitrary files through this page?: Do not assume arbitrary attachment support unless the public API docs list that workflow. This page focuses on documented PDF/A-3b and e-invoice use.
How do I verify PDF/A output?: Use /validator/ or your own reference-engine pipeline. For e-invoices, validate both the PDF/A layer and the embedded XML layer.