Docs

Pobranie bieżącego stanu faktury

  • W sandboxie

Prostymi słowami

Pokazuje, na jakim etapie jest jedna faktura.
GET
/invoices/{id}

Autoryzacja

apiKey
headerAuthorizationBearer <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.

Parametry ścieżki

id*string

Identyfikator faktury zwrócony przez wywołanie przesłania.

Wzorzec^inv_[A-Za-z0-9]{16,40}$

Treść odpowiedzi

Faktura.

application/json
  1. response
id*string
invoice_ref*string
invoice_number?string
route*Route

Krajowy kanał przesyłania. Te same wartości co country_route w zdarzeniach statusu.

Wartość spośród"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"
environment*string
Wartość spośród"sandbox""production"
state*InvoiceState

Wł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.

Wartość spośród"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|null
document_sha256?|
Wzorzec^[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*string
Formatdate-time
updated_at*string
Formatdate-time
deadline_at?string

Orientacyjny 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.

Formatdate-time
curl -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.