Przekazanie faktury, którą klient otrzymał przez kanał
- W sandboxie
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.
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.
route*stringKanał, którym przyszedł dokument.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"rail_id?stringWłasny identyfikator dokumentu w kanale (identyfikator dokumentu punktu dostępowego, numer KSeF, identyfikator pobierania ANAF). Od 1 do 200 liter, cyfr i znaków . _ : / @ + = # -.
^[A-Za-z0-9._:/@+=#-]{1,200}$client?stringKlient, który go otrzymał. Klucz operatora go wskazuje (po pominięciu: własny klient operatora local); klucz klienta może go pominąć albo wskazać własnego klienta, a każdy inny daje odpowiedź 403.
^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$Idempotency-Key*stringUnikalny klucz na każde logiczne żądanie (wystarczy UUID). Klucz zaczynający się od erp: (erp:{connector}:{scope}:{entity}:{id} z przepisu transportu ERP, z kluczem operatora lub klienta) nie ma okna czasowego; jest zachowany ze swoją pierwszą odpowiedzią, dopóki klient albo utworzona przez niego faktura nie zostanie usunięta, więc zmieniony dokument przekazany ponownie po tygodniach nadal dostaje 409 idempotency-conflict. Taki klucz jest przyjmowany tylko przy eksporcie konektora ERP (POST /invoices z connector, który ta wersja odczytuje, z export będącym niepustym obiektem JSON i z kluczem operatora client); przy każdym innym żądaniu, dokumencie kanonicznym, POST /invoices/xml lub anulowaniu, daje 400 idempotency-key-not-allowed i nic nie jest zachowywane, a eksport z liczbą dłuższą niż 40 znaków dostaje 422 EI-SCHEMA, jakie dostaje pod każdym innym kluczem, także niezachowane pod żadnym kluczem. Gdy operator zwalnia dead letter (anuluje go), wcześniejsze odpowiedzi dotyczące tej faktury znikają razem z nim, przesłania i, od wersji 0.35.0, wcześniejszego odrzuconego anulowania, więc ponowienie tego anulowania uruchamia się znów i odpowiada 200 z fakturą anulowaną. Od wersji 0.32.0 odpowiedź 5xx i 422 connector-settings-missing nie są zachowywane, więc to samo żądanie z tym samym kluczem można wysłać ponownie. Z kluczem operatora nie może zaczynać się od client: (400), czyli postaci, pod którą zapisywane są klucze klientów.
8 <= length <= 100body*stringapplication/xmlZapisana i w kolejce do kontroli kanału, chyba że już zakończyła się błędem; albo już przechowywana (duplicate_of).
application/json- response
Od wersji 0.35.0. Faktura, którą klient otrzymał przez kanał, w postaci, w jakiej przyjął ją POST /received. Tak jak Invoice,
nie zawiera treści faktury: ani sprzedawcy, ani nabywcy, ani kwot.
id*string^rcv_[0-9a-f]{24}$invoice_ref*stringWłasny numer faktury z pliku (BT-1; FA(3) Fa/P_2), w przeciwnym razie rail_id, w przeciwnym razie identyfikator.
invoice_number?stringroute*RouteKrajowy kanał przesyłania. Te same wartości co country_route w zdarzeniach statusu.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"client*stringenvironment*string"sandbox""production"state*string"received""validated""validation_failed"direction*"in""in"rail_id?stringWłasny identyfikator dokumentu w kanale, podany w POST /received.
document_sha256*string^[a-f0-9]{64}$duplicate_of?stringTylko w POST /received, gdy dokument był już przechowywany dla klienta i kanału.
links?errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timecurl -X POST "https://example.com/received?route=PEPPOL" \ -H "Authorization: Bearer <your-api-key>" \ -H "Idempotency-Key: order-2026-0001" \ -H "Content-Type: application/xml" \ -d 'string'{ "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"}Lista i wyszukiwanie faktur otrzymanych GET
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.
Wyszukanie kodu błędu lub przyczyny GET
Zwraca wpis katalogu dla identyfikatora reguły, kodu błędu kanału lub francuskiego kodu przyczyny (identyfikatory i aliasy).