Listați și căutați facturile primite
- În sandbox
De la versiunea 0.35.0. Aceiași parametri și același răspuns ca la GET /invoices, doar pentru facturile primite; state este
received, validated sau validation_failed. O cheie de client le vede pe ale propriului client; operatorul le vede pe ale tuturor clienților sau
pe ale unui client, cu client.
apiKeyAuthorizationBearer <token>Trimiteți cheia ca token de tip bearer: Authorization: Bearer <your-api-key>. Starea serviciului este singurul apel care nu necesită cheie.
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?integer252550100200O pagină de rezultate.
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 }}Listați evenimentele de stare ale unei facturi primite GET
De la versiunea 0.35.0. Aceleași evenimente pe care le livrează webhook-ul, în ordinea secvenței, fiecare cu direction in.
Predați o factură primită de client printr-un canal POST
De la versiunea 0.35.0 (17 oct. 2026). Corpul este XML-ul exact așa cum l-a livrat canalul (UBL, CII sau FA(3)); nu se modifică nimic și nu se trimite nimic. Fișierul este stocat mai întâi, sigilat cu cheia de date a clientului, deoarece în drept este deja primit; apoi validatoarele proprii ale canalului îl verifică, ca la o trimitere directă, iar rezultatul sosește ca eveniment de stare (received, apoi validated sau validation_failed, cu direction: in) pe webhook-ul clientului și la GET /received/{id}/events. Un fișier care nu respectă regulile este păstrat și apare ca validation_failed, cu erorile; nu este abandonat niciodată. Un fișier care nu este o factură de păstrat este refuzat cu 422 și nu se stochează nimic, ca la POST /invoices/xml: un DOCTYPE (EI-XML-DTD, niciodată analizat), XML care nu este bine format (EI-XML-SYNTAX) sau un document care nu este o factură cunoscută de canal (EI-XML-TYPE). O verificare care nu a putut rula (un validator indisponibil) este reluată, iar după ultima reîncercare factura intră în lista de gestionare și rămâne received. Un client predă cel mult 120 de documente pe minut și 2.000 pe zi, indiferent de cheia folosită (429, nepăstrat sub Idempotency-Key). Fișierul este returnat ca descărcare (Content-Disposition: attachment). Un document al canalului este o factură primită pentru client: după rail_id, când este dat, după SHA-256 al fișierului când nu este. Același document din nou primește 202 cu duplicate_of; același rail_id cu alți octeți primește 409 received-id-conflict, iar nimic nu se stochează. Facturile primite sunt păstrate separat de facturile pe care clientul le trimite: nu apar în GET /invoices, în serii, în metrici sau în raportul lunar și nu blochează niciodată o trimitere a aceluiași fișier. O factură primită este ștearsă odată cu retenția clientului, după ce nu mai este nimic deschis pe ea (verificarea s-a încheiat sau o persoană a rezolvat rândul ei din lista de gestionare), și se află în exportul clientului, sub received/. Domeniul de acces submit; o cheie de client acționează doar pentru propriul client.