Lister et rechercher des factures
- Dans le bac à sable
En termes simples
Une clé de client voit les factures de son propre client ; l’opérateur voit celles de tous les clients, ou celles d’un seul avec client. Les lignes portent ce que porte GET /invoices/{id}, sans documents, et aucun contenu de facture : ni acheteur ni montants,
ni date d’émission (pour la Roumanie et la Pologne, le deadline_at en découle, à quelques jours près). Un paramètre inconnu répond 400.
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?stringPartie de l’invoice_ref ou du numéro de facture, sans distinction de casse. 100 caractères au plus.
length <= 100route?array<>Un ou plusieurs canaux, séparés par des virgules.
state?array<>Un ou plusieurs états, séparés par des virgules.
client?stringFiltre de l’opérateur sur un client. Une clé de client ne peut nommer que son propre client ; tout autre répond 404. Une autre forme répond 400.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$received_from?stringPremier jour UTC de réception de la facture, inclus.
datereceived_to?stringDernier jour UTC de réception de la facture, inclus.
datesort?stringPar heure de réception. Les égalités sont départagées par l’identifiant, de sorte qu’une page ne se réorganise jamais d’un appel à l’autre.
"newest""newest""oldest"page?integer1 <= value1page_size?integer252550100200Une page de résultats.
application/json- response
data*array<>total*integerRésultats avant pagination.
page*integerLa page renvoyée. Une page au-delà de la fin est ramenée à la dernière.
page_size*integercounts_by_state*Résultats par état avec tous les filtres sauf state. Un état sans résultat est omis.
curl -X GET "https://example.com/invoices" \ -H "Authorization: Bearer <your-api-key>"{ "data": [ { "id": "string", "invoice_ref": "string", "invoice_number": "string", "route": "PEPPOL", "environment": "sandbox", "state": "received", "legal_id": "string", "buyer_status": "string", "document_sha256": "string", "attempts": [ { "id": "string", "state": "received", "created_at": "2019-08-24T14:15:22Z" } ], "errors": [ { "code": "string", "source": "string", "message": "string", "field": "string", "fix_hint": "string", "who_fixes": "us", "related": [ { "code": "string", "source": "string" } ] } ], "documents": [ { "kind": "string", "sha256": "string", "href": "string" } ], "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z", "deadline_at": "2019-08-24T14:15:22Z" } ], "total": 0, "page": 0, "page_size": 0, "counts_by_state": { "property1": 0, "property2": 0 }}Factures reçues et rejetées par jour et par canal GET
Calculé à partir du stockage à chaque appel. received compte les factures selon le jour UTC de leur arrivée ; rejected compte les factures désormais rejetées selon le jour UTC de leur dernière modification. Un jour sans rien a des zéros, de sorte qu’un graphique n’a pas de trous. Même périmètre que GET /invoices.
Soumettre une facture ou un avoir en JSON canonique POST
Le service contrôle d’emblée le document par rapport au modèle canonique et aux pré-contrôles, et répond 422 si l’un des deux échoue. Tout le reste s’exécute de façon asynchrone (construction, validation officielle, transmission au canal, statuts) et est signalé par des événements de statut. Une nouvelle soumission corrigée d’une facture rejetée utilise le même invoice_ref et une nouvelle Idempotency-Key ; le service relie les tentatives. En production, un export ERP n’est lu que si les paramètres du connecteur du client contiennent ses propres données de vendeur et de paiement, et non l’exemple du mapping : sinon 422 connector-settings-missing, qui indique ce qui manque. Un bac à sable le lit avec l’exemple, comme avant.