Arrêter une facture qui n’a pas encore été transmise
- Dans le bac à sable
En termes simples
Ne fonctionne que tant que la facture est received, validated ou queued. Depuis la 0.18.3, quand un envoi a été tenté et que sa
réponse s’est perdue (délai dépassé ou erreur 5xx), la facture est en submitting et une annulation répond 409
send-in-progress, car le canal peut la détenir ; le traitement la règle ensuite en submitted ou dead_letter. Une fois
que le canal l’a, une annulation est un document commercial (un avoir, ou un KOR en Pologne), pas un appel d’API.
Depuis la 0.18.5, l’annulation d’une facture déjà annulée répond 200 avec elle, de sorte qu’un nouvel essai après une réponse
perdue est sans risque. Depuis la 0.18.6, la clé de l’opérateur peut annuler une facture dead_letter quand aucun appel au canal n’a
jamais été fait pour elle : rien ne peut être sur le canal, donc le même document peut être renvoyé ensuite. Quand un appel
a été fait, la réponse est 409 dead-letter-reached-rail, car un envoi dont la réponse s’est perdue peut s’y trouver : vérifiez
d’abord auprès du canal. Une clé de client reçoit 409 dead-letter ; l’opérateur décide.
apiKeyAuthorizationBearer <token>Envoyez votre clé sous forme de jeton bearer : Authorization: Bearer <your-api-key>. L’état du service est le seul appel qui ne nécessite pas de clé.
id*stringL’identifiant de facture renvoyé par l’appel de soumission.
^inv_[A-Za-z0-9]{16,40}$Idempotency-Key*stringUne clé unique par requête logique (un UUID convient). Conservée aussi longtemps que les données du client. Avec la clé de l’opérateur, elle ne peut pas commencer par client: (400), la forme sous laquelle les clés de client sont stockées.
8 <= length <= 100Annulée avant la transmission, une facture en échec définitif qui n’a jamais atteint le canal (clé de l’opérateur), ou déjà annulée.
application/json- response
id*stringinvoice_ref*stringinvoice_number?stringroute*RouteLe canal du pays. Les mêmes valeurs que country_route dans les événements de statut.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"environment*string"sandbox""production"state*InvoiceStateL’état propre au service pour une facture. Les événements de statut rapportent le cycle de vie visible du partenaire ;
queued et submitting sont des étapes internes entre validated et submitted. validation_failed signifie que les règles officielles ont refusé le document ; depuis la
0.18.4, un contrôle qui n’a pas pu s’exécuter (KOSIT-RUN, EI-PDF-CHECK) est retenté, puis finit en dead_letter avec ce
code. Une dead_letter garde son document, de sorte que le même fichier répond avec duplicate_of ; depuis la 0.18.6, l’
opérateur peut annuler celle pour laquelle aucun appel au canal n’a été fait, et le fichier peut alors repartir.
"received""source_error""validated""validation_failed""queued""submitting""submitted""ready""accepted""rejected""delivered""cancelled""dead_letter"legal_id?|Numéro KSeF, index de dépôt ANAF, identifiant de document du point d’accès, identifiant de facture de la plateforme française.
buyer_status?string|nulldocument_sha256?|^[a-f0-9]{64}$attempts?array<>Soumissions antérieures du même invoice_ref (par exemple après un rejet et une correction).
errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timedeadline_at?stringUne échéance indicative pour cette facture, comme le dernier instant de son dernier jour permis en UTC (lisez la date comme ce jour) : la date d’émission plus cinq jours ouvrés pour la Roumanie (e-Factura), le jour ouvré suivant pour la Pologne (KSeF offline24). Les jours sont comptés du lundi au vendredi et les jours fériés ne sont pas appliqués, donc l’échéance réelle peut être plus tardive, jamais plus précoce ; ce n’est pas un conseil juridique. Donnée à chaque état de la facture ; elle ne dit pas si la facture était à temps ou en retard. Présente uniquement pour ces deux canaux, et seulement quand la facture porte une date d’émission : POST /invoices avec un invoice.issue_date, ou, depuis la 0.19.2, un fichier UBL (cbc:IssueDate) ou FA(3) (Fa/P_1) envoyé en XML ou déposé dans le dossier. Un PDF n’en porte aucune, et son absence ne veut pas dire qu’aucune échéance ne s’applique. Depuis la 0.19.1.
date-timecurl -X POST "https://example.com/invoices/inv_bd8bc8b276f38643f1c0f24f/cancel" \ -H "Authorization: Bearer <your-api-key>" \ -H "Idempotency-Key: order-2026-0001"{ "invoice_ref": "FRESH-mux3dlqm-0", "environment": "sandbox", "document_sha256": "b341c81da6fe297787829a8c26fd4b25106b5b34e67482d38c1039651bbfed65", "route": "DE-XRECHNUNG", "updated_at": "2026-10-06T19:49:10.992Z", "client": "acme-srl", "created_at": "2026-10-06T19:49:10.816Z", "id": "inv_ae4d9834bf251353532fe5ee", "state": "cancelled", "invoice_number": "FRESH-mux3dlqm-0"}Stocker un identifiant d’accès, chiffré ; la valeur n’est jamais renvoyée POST
Un processus ne stocke des identifiants d’accès que pour son propre environnement. legal_entity en lie un à l’identifiant du vendeur pour lequel il agit (numéro de TVA, NIP, SIREN ou identifiant d’entreprise) ; un identifiant sans cette étiquette sert les autres factures du client. La clé d’administration d’un client ne stocke que pour son propre client.
Obtenir l’état actuel d’une facture GET
Suivant