Not a marketing mockup — this is the real request shape, real response shape, and a real (but illustratively generated) signed proof record. Field names below are copied directly from the running code, not paraphrased.
curl -X POST https://invoxapi.de/v1/validate \ -H "X-API-Key: in_your_key_here" \ -F "file=@invoice.xml" \ -F "format=XRECHNUNG_3_UBL"Response — an invoice with two real defects
{
"verdict": "invalid",
"errors": [
{
"rule_id": "BR-01",
"severity": "error",
"human_message": "Specification identifier (BT-24) is missing.",
"bt_number": "BT-24",
"auto_fix_possible": true
},
{
"rule_id": "BR-04",
"severity": "error",
"human_message": "Invoice type code (BT-3) is missing.",
"bt_number": "BT-3",
"auto_fix_possible": true
}
],
"warnings": []
}
Note: not "Invalid invoice" and nothing else. Every finding names the exact business term (BT-x, from the EN 16931 standard itself), whether an automatic fix is possible, and a plain-language explanation — the same information a human reviewer would need to fix the invoice.
{
"request_id": "8f2c1a9e-...-uuid",
"doc_hash": "0d19ba76...e9a10179",
"format": "XRECHNUNG_3_UBL",
"violation_count": 0,
"chain_entry_hash": "79cb4fc0...4336961f"
}
Two things worth noticing:
| doc_hash | A SHA-256 hash of the invoice — never the invoice content itself. Nothing you send is stored. |
| chain_entry_hash | This result is appended to an append-only, tamper-evident hash chain and signed (Ed25519) — verifiable offline, without trusting INVOX's servers, by anyone holding the published public key. |
Every real result you generate gets its own request_id and its own chain entry — this is a schema illustration, not a record you can look up. To check a real signed proof, use the public verifier with a request_id from your own account.