Les fichiers construits de 200 factures au plus, dans un seul zip
- Dans le bac à sable
Depuis la 0.33.0 (16 oct. 2026). Corps {"ids": [...]}, de 1 à 200 identifiants de facture. Le zip contient un fichier par document
construit (UBL, CII, FA(3), XRechnung, Factur-X, ZUGFeRD, PDF, ou le XML tel que reçu pour une transmission directe), nommé
<invoice_number>.<xml|pdf> (avec le type ajouté quand une facture a deux fichiers XML), et manifest.csv avec
invoice_id,invoice_ref,invoice_number,route,state,file,kind,sha256. Le JSON canonique, le rapport de validation
et l’export de l’ERP en sont exclus. Un identifiant inconnu ou appartenant à un autre client est ignoré sans être nommé,
comme une facture dont aucun fichier n’est encore construit ; X-Export-Skipped les compte. Droit de lecture ; 10 exports par minute et par
client, partagés avec GET /exports/{dataset} ; une ligne d’audit data_exported avec le SHA-256 du zip.
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é.
application/json- body
ids*array<>1 <= items <= 200Le zip.
response?fileapplication/zipbinarycurl -X POST "https://example.com/invoices/export" \ -H "Authorization: Bearer <your-api-key>" \ -H "Content-Type: application/json" \ -d '{ "ids": [ "string" ] }'"string"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.
Obtenir l’état actuel d’une facture GET
Suivant