PDF/A-3b é sempre uma e-invoice?

Não. PDF/A-3b é um perfil PDF de arquivamento. E-invoices Factur-X e ZUGFeRD usam PDF/A-3b como wrapper para EN 16931 XML incorporado.

Qual endpoint cria PDF/A-3b?

Use POST /api/v1/pdf/render com settings.profile para PDF/A-3b comum. Use POST /api/v1/e-invoice/render quando a saída precisa ser uma e-invoice Factur-X ou ZUGFeRD.

Posso anexar arquivos arbitrários por esta página?

Não presuma suporte a anexos arbitrários a menos que a documentação pública da API liste esse fluxo. Esta página foca nos usos documentados de PDF/A-3b e e-invoice.

Como verifico a saída PDF/A?

Use /validator/ ou seu próprio pipeline de motor de referência. Para e-invoices, valide tanto a camada PDF/A quanto a camada XML incorporada.

Compliance e arquivo

API de PDF/A-3b para fluxos de arquivamento e e-invoice

Gere saída PDF/A-3b com o gPdf e entenda quando PDF/A-3b é apenas um perfil de arquivamento versus quando é um wrapper de e-invoice.

API PRINCIPAL JSON Render

ENDPOINT /api/v1/pdf/render

SISTEMAS Backend de compliance / Sistema financeiro / Arquivo legal / Fluxo de auditoria

Testar no Playground Ler a documentação

Tarefa a resolver

Gerar documentos PDF/A-3b para fluxos de arquivamento e escolher o endpoint de e-invoice quando o PDF/A-3b precisa carregar XML EN 16931 incorporado de Factur-X ou ZUGFeRD.

Quando usar esta API

Você precisa de um perfil de arquivamento PDF/A-3b para um documento renderizado.
Você precisa explicar a fronteira entre PDF/A comum e empacotamento de e-invoice.
Seu fluxo de compliance valida PDFs gerados com veraPDF ou outro motor de referência.
Você precisa de uma página pública que direcione a intenção de busca por PDF/A-3b ao endpoint correto.

O que ela não substitui

Você precisa de fluxos arbitrários de anexos de arquivo que não estão documentados na API pública.
Você precisa de e-invoices Factur-X ou ZUGFeRD por JSON Render. Use E-Invoice Render.
Você precisa de uma API de validador. A superfície pública atual de validação é a página /validator/.

Qual endpoint chamar

PRINCIPAL

/api/v1/pdf/render

JSON Render é o caminho padrão para este fluxo.

SECUNDÁRIO 1

/api/v1/e-invoice/render

Use quando o fluxo precisar da API relacionada, de um contrato de template ou de uma consulta de capacidades.

Request mínimo

POST /api/v1/pdf/render - solicitar saída PDF/A-3b para um documento renderizado.

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

O que a gPdf faz

Seleção de perfil PDF/A por configurações de JSON Render.
Empacotamento de e-invoice PDF/A-3b ao usar POST /api/v1/e-invoice/render.
Saída PDF renderizável adequada para validação por motores externos de referência.
Separação clara entre perfil de arquivamento e fluxo legal de e-invoice.

O que seu sistema controla

A política de retenção e o motivo pelo qual PDF/A-3b é obrigatório.
Quaisquer dados de negócio, semântica XML e critérios externos de aceite de compliance.
Evidência de validação, registros de auditoria e armazenamento de longo prazo após a renderização.

Checklist de produção

Escolha JSON Render para saída PDF/A-3b comum.
Escolha E-Invoice Render quando EN 16931 XML incorporado for necessário.
Valide a saída PDF/A com /validator/ ou seu próprio fluxo veraPDF.
Registre o perfil solicitado e o ID de requisição junto ao documento armazenado.
Evite declarar suporte a anexos arbitrários a menos que a documentação pública os liste.

Limites da promessa

PDF/A-3b é um perfil de arquivamento; empacotamento de e-invoice é um fluxo mais específico sobre ele.
Não sugira que todo fluxo arbitrário de arquivo incorporado é suportado.
A rota de e-invoice é obrigatória para pacotes PDF/A-3b Factur-X e ZUGFeRD.

PDF/A-3b é o wrapper, não o fluxo inteiro

PDF/A-3b é um perfil PDF de arquivamento. Ele importa porque pode atuar como wrapper para e-invoices híbridas, mas o perfil sozinho não transforma um documento em e-invoice legal. Um documento comum de arquivo pode usar PDF/A-3b sem XML de fatura incorporado.

Para Factur-X e ZUGFeRD, use POST /api/v1/e-invoice/render. Esse endpoint é responsável pelos metadados específicos de e-invoice e pela ligação do arquivo associado.

Escolha o endpoint pela intenção

Use JSON Render quando seu objetivo é “renderizar este documento como PDF/A-3b”. Use E-Invoice Render quando seu objetivo é “empacotar esta fatura como Factur-X ou ZUGFeRD com EN 16931 CII XML”. A distinção mantém o código claro e evita que jobs comuns de arquivamento carreguem pressupostos de e-invoice por acidente.

Valide externamente

PDF/A deve ser verificado com um motor de referência, não com uma afirmação de marketing. Use o validador público ou seu próprio pipeline de validação e armazene o relatório junto às evidências de auditoria.

FAQ

PDF/A-3b é sempre uma e-invoice?: Não. PDF/A-3b é um perfil PDF de arquivamento. E-invoices Factur-X e ZUGFeRD usam PDF/A-3b como wrapper para EN 16931 XML incorporado.
Qual endpoint cria PDF/A-3b?: Use POST /api/v1/pdf/render com settings.profile para PDF/A-3b comum. Use POST /api/v1/e-invoice/render quando a saída precisa ser uma e-invoice Factur-X ou ZUGFeRD.
Posso anexar arquivos arbitrários por esta página?: Não presuma suporte a anexos arbitrários a menos que a documentação pública da API liste esse fluxo. Esta página foca nos usos documentados de PDF/A-3b e e-invoice.
Como verifico a saída PDF/A?: Use /validator/ ou seu próprio pipeline de motor de referência. Para e-invoices, valide tanto a camada PDF/A quanto a camada XML incorporada.