Die erstellten Dateien von bis zu 200 Rechnungen als eine Zip-Datei
- In der Sandbox
Seit 0.33.0 (16. Okt. 2026). Body {"ids": [...]}, 1 bis 200 Rechnungs-IDs. Die Zip-Datei enthält eine Datei je erstelltem
Dokument (UBL, CII, FA(3), XRechnung, Factur-X, ZUGFeRD, PDF oder das XML, wie es beim Durchreichen empfangen wurde), benannt
<invoice_number>.<xml|pdf> (mit angefügter Art, wenn eine Rechnung zwei XML-Dateien hat), und manifest.csv mit
invoice_id,invoice_ref,invoice_number,route,state,file,kind,sha256. Das kanonische JSON, der Validierungsbericht
und der Export des ERP bleiben außen vor. Eine ID, die unbekannt ist oder zu einem anderen Kunden gehört, wird übersprungen, ohne genannt zu werden,
ebenso eine Rechnung, für die noch keine erstellte Datei vorliegt; X-Export-Skipped zählt sie. Der Scope read; 10 Exporte pro Minute und
Kunde, gemeinsam mit GET /exports/{dataset}; eine Audit-Zeile data_exported mit dem SHA-256 der Zip-Datei.
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.
application/json- body
ids*array<>1 <= items <= 200Die Zip-Datei.
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"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.
Den aktuellen Zustand einer Rechnung abrufen GET
Weiter