Get an invoice's current state
- In the sandbox
In plain words
apiKeyAuthorizationBearer <token>Send your key as a bearer token: Authorization: Bearer <your-api-key>. Health is the only call that needs no key.
id*stringThe invoice id returned by the submit call.
^inv_[A-Za-z0-9]{16,40}$The invoice.
application/json- response
id*stringinvoice_ref*stringinvoice_number?stringroute*RouteThe country route. The same values as country_route in status events.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"environment*string"sandbox""production"state*InvoiceStateThe service's own state for an invoice. Status events report the partner-facing lifecycle;
queued and submitting are internal steps between validated and submitted. validation_failed means the official rules refused the document; since
0.18.4 a check that did not run (KOSIT-RUN, EI-PDF-CHECK) retries instead, then ends dead_letter with that
code. A dead_letter keeps its document held, so the same file answers with duplicate_of; since 0.18.6 the
operator can cancel one for which no call to the route was made, and then the file can go again.
"received""source_error""validated""validation_failed""queued""submitting""submitted""ready""accepted""rejected""delivered""cancelled""dead_letter"legal_id?|KSeF number, ANAF upload index, access-point document ID, French platform invoice ID.
buyer_status?string|nulldocument_sha256?|^[a-f0-9]{64}$attempts?array<>Earlier submissions of the same invoice_ref (for example after a rejection and a fix).
errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timedeadline_at?stringAn indicative deadline for this invoice, as the last moment of its last permitted day in UTC (read the date part as that day): the issue date plus five working days for Romania (e-Factura), the next business day for Poland (KSeF offline24). Days are counted Monday to Friday and public holidays are not applied, so the real deadline can be later, never earlier; it is not legal advice. Given in every state of the invoice; it does not say the invoice was on time or late. Present only for those two routes, and only when the invoice carries an issue date: POST /invoices with an invoice.issue_date, or since 0.19.2 a UBL file (cbc:IssueDate) or an FA(3) file (Fa/P_1) sent as XML or dropped in the folder. A PDF carries none, and its absence does not mean no deadline applies. Since 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"}Stop an invoice that has not been submitted yet POST
Works only while the invoice is received, validated or queued. Since 0.18.3, once a send was tried and its answer was lost (a timeout or a 5xx), the invoice reads submitting and a cancel answers 409 send-in-progress, because the route may hold it; the worker settles it as submitted or dead_letter. Once the route has it, a cancellation is a business document (a credit note, or a KOR in Poland), not an API call. Since 0.18.5 a cancel of an invoice that is already cancelled answers 200 with it, so a retry after a lost answer is safe. Since 0.18.6 the operator's key may cancel a dead_letter invoice when no call to the route was ever made for it: nothing can be on the route, so the same document can be sent again afterwards. When a call was made, the answer is 409 dead-letter-reached-rail, because a send whose answer was lost may be there: check with the route first. A client's key gets 409 dead-letter; the operator decides.
Download a generated document or the route's receipt GET
Kinds: canonical (the JSON as received), erp-export (an ERP export as the ERP sent it), the file as sent (ubl, cii, fa3, pdf), the built document (xrechnung-ubl for Germany, ubl or fa3 otherwise), validation-report and manifest (the SHA-256 of the bytes that go to the route, and the layers that checked them). The four JSON kinds are served as application/json. The ETag is the SHA-256.