Guide / Validation API

Use a Factur-X Validator API, not a fragile validation stack

If your ERP or middleware needs to reject broken invoices before they hit your database, a validator API is the simplest control point. The key is not just returning valid or invalid, but exposing what actually ran.

What the API Gives You

  • EN 16931 validation for XML and Factur-X PDFs
  • validation_completeness so you know whether all applicable layers ran
  • pdfa_valid with tri-state semantics: true, false, or null
  • Structured errors you can log, surface, or map into workflow rules

Validate XML or PDF

XML Validation
curl -X POST "http://localhost:8000/v1/validate" \
  -F "file=@invoice.xml"
PDF Validation
curl -X POST "http://localhost:8000/v1/validate" \
  -F "file=@invoice.pdf"

Interpret the Result Safely

For PDF/A, the API distinguishes three states. That matters operationally because "not checked" is not the same thing as "checked and failed".

Response Example
{
  "valid": true,
  "format": "factur-x",
  "pdfa_valid": null,
  "validation_completeness": "partial",
  "layers_executed": ["xsd"],
  "layers_skipped": [
    {"layer": "pdfa", "reason": "verapdf_unavailable"}
  ]
}
  • pdfa_valid = true: VeraPDF ran and the PDF passed
  • pdfa_valid = false: VeraPDF ran and the PDF failed
  • pdfa_valid = null: PDF/A was not checked or did not apply

Where It Fits

Control Point

  Supplier XML/PDF
       |
       v
  /v1/validate  -> reject, quarantine, or route
       |
       v
  /v1/serialize -> ERP-ready JSON
                    

See Also

Start Validating Invoices

docker run -d -p 8000:8000 facturxengine/facturx-engine:latest