Pobranie bieżącego stanu faktury
- W sandboxie
Prostymi słowami
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.
id*stringIdentyfikator faktury zwrócony przez wywołanie przesłania.
^inv_[A-Za-z0-9]{16,40}$Faktura.
application/json- response
id*stringinvoice_ref*stringinvoice_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"environment*string"sandbox""production"state*InvoiceStateWłasny stan usługi dla faktury. Zdarzenia statusu zgłaszają cykl życia widoczny dla partnera;
queued i submitting to kroki wewnętrzne między validated a submitted. validation_failed oznacza, że oficjalne reguły odrzuciły dokument; od
0.18.4 kontrola, która się nie uruchomiła (KOSIT-RUN, EI-PDF-CHECK), jest ponawiana, a potem kończy jako dead_letter z tym
kodem. dead_letter zatrzymuje swój dokument, więc ten sam plik dostaje odpowiedź z duplicate_of; od 0.18.6
operator może anulować taką fakturę, dla której nie wykonano wywołania do kanału, i wtedy plik może zostać wysłany ponownie.
"received""source_error""validated""validation_failed""queued""submitting""submitted""ready""accepted""rejected""delivered""cancelled""dead_letter"legal_id?|Numer KSeF, indeks wysyłki do ANAF, identyfikator dokumentu w punkcie dostępowym, identyfikator faktury na francuskiej platformie.
buyer_status?string|nulldocument_sha256?|^[a-f0-9]{64}$attempts?array<>Wcześniejsze przesłania tej samej invoice_ref (na przykład po odrzuceniu i poprawce).
errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timedeadline_at?stringOrientacyjny termin dla tej faktury, jako ostatnia chwila jej ostatniego dozwolonego dnia w UTC (część z datą należy czytać jako ten dzień): data wystawienia plus pięć dni roboczych dla Rumunii (e-Factura), następny dzień roboczy dla Polski (KSeF offline24). Dni są liczone od poniedziałku do piątku, a święta nie są uwzględniane, więc rzeczywisty termin może być późniejszy, nigdy wcześniejszy; nie jest to porada prawna. Podawany w każdym stanie faktury; nie mówi, że faktura była na czas lub spóźniona. Obecny tylko dla tych dwóch kanałów i tylko wtedy, gdy faktura ma datę wystawienia: POST /invoices z invoice.issue_date, albo od 0.19.2 plik UBL (cbc:IssueDate) lub plik FA(3) (Fa/P_1) wysłany jako XML lub upuszczony w folderze. PDF jej nie zawiera, a jej brak nie oznacza, że żaden termin nie obowiązuje. Od 0.19.1.
date-timecurl -X GET "https://example.com/invoices/inv_bd8bc8b276f38643f1c0f24f" \ -H "Authorization: Bearer <your-api-key>"{ "invoice_ref": "CAPTURE-JSON-1790961440", "environment": "sandbox", "document_sha256": "45f857890231e9bc6e73c1ec1e53bc01e7b030f84068b324bdd9ef42b88322bc", "route": "DE-XRECHNUNG", "updated_at": "2026-10-06T19:49:02.676Z", "documents": [ { "sha256": "45f857890231e9bc6e73c1ec1e53bc01e7b030f84068b324bdd9ef42b88322bc", "kind": "canonical", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/canonical" }, { "sha256": "ad122fe72dc6f04b2de6b6bbc01fcb7e46e33116b12e3bbb02a569cde3f10106", "kind": "manifest", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/manifest" }, { "sha256": "941fd5005aa03586a7bf23f3039c6d15e38220879d46690f9199a494e35fdc11", "kind": "validation-report", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/validation-report" }, { "sha256": "251a52fec3bdd44555a7396a1567d62c5ada3e3b7d002bb757d6b50e347c2e90", "kind": "xrechnung-ubl", "href": "/invoices/inv_936a93e38de84e7b0a1d7681/documents/xrechnung-ubl" } ], "client": "acme-srl", "created_at": "2026-10-06T19:49:01.621Z", "id": "inv_936a93e38de84e7b0a1d7681", "state": "ready", "invoice_number": "DOC-mux3dlqm"}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 wygenerowanego dokumentu lub potwierdzenia z kanału GET
Rodzaje: canonical (JSON w postaci odebranej), erp-export (eksport z ERP w postaci wysłanej przez ERP), plik w postaci wysłanej (ubl, cii, fa3, pdf), zbudowany dokument (xrechnung-ubl dla Niemiec, w pozostałych przypadkach ubl lub fa3), validation-report i manifest (SHA-256 bajtów wysyłanych do kanału oraz warstwy, które je sprawdziły). Cztery rodzaje JSON są zwracane jako application/json. ETag to SHA-256.