Kein Marketing-Mockup — das ist die echte Anfrageform, echte Antwortform und ein echter (aber zu Illustrationszwecken erzeugter) signierter Nachweisdatensatz. Feldnamen unten sind direkt aus dem laufenden Code kopiert, nicht umschrieben.
curl -X POST https://invoxapi.de/v1/validate \ -H "X-API-Key: in_ihr_key_hier" \ -F "file=@rechnung.xml" \ -F "format=XRECHNUNG_3_UBL"Antwort — eine Rechnung mit zwei echten Mängeln
{
"verdict": "invalid",
"errors": [
{
"rule_id": "BR-01",
"severity": "error",
"human_message": "Spezifikationskennung (BT-24) fehlt.",
"bt_number": "BT-24",
"auto_fix_possible": true
},
{
"rule_id": "BR-04",
"severity": "error",
"human_message": "Rechnungstypcode (BT-3) fehlt.",
"bt_number": "BT-3",
"auto_fix_possible": true
}
],
"warnings": []
}
Nicht "Invalid invoice" und sonst nichts. Jeder Befund benennt den exakten Geschäftsbegriff (BT-x, aus dem EN-16931-Standard selbst), ob eine automatische Korrektur möglich ist, und eine Klartext-Erklärung — genau die Information, die ein menschlicher Prüfer bräuchte.
{
"request_id": "8f2c1a9e-...-uuid",
"doc_hash": "0d19ba76...e9a10179",
"format": "XRECHNUNG_3_UBL",
"violation_count": 0,
"chain_entry_hash": "79cb4fc0...4336961f"
}
Zwei Dinge sind bemerkenswert:
| doc_hash | Ein SHA-256-Hash der Rechnung — niemals der Rechnungsinhalt selbst. Nichts, was Sie senden, wird gespeichert. |
| chain_entry_hash | Dieses Ergebnis wird an eine unveränderliche, manipulationssichere Hash-Kette angehängt und signiert (Ed25519) — offline verifizierbar, ohne INVOX's Servern vertrauen zu müssen, für jeden, der den veröffentlichten öffentlichen Schlüssel besitzt. |
Jedes echte Ergebnis, das Sie erzeugen, erhält eine eigene request_id und einen eigenen Ketteneintrag — dies ist eine Schema-Illustration, kein nachschlagbarer Datensatz. Um einen echten signierten Nachweis zu prüfen, nutzen Sie den öffentlichen Verifizierer mit einer request_id aus Ihrem eigenen Konto.