No es una maqueta de marketing — esta es la forma real de la solicitud, la forma real de la respuesta, y un registro de prueba firmado real (generado con fines ilustrativos). Los nombres de campo a continuación están copiados directamente del código en producción, no parafraseados.
curl -X POST https://invoxapi.de/v1/validate \ -H "X-API-Key: in_su_clave_aqui" \ -F "file=@factura.xml" \ -F "format=XRECHNUNG_3_UBL"Respuesta — una factura con dos defectos reales
{
"verdict": "invalid",
"errors": [
{
"rule_id": "BR-01",
"severity": "error",
"human_message": "Falta el identificador de especificación (BT-24).",
"bt_number": "BT-24",
"auto_fix_possible": true
},
{
"rule_id": "BR-04",
"severity": "error",
"human_message": "Falta el código de tipo de factura (BT-3).",
"bt_number": "BT-3",
"auto_fix_possible": true
}
],
"warnings": []
}
No solo "Invalid invoice" y nada más. Cada anomalía nombra el término comercial exacto (BT-x, del propio estándar EN 16931), si es posible una corrección automática, y una explicación en lenguaje claro — exactamente la información que un revisor humano necesitaría para corregir la factura.
{
"request_id": "8f2c1a9e-...-uuid",
"doc_hash": "0d19ba76...e9a10179",
"format": "XRECHNUNG_3_UBL",
"violation_count": 0,
"chain_entry_hash": "79cb4fc0...4336961f"
}
Dos cosas a destacar:
| doc_hash | Un hash SHA-256 de la factura — nunca el contenido de la factura en sí. Nada de lo que envía se almacena. |
| chain_entry_hash | Este resultado se añade a una cadena de hash append-only, a prueba de manipulaciones, y se firma (Ed25519) — verificable sin conexión, sin necesidad de confiar en los servidores de INVOX, por cualquiera que tenga la clave pública publicada. |
Cada resultado real que genere obtiene su propio request_id y su propia entrada en la cadena — esto es una ilustración del esquema, no un registro consultable. Para verificar una prueba firmada real, use el verificador público con un request_id de su propia cuenta.