Lista i wyszukiwanie faktur otrzymanych
- W sandboxie
Od wersji 0.35.0. Te same parametry i ta sama odpowiedź co w GET /invoices, tylko dla faktur otrzymanych; state to
received, validated lub validation_failed. Klucz klienta widzi faktury własnego klienta; operator faktury wszystkich klientów albo
jednego klienta po podaniu client.
apiKeyAuthorizationBearer <token>Klucz należy wysyłać jako token typu bearer: Authorization: Bearer <your-api-key>. Wywołanie stanu usługi jest jedynym, które nie wymaga klucza.
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?integer252550100200Jedna strona wyników.
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 zdarzeń statusu jednej faktury otrzymanej GET
Od wersji 0.35.0. Te same zdarzenia, które dostarcza webhook, w kolejności numerów sekwencyjnych, każde z direction in.
Przekazanie faktury, którą klient otrzymał przez kanał POST
Od wersji 0.35.0 (17 paź. 2026). Treścią jest XML dokładnie taki, jaki dostarczył kanał (UBL, CII lub FA(3)); nic nie jest zmieniane i nic nie jest wysyłane. Plik jest najpierw zapisywany, zaszyfrowany kluczem danych klienta, ponieważ z mocy prawa jest już otrzymany; następnie sprawdzają go walidatory kanału, jak przy wysyłce bez zmian, a wynik przychodzi jako zdarzenie statusu (received, potem validated lub validation_failed, z direction: in) na webhook klienta i w GET /received/{id}/events. Plik, który nie spełnia reguł, jest zachowany i ma stan validation_failed z błędami; nigdy nie jest odrzucany. Plik, który nie jest fakturą do zachowania, jest odrzucany z kodem 422 i nic nie jest zapisywane, jak w POST /invoices/xml: DOCTYPE (EI-XML-DTD, nigdy nie parsowany), XML niepoprawnie sformułowany (EI-XML-SYNTAX) albo dokument, który nie jest fakturą znaną kanałowi (EI-XML-TYPE). Kontrola, której nie udało się uruchomić (walidator nie działa), jest ponawiana, a po ostatniej próbie faktura trafia na listę obsługi i pozostaje w stanie received. Klient przekazuje najwyżej 120 dokumentów na minutę i 2000 na dobę, niezależnie od użytego klucza (429, bez zapisu pod Idempotency-Key). Plik jest zwracany jako pobranie (Content-Disposition: attachment). Jeden dokument kanału to jedna faktura otrzymana przez klienta: według rail_id, gdy jest podany, według SHA-256 pliku, gdy go nie ma. Ten sam dokument ponownie daje odpowiedź 202 z duplicate_of; ten sam rail_id z innymi bajtami daje odpowiedź 409 received-id-conflict i nic nie jest zapisywane. Faktury otrzymane są przechowywane osobno od faktur, które klient wysyła: nie ma ich w GET /invoices, w serii, w metrykach ani w raporcie miesięcznym i nigdy nie blokują wysyłki tego samego pliku. Faktura otrzymana jest usuwana zgodnie z okresem przechowywania klienta, gdy nic na niej nie jest otwarte (jej kontrola się zakończyła albo osoba obsłużyła jej wiersz obsługi), i znajduje się w eksporcie klienta w received/. Zakres wysyłania; klucz klienta działa tylko dla własnego klienta.