Obtenir l’état actuel d’une facture
- Dans le bac à sable
En termes simples
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}$La facture.
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 GET "https://example.com/invoices/inv_bd8bc8b276f38643f1c0f24f" \ -H "Authorization: Bearer <your-api-key>"{ "invoice_ref": "CAPTURE-JSON-1790961440", "environment": "sandbox", "document_sha256": "45f857890231e9bc6e73c1ec1e53bc01e7b030f84068b324bdd9ef42b88322bc", "route": "DE-XRECHNUNG", "updated_at": "2026-10-06T19:49:02.676Z", "documents": [ { "sha256": "45f857890231e9bc6e73c1ec1e53bc01e7b030f84068b324bdd9ef42b88322bc", "kind": "canonical", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/canonical" }, { "sha256": "ad122fe72dc6f04b2de6b6bbc01fcb7e46e33116b12e3bbb02a569cde3f10106", "kind": "manifest", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/manifest" }, { "sha256": "941fd5005aa03586a7bf23f3039c6d15e38220879d46690f9199a494e35fdc11", "kind": "validation-report", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/validation-report" }, { "sha256": "251a52fec3bdd44555a7396a1567d62c5ada3e3b7d002bb757d6b50e347c2e90", "kind": "xrechnung-ubl", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/xrechnung-ubl" } ], "client": "acme-srl", "created_at": "2026-10-06T19:49:01.621Z", "id": "inv_936a93e38de84e7b0a1d7681", "state": "ready", "invoice_number": "DOC-mux3dlqm"}Arrêter une facture qui n’a pas encore été transmise POST
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.
Télécharger un document généré ou l’accusé du canal GET
Types : canonical (le JSON tel que reçu), erp-export (un export ERP tel que l’ERP l’a envoyé), le fichier tel qu’envoyé (ubl, cii, fa3, pdf), le document construit (xrechnung-ubl pour l’Allemagne, ubl ou fa3 sinon), validation-report et manifest (le SHA-256 des octets qui partent vers le canal, et les couches qui les ont contrôlés). Les quatre types JSON sont servis en application/json. L’ETag est le SHA-256.