Den aktuellen Zustand einer Rechnung abrufen
- In der Sandbox
In einfachen Worten
apiKeyAuthorizationBearer <token>Senden Sie Ihren Schlüssel als Bearer-Token: Authorization: Bearer <your-api-key>. Der Systemzustand ist der einzige Aufruf, der keinen Schlüssel braucht.
id*stringDie ID der Rechnung, die der Übermittlungsaufruf zurückgegeben hat.
^inv_[A-Za-z0-9]{16,40}$Die Rechnung.
application/json- response
id*stringinvoice_ref*stringinvoice_number?stringroute*RouteDer Übermittlungsweg. Dieselben Werte wie country_route in Statusereignissen.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"environment*string"sandbox""production"state*InvoiceStateDer eigene Zustand des Service für eine Rechnung. Statusereignisse melden den Lebenszyklus aus Sicht des Partners;
queued und submitting sind interne Schritte zwischen validated und submitted. validation_failed bedeutet, dass die offiziellen Regeln das Dokument abgelehnt haben; seit
0.18.4 wird eine Prüfung, die nicht lief (KOSIT-RUN, EI-PDF-CHECK), wiederholt und endet dann als dead_letter mit diesem
Code. Eine dead_letter hält ihr Dokument fest, sodass dieselbe Datei mit duplicate_of beantwortet wird; seit 0.18.6 kann der
Betreiber eine stornieren, für die kein Aufruf an den Übermittlungsweg gemacht wurde, und die Datei kann dann erneut gesendet werden.
"received""source_error""validated""validation_failed""queued""submitting""submitted""ready""accepted""rejected""delivered""cancelled""dead_letter"legal_id?|KSeF-Nummer, ANAF-Upload-Index, Dokument-ID des Access Points, Rechnungs-ID der französischen Plattform.
buyer_status?string|nulldocument_sha256?|^[a-f0-9]{64}$attempts?array<>Frühere Übermittlungen derselben invoice_ref (zum Beispiel nach einer Ablehnung und einer Korrektur).
errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timedeadline_at?stringEine Richtfrist für diese Rechnung, als letzter Moment ihres letzten zulässigen Tages in UTC (lesen Sie den Datumsteil als diesen Tag): das Ausstellungsdatum plus fünf Werktage für Rumänien (e-Factura), der nächste Geschäftstag für Polen (KSeF offline24). Die Tage werden von Montag bis Freitag gezählt, gesetzliche Feiertage werden nicht berücksichtigt, die tatsächliche Frist kann also später liegen, nie früher; es ist keine Rechtsberatung. In jedem Zustand der Rechnung angegeben; sie sagt nicht, ob die Rechnung rechtzeitig oder verspätet war. Nur für diese beiden Übermittlungswege vorhanden, und nur wenn die Rechnung ein Ausstellungsdatum trägt: POST /invoices mit einem invoice.issue_date, oder seit 0.19.2 eine UBL-Datei (cbc:IssueDate) oder eine FA(3)-Datei (Fa/P_1), als XML gesendet oder im Ordner abgelegt. Ein PDF trägt keines, und sein Fehlen heißt nicht, dass keine Frist gilt. Seit 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"}Eine Rechnung stoppen, die noch nicht übermittelt wurde POST
Funktioniert nur, solange die Rechnung received, validated oder queued ist. Seit 0.18.3 gilt: Wurde ein Versand versucht und ging seine Antwort verloren (ein Timeout oder ein 5xx), steht die Rechnung auf submitting, und ein Stornieren wird mit 409 send-in-progress beantwortet, weil der Übermittlungsweg sie haben kann; der Worker setzt sie dann auf submitted oder dead_letter. Hat der Übermittlungsweg sie, ist eine Stornierung ein Geschäftsdokument (eine Gutschrift, oder in Polen eine KOR), kein API-Aufruf. Seit 0.18.5 beantwortet ein Stornieren einer bereits stornierten Rechnung mit 200 und der Rechnung, damit eine Wiederholung nach einer verlorenen Antwort sicher ist. Seit 0.18.6 darf der Schlüssel des Betreibers eine dead_letter-Rechnung stornieren, wenn für sie nie ein Aufruf an den Übermittlungsweg gemacht wurde: Dort kann nichts liegen, daher kann dasselbe Dokument danach erneut gesendet werden. Wurde ein Aufruf gemacht, lautet die Antwort 409 dead-letter-reached-rail, weil ein Versand mit verlorener Antwort dort liegen kann: Prüfen Sie zuerst beim Übermittlungsweg. Ein Kundenschlüssel erhält 409 dead-letter; der Betreiber entscheidet.
Ein erzeugtes Dokument oder die Quittung des Übermittlungswegs herunterladen GET
Arten: canonical (das JSON, wie empfangen), erp-export (ein ERP-Export, wie das ERP ihn gesendet hat), die Datei, wie gesendet (ubl, cii, fa3, pdf), das erstellte Dokument (xrechnung-ubl für Deutschland, sonst ubl oder fa3), validation-report und manifest (das SHA-256 der Bytes, die an den Übermittlungsweg gehen, und die Ebenen, die sie geprüft haben). Die vier JSON-Arten werden als application/json ausgeliefert. Der ETag ist das SHA-256.