Cumplimiento y archivo

API de PDF/A-3b para flujos de archivo y factura electrónica

Genere salida PDF/A-3b con gPdf y distinga cuándo PDF/A-3b es solo un perfil de archivo y cuándo es un contenedor de factura electrónica.

API PRINCIPAL JSON Render
ENDPOINT /api/v1/pdf/render
SISTEMAS backend de cumplimiento / sistema financiero / archivo legal / flujo de auditoría
Trabajo a resolver

Generar documentos PDF/A-3b para flujos de archivo y elegir el endpoint de factura electrónica cuando PDF/A-3b deba transportar XML EN 16931 incrustado de Factur-X o ZUGFeRD.

Cuándo usar esta API

  • Necesita un perfil de archivo PDF/A-3b para un documento renderizado.
  • Necesita explicar la frontera entre PDF/A ordinario y empaquetado de factura electrónica.
  • Su flujo de cumplimiento valida PDF generados con veraPDF u otro motor de referencia.
  • Necesita una página pública que enrute la intención de búsqueda PDF/A-3b al endpoint correcto.

Qué no sustituye

  • Necesita flujos arbitrarios de adjuntos no documentados en la API pública.
  • Necesita facturas electrónicas Factur-X o ZUGFeRD mediante JSON Render. Use E-Invoice Render.
  • Necesita una API de validación. La superficie pública actual del validador es la página /validator/.

Qué endpoint llamar

PRINCIPAL

/api/v1/pdf/render

JSON Render es la ruta predeterminada para este flujo.

SECUNDARIO 1

/api/v1/e-invoice/render

Úsalo cuando el flujo necesite la ruta API relacionada, un contrato de plantilla o una consulta de capacidades.

Solicitud mínima

POST /api/v1/pdf/render - solicitar salida PDF/A-3b para un 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" }
        }
      ]
    }
  ]
}

Qué gestiona gPdf

  • Selección de perfil PDF/A mediante ajustes de JSON Render.
  • Empaquetado de factura electrónica PDF/A-3b al usar POST /api/v1/e-invoice/render.
  • Salida PDF renderizable apta para validación externa con motores de referencia.
  • Separación clara entre perfil de archivo y flujo legal de factura electrónica.

Qué controla su sistema

  • La política de retención y la razón por la que PDF/A-3b es obligatorio.
  • Cualquier dato empresarial, semántica XML y criterio externo de aceptación de cumplimiento.
  • Evidencia de validación, registros de auditoría y almacenamiento a largo plazo después del renderizado.

Checklist de producción

  1. Elija JSON Render para salida PDF/A-3b ordinaria.
  2. Elija E-Invoice Render cuando se requiera XML EN 16931 incrustado.
  3. Valide la salida PDF/A con /validator/ o con su propio flujo veraPDF.
  4. Registre el perfil solicitado y el ID de solicitud con el documento almacenado.
  5. Evite afirmar soporte para adjuntos arbitrarios salvo que la documentación pública lo liste.

Límites de la promesa

  • PDF/A-3b es un perfil de archivo; el empaquetado de factura electrónica es un flujo más estrecho construido sobre él.
  • No implique que se soporta cualquier flujo arbitrario con archivos incrustados.
  • La ruta de factura electrónica es obligatoria para paquetes Factur-X y ZUGFeRD PDF/A-3b.

PDF/A-3b es el contenedor, no todo el flujo

PDF/A-3b es un perfil PDF de archivo. Importa porque puede actuar como contenedor para facturas electrónicas híbridas, pero el perfil por sí solo no convierte un documento en una factura electrónica legal. Un documento ordinario archivado puede usar PDF/A-3b sin XML de factura incrustado.

Para Factur-X y ZUGFeRD, use POST /api/v1/e-invoice/render. Ese endpoint se encarga de los metadatos específicos de factura electrónica y del cableado de archivo asociado.

Elija el endpoint según la intención

Use JSON Render cuando su objetivo sea “renderizar este documento como PDF/A-3b”. Use E-Invoice Render cuando su objetivo sea “empaquetar esta factura como Factur-X o ZUGFeRD con XML CII EN 16931”. La distinción mantiene claro el código y evita que trabajos ordinarios de archivo arrastren supuestos de factura electrónica.

Valide externamente

PDF/A debe verificarse con un motor de referencia, no con una afirmación de marketing. Use el validador público o su propio pipeline de validación y guarde el informe junto con su evidencia de auditoría.

FAQ

¿PDF/A-3b siempre es una factura electrónica?
No. PDF/A-3b es un perfil PDF de archivo. Las facturas electrónicas Factur-X y ZUGFeRD usan PDF/A-3b como contenedor para XML EN 16931 incrustado.
¿Qué endpoint crea PDF/A-3b?
Use POST /api/v1/pdf/render con settings.profile para PDF/A-3b ordinario. Use POST /api/v1/e-invoice/render cuando la salida deba ser una factura electrónica Factur-X o ZUGFeRD.
¿Puedo adjuntar archivos arbitrarios desde esta página?
No asuma soporte para adjuntos arbitrarios salvo que la documentación pública de la API liste ese flujo. Esta página se centra en PDF/A-3b y factura electrónica documentados.
¿Cómo verifico la salida PDF/A?
Use /validator/ o su propio pipeline con motores de referencia. Para facturas electrónicas, valide tanto la capa PDF/A como la capa XML incrustada.