Pas une maquette marketing — voici la vraie forme de requête, la vraie forme de réponse, et un vrai enregistrement de preuve signée (généré à titre d'illustration). Les noms de champs ci-dessous sont copiés directement du code en production, pas paraphrasés.
curl -X POST https://invoxapi.de/v1/validate \ -H "X-API-Key: in_votre_cle_ici" \ -F "file=@facture.xml" \ -F "format=XRECHNUNG_3_UBL"Réponse — une facture avec deux défauts réels
{
"verdict": "invalid",
"errors": [
{
"rule_id": "BR-01",
"severity": "error",
"human_message": "L'identifiant de spécification (BT-24) est manquant.",
"bt_number": "BT-24",
"auto_fix_possible": true
},
{
"rule_id": "BR-04",
"severity": "error",
"human_message": "Le code type de facture (BT-3) est manquant.",
"bt_number": "BT-3",
"auto_fix_possible": true
}
],
"warnings": []
}
Pas seulement « Invalid invoice » sans autre précision. Chaque anomalie nomme le terme métier exact (BT-x, issu du standard EN 16931 lui-même), indique si une correction automatique est possible, et fournit une explication en langage clair — exactement l'information dont un relecteur humain aurait besoin pour corriger la facture.
{
"request_id": "8f2c1a9e-...-uuid",
"doc_hash": "0d19ba76...e9a10179",
"format": "XRECHNUNG_3_UBL",
"violation_count": 0,
"chain_entry_hash": "79cb4fc0...4336961f"
}
Deux points à noter :
| doc_hash | Un hash SHA-256 de la facture — jamais le contenu de la facture lui-même. Rien de ce que vous envoyez n'est stocké. |
| chain_entry_hash | Ce résultat est ajouté à une chaîne de hachage append-only, infalsifiable, et signé (Ed25519) — vérifiable hors ligne, sans avoir à faire confiance aux serveurs d'INVOX, par quiconque détient la clé publique publiée. |
Chaque résultat réel que vous générez obtient son propre request_id et sa propre entrée de chaîne — ceci est une illustration de schéma, pas un enregistrement consultable. Pour vérifier une vraie preuve signée, utilisez le vérificateur public avec un request_id de votre propre compte.