Une facture conforme aujourd'hui peut échouer demain

Les référentiels EN16931/Peppol/XRechnung évoluent. Un scénario reçoit une nouvelle contrainte, une liste de codes se resserre, un profil cesse d'accepter une URN qu'il acceptait — et un modèle de facture qui validait sans problème le mois dernier commence à échouer aujourd'hui, sans que rien n'ait changé dans la facture elle-même. Le suivi de régression surveille un échantillon pour vous et vous indique précisément quelle règle se déclencherait désormais, avant que le système de votre client ne rejette la facture réelle.

Deux contrats de données — le seul endroit où un document est stocké

Chaque autre point d'entrée de ce service (/api/v1/validate, /api/v1/repair, /api/v1/validate/batch, les outils MCP) traite votre envoi en mémoire puis le supprime — voir la page confidentialité. Le suivi fonctionne différemment, et c'est voulu : une revalidation automatique ultérieure a besoin de quelque chose à revalider, donc POST /api/v1/watch exige que vous précisiez explicitement si cet échantillon peut être conservé.

  • "store_document": true — les octets de l'échantillon sont stockés. Lors d'un changement de référentiel, il est automatiquement revalidé et son statut se met à jour tout seul.
  • "store_document": false — seule une empreinte est stockée (hash, verdict, codes de règles déclenchés), jamais les octets. Lors d'un changement de référentiel, cette entrée est marquée needs_resubmit à la place — vous renvoyez le document quand vous êtes prêt.

Aucune des deux options n'est silencieuse, et il n'y a pas de valeur par défaut : omettre store_document fait échouer la requête avec un 400 qui explique le choix à faire.

Enregistrer un échantillon

curl -X POST "https://api.facturecheck.eu/api/v1/watch?label=acme-template&store_document=true" \
  -H "X-Api-Key: YOUR_API_KEY" \
  --data-binary @invoice.xml

Renvoie l'id de la nouvelle entrée, son verdict au moment de l'enregistrement, et les codes de règles alors déclenchés — la référence à laquelle chaque future revérification est comparée.

Revérifier un échantillon

Un échantillon stocké peut être revérifié à la demande, sans corps de requête — il est revalidé à partir de ses propres octets sauvegardés :

curl -X POST "https://api.facturecheck.eu/api/v1/watch/42/recheck" \
  -H "X-Api-Key: YOUR_API_KEY"

Une entrée en empreinte seule (store_document: false) n'a aucun octet sauvegardé : son appel de revérification prend donc le document dans le corps de la requête, comme l'enregistrement. Dans les deux cas, la réponse indique regressions (codes de règles qui se déclenchent désormais alors qu'ils ne le faisaient pas à l'enregistrement), resolved (codes de règles qui ne se déclenchent plus), et si le verdict global a changé.

Tous les échantillons stockés sous votre clé peuvent être revérifiés en un seul appel avec POST /api/v1/watch/recheck-all.

Ce qui se passe automatiquement

Au démarrage, le service compare le référentiel qu'il s'apprête à exécuter avec la dernière version enregistrée. S'ils diffèrent, chaque échantillon stocké enregistré sous l'ancienne version est automatiquement revalidé, et chaque entrée en empreinte seule est marquée needs_resubmit. Ce balayage automatique ne consomme jamais votre quota mensuel — seul un appel manuel recheck/ recheck-all, ou l'enregistrement d'un nouvel échantillon, en consomme (1 appel chacun). GET /api/v1/ruleset-status est public et ne nécessite aucune clé : il indique les versions actuelles du référentiel et la date de leur dernier changement.

Limites

PalierÉchantillons stockés max.Taille max. d'un échantillon
Free32 Mo
Pro50

Un échantillon stocké est supprimé immédiatement lors d'un DELETE /api/v1/watch/{id}, et automatiquement après 12 mois d'inactivité dans tous les cas.

Consulter la documentation API Valider votre facture gratuitement