Lister et rechercher les factures reçues
- Dans le bac à sable
Depuis la 0.35.0. Les mêmes paramètres et la même réponse que GET /invoices, pour les factures reçues uniquement ; state vaut
received, validated ou validation_failed. Une clé de client voit celles de son client ; l’opérateur voit celles de tous les clients, ou
celles d’un seul avec client.
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é.
q?stringlength <= 100route?array<>state?array<>client?string^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$received_from?stringdatereceived_to?stringdatesort?string"newest""newest""oldest"page?integer1 <= value1page_size?integer252550100200Une page de résultats.
application/json- response
data*array<>total*integerpage*integerpage_size*integercounts_by_state*curl -X GET "https://example.com/received" \ -H "Authorization: Bearer <your-api-key>"{ "data": [ { "id": "string", "invoice_ref": "string", "invoice_number": "string", "route": "PEPPOL", "client": "string", "environment": "sandbox", "state": "received", "direction": "in", "rail_id": "string", "document_sha256": "string", "duplicate_of": "string", "links": { "self": "string", "events": "string" }, "errors": [ { "code": "string" } ], "documents": [ { "kind": "received-xml", "sha256": "string", "href": "string" } ], "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z" } ], "total": 0, "page": 0, "page_size": 0, "counts_by_state": { "property1": 0, "property2": 0 }}Lister les événements de statut d’une facture reçue GET
Depuis la 0.35.0. Les mêmes événements que ceux livrés par le webhook, dans l’ordre de séquence, chacun avec direction valant in.
Remettre une facture que le client a reçue par un canal POST
Depuis la 0.35.0 (17 oct. 2026). Le corps est le XML tel que le canal l’a livré (UBL, CII ou FA(3)) ; rien n’est modifié et rien n’est envoyé. Le fichier est d’abord stocké, scellé sous la clé de données du client, car en droit il est déjà reçu ; ensuite les validateurs propres au canal le contrôlent, comme pour un envoi en transmission directe, et le résultat arrive sous la forme d’un événement de statut (received, puis validated ou validation_failed, avec direction: in) sur le webhook du client et sur GET /received/{id}/events. Un fichier qui échoue aux règles est conservé et affiche validation_failed avec les erreurs ; il n’est jamais supprimé. Un fichier qui n’est pas une facture à conserver est refusé avec un 422 et rien n’est stocké, comme sur POST /invoices/xml : un DOCTYPE (EI-XML-DTD, jamais analysé), un XML mal formé (EI-XML-SYNTAX), ou un document qui n’est pas une facture connue du canal (EI-XML-TYPE). Un contrôle qui n’a pas pu s’exécuter (validateur indisponible) est relancé, et après la dernière nouvelle tentative la facture passe sur la liste de suivi et reste received. Un client remet au plus 120 documents par minute et 2 000 par jour, quelle que soit la clé utilisée (429, non conservé sous l’Idempotency-Key). Le fichier est restitué en téléchargement (Content-Disposition: attachment). Un document de canal correspond à une facture reçue pour le client : par rail_id quand il est fourni, par le SHA-256 du fichier sinon. Le même document renvoyé répond 202 avec duplicate_of ; le même rail_id avec d’autres octets répond 409 received-id-conflict, et rien n’est stocké. Les factures reçues sont tenues à part des factures que le client envoie : elles ne figurent ni dans GET /invoices, ni dans les séries, ni dans les métriques, ni dans le rapport mensuel, et elles ne bloquent jamais l’envoi du même fichier. Une facture reçue est supprimée avec la conservation du client dès que plus rien n’est ouvert sur elle (son contrôle est terminé, ou une personne a traité sa ligne de suivi), et figure dans l’export du client sous received/. Droit d’envoi (submit) ; une clé de client agit pour son propre client uniquement.