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éeneeds_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 |
|---|---|---|
| Free | 3 | 2 Mo |
| Pro | 50 |
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