Zbudowane pliki do 200 faktur jako jeden plik zip
- W sandboxie
Od wersji 0.33.0 (16 paź. 2026). Treść {"ids": [...]}, od 1 do 200 identyfikatorów faktur. Plik zip zawiera jeden plik na każdy zbudowany
dokument (UBL, CII, FA(3), XRechnung, Factur-X, ZUGFeRD, PDF albo XML w postaci otrzymanej dla wysyłki bez zmian), nazwany
<invoice_number>.<xml|pdf> (z dodanym rodzajem, gdy jedna faktura ma dwa pliki XML), oraz manifest.csv z kolumnami
invoice_id,invoice_ref,invoice_number,route,state,file,kind,sha256. Kanoniczny JSON, raport walidacji
i eksport z ERP są pominięte. Identyfikator nieznany lub należący do innego klienta jest pomijany bez wskazania,
tak samo jak faktura, która nie ma jeszcze zbudowanego pliku; X-Export-Skipped je zlicza. Zakres odczytu; 10 eksportów na minutę na
klienta, wspólnie z GET /exports/{dataset}; wiersz audytu data_exported z SHA-256 pliku zip.
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.
application/json- body
ids*array<>1 <= items <= 200Plik zip.
response?fileapplication/zipbinarycurl -X POST "https://example.com/invoices/export" \ -H "Authorization: Bearer <your-api-key>" \ -H "Content-Type: application/json" \ -d '{ "ids": [ "string" ] }'"string"Zatrzymanie faktury, która nie została jeszcze przesłana POST
Działa tylko wtedy, gdy faktura ma stan received, validated lub queued. Od 0.18.3, jeśli wysyłkę podjęto, a jej odpowiedź zaginęła (przekroczenie czasu lub 5xx), faktura ma stan submitting, a anulowanie daje odpowiedź 409 send-in-progress, ponieważ kanał może ją mieć; proces roboczy ustala ją jako submitted lub dead_letter. Gdy kanał ją ma, anulowanie jest dokumentem biznesowym (notą kredytową, a w Polsce korektą KOR), a nie wywołaniem API. Od 0.18.5 anulowanie faktury, która jest już anulowana, daje odpowiedź 200 z tą fakturą, więc ponowienie po zaginionej odpowiedzi jest bezpieczne. Od 0.18.6 klucz operatora może anulować fakturę dead_letter, gdy nigdy nie wykonano dla niej wywołania do kanału: nic nie może być w kanale, więc ten sam dokument można potem wysłać ponownie. Gdy wywołanie wykonano, odpowiedzią jest 409 dead-letter-reached-rail, ponieważ wysyłka z zaginioną odpowiedzią mogła dotrzeć: najpierw należy sprawdzić w kanale. Klucz klienta dostaje 409 dead-letter; decyduje operator.
Pobranie bieżącego stanu faktury GET
Dalej