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_completenessso you know whether all applicable layers ranpdfa_validwith 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 passedpdfa_valid = false: VeraPDF ran and the PDF failedpdfa_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