Externe API V1 Dokumentation

Rechnungsdokument konvertieren

Strukturierte Daten konvertieren

Task-Status abfragen

Laden Sie ein PDF-, DOCX- oder TXT-Rechnungsdokument hoch und starten Sie die asynchrone Konvertierung. Gibt eine task_id für das Polling zurück. ZUGFeRD/Factur-X-Hybrid-PDFs erfordern einen PDF-Quellupload; für DOCX/TXT-Quellen sollten XML-Ergebnisse angefragt werden. Eingebettete Rechnungs-XML wird standardmäßig ignoriert; setzen Sie use_embedded_xml=true nur, wenn Ihre Integration sie als primäre Extraktionsquelle akzeptiert. Anfrage: multipart/form-data; file (binary, erforderlich) — PDF-, DOCX- oder TXT-Rechnungsdokument; alte DOC/RTF-, Bild- und andere Dateien werden abgelehnt; format (string, erforderlich) — Zielausgabeformat; siehe Formatmatrix unten; profile (string, optional, empfohlen für deterministische Integrationen) — explizites Compliance-Profil, Groß-/Kleinschreibung wird ignoriert. Jedes Format hat eine abgeschlossene Menge zulässiger Profile und genau einen Standard: XRECHNUNG → [XRECHNUNG] (Standard XRECHNUNG); EN16931 → [EN16931] (Standard EN16931); UBL → [XRECHNUNG, PEPPOL, EN16931] (Standard EN16931); CII → [XRECHNUNG, EN16931, ZUGFERD_EN16931, ZUGFERD_FACTURX_EXTENDED, ZUGFERD_XRECHNUNG] (Standard EN16931); ZUGFERD → [ZUGFERD_EN16931, ZUGFERD_FACTURX_EXTENDED, ZUGFERD_XRECHNUNG] (Standard ZUGFERD_EN16931). ZUGFERD, FACTURX, FACTUR-X und FACTUR_X sind Aliase für ZUGFERD_EN16931; ZUGFERD-XRECHNUNG ist ein Alias für ZUGFERD_XRECHNUNG. Ein Wert außerhalb der zulässigen Menge liefert 422 OUTPUT_PROFILE_CONFLICT; ein nicht erkannter Profilname liefert 422 INVALID_PROFILE mit details.allowed_profiles; jurisdiction (string, optional) — expliziter ISO-3166-1-Alpha-2-Jurisdiktionskontext für Validierungs-/Hinweisprüfungen; überschreibt das Profil nicht; transaction_scope (string, optional) — expliziter Transaktionskontext, zum Beispiel B2G; wird auf die eingereihte Aufgabe angewendet; delivery_channel (string, optional) — einer von PEPPOL, DIRECT_XML, PORTAL, EMAIL_PDF, UNKNOWN; wird auf die eingereihte Aufgabe angewendet; client_reference oder external_invoice_id (string, optional) — kundenseitige Rechnungs-/Jobreferenz, die in angenommenen Uploads und Task-Statusantworten zurückgegeben wird; source_system (string, optional) — vorgelagertes ERP- oder Abrechnungssystem, das in angenommenen Uploads und Task-Statusantworten zurückgegeben wird; email_input (Freitext, optional, nur PDF-Quellen) — Kundenanweisungen in beliebiger Sprache, bis zu 10.000 Zeichen, ohne E-Mail-Blockmarkierungen übergeben; alle KI-Extraktions- und Korrekturschritte erhalten sie getrennt vom Rechnungsquelltext; nicht mit use_embedded_xml=true kombinierbar, Teil der Request-Identität für Idempotenz und von invoices:convert-structured nicht unterstützt; die normale Rechnungsvalidierung gilt weiterhin; use_seller_master_data (boolean, optional) — ohne Angabe gilt der Standard aus dem Tenant-Profil; false ignoriert gespeicherte Verkäufer-Stammdaten für diesen Request, true stellt Verkäufer-Stammdaten bereit bzw. nutzt sie; seller_master_data (JSON-Objekt-String, optional) — request-bezogene Verkäufer-Stammdaten, die nur bei use_seller_master_data=true verwendet werden; unterstützt werden Firmen-, Adress-, Steuer-, Kontakt- und Zahlungsfelder (payment_means_code 30/42/58, payment_iban, payment_bic, payment_account_name, payment_terms_note); jeder Profilwert ersetzt den entsprechenden extrahierten Wert, nicht gesetzte Profilfelder bleiben unverändert und Abweichungen erzeugen nicht blockierende Warnungen; electronic_address und electronic_address_scheme müssen gemeinsam gesetzt oder beide weggelassen werden; use_embedded_xml (boolean, optional, Standard false) — eingebettete Factur-X-, ZUGFeRD- oder XRechnung-XML wird ignoriert, außer der Wert ist ausdrücklich true; nur verwenden, wenn die Integration die eingebettete XML als primäre Extraktionsquelle akzeptiert. Antwort: 202 Accepted.

Laden Sie ein Träger-PDF plus CSV-, JSON-, XML-, XLSX- oder TXT-Rechnungsdaten hoch und starten Sie die asynchrone Konvertierung aus strukturierten Daten. Die data_file-Parts sind die einzige semantische Quelle; das PDF füllt keine fehlenden Rechnungsfelder auf. Für ZUGFeRD/Factur-X wird es als Träger-PDF verwendet, bei XML-orientierten Ausgaben als eingereichtes PDF-Artefakt gespeichert. Nutzen Sie einen Konvertierungsrequest pro Rechnung; wiederholen Sie data_file nur für gesplittete ERP-Exporte derselben Rechnung. Anfrage: multipart/form-data; pdf_file (binary, erforderlich) — Träger-PDF für ZUGFeRD/Factur-X-Einbettung und Speicherung bei XML-orientierten Ausgaben; data_file (binary, erforderlich, wiederholbar) — CSV-, JSON-, XML-, XLSX- oder TXT-Rechnungsdaten als einzige semantische Quelle; .xls, PDFs und Bilddateien werden als data_file abgelehnt; für gesplittete Header-/Positions-Exporte derselben Rechnung wiederholen; die Aliasse data_files und data_files[] werden akzeptiert; Gesamtgröße strukturierter Daten — maximal 2 MB über alle data_file-Parts; format (string, erforderlich) — Ziel-Ausgabeformat; unterstützt XRECHNUNG, ZUGFERD, EN16931, UBL und CII; profile (string, optional, empfohlen für deterministische Integrationen) — explizites Compliance-Profil, Groß-/Kleinschreibung wird ignoriert. Jedes Format hat eine abgeschlossene Menge zulässiger Profile und genau einen Standard: XRECHNUNG → [XRECHNUNG] (Standard XRECHNUNG); EN16931 → [EN16931] (Standard EN16931); UBL → [XRECHNUNG, PEPPOL, EN16931] (Standard EN16931); CII → [XRECHNUNG, EN16931, ZUGFERD_EN16931, ZUGFERD_FACTURX_EXTENDED, ZUGFERD_XRECHNUNG] (Standard EN16931); ZUGFERD → [ZUGFERD_EN16931, ZUGFERD_FACTURX_EXTENDED, ZUGFERD_XRECHNUNG] (Standard ZUGFERD_EN16931). Ein Wert außerhalb der zulässigen Menge liefert 422 OUTPUT_PROFILE_CONFLICT; ein nicht erkannter Profilname liefert 422 INVALID_PROFILE mit details.allowed_profiles; jurisdiction (string, optional) — expliziter ISO-3166-1-Alpha-2-Jurisdiktionskontext für Validierungs-/Hinweisprüfungen; überschreibt das Profil nicht; transaction_scope (string, optional) — expliziter Transaktionskontext, zum Beispiel B2G; wird auf die eingereihte Aufgabe angewendet; delivery_channel (string, optional) — einer von PEPPOL, DIRECT_XML, PORTAL, EMAIL_PDF, UNKNOWN; wird auf die eingereihte Aufgabe angewendet; client_reference oder external_invoice_id (string, optional) — kundenseitige Rechnungs-/Jobreferenz, die in angenommenen Uploads und Task-Statusantworten zurückgegeben wird; source_system (string, optional) — vorgelagertes ERP- oder Abrechnungssystem, das in angenommenen Uploads und Task-Statusantworten zurückgegeben wird; use_seller_master_data (boolean, optional) — ohne Angabe gilt der Standard aus dem Tenant-Profil; false ignoriert gespeicherte Verkäufer-Stammdaten für diesen Request, true stellt Verkäufer-Stammdaten bereit bzw. nutzt sie; seller_master_data (JSON-Objekt-String, optional) — request-bezogene Verkäufer-Stammdaten, die nur bei use_seller_master_data=true verwendet werden; unterstützt werden Firmen-, Adress-, Steuer-, Kontakt- und Zahlungsfelder (payment_means_code 30/42/58, payment_iban, payment_bic, payment_account_name, payment_terms_note); jeder Profilwert ersetzt den entsprechenden extrahierten Wert, nicht gesetzte Profilfelder bleiben unverändert und Abweichungen erzeugen nicht blockierende Warnungen; electronic_address und electronic_address_scheme müssen gemeinsam gesetzt oder beide weggelassen werden. Antwort: 202 Accepted.

Fragen Sie den aktuellen Status eines Konvertierungs-Tasks ab. Gibt pending (angenommen und in der Queue, noch nicht gestartet), processing, completed oder failed zurück. Rate-Limit 10/min und 120/hour; das ist die bindende Grenze für das Polling: Warten Sie nach dem angenommenen 202 etwa 20 Sekunden bis zum ersten Aufruf, erhöhen Sie danach die Abstände (20s, 30s, 45s, 60s und ab dann 60s) und beenden Sie das Polling bei completed oder failed. Abgeschlossene Tasks enthalten result_artifacts-Diagnosen, damit Clients sehen können, welche XML/PDF-Artefakte verfügbar, im Cache gespeichert und durch Validierung verifiziert sind. Payloads abgeschlossener Tasks können zusätzliche _processing_warnings- und _validation_warnings-Einträge mit SOURCE_CONTEXT_*-Regel-IDs enthalten, wenn Quellenbelege fehlten, zweifelhaft oder abgeschnitten waren; behandeln Sie diese als Prüfsignale, nicht als Fehler. Bei failed enthält die Antwort ein error-Feld mit dem Fehlergrund. Anfrage: keins (GET); task_id (path, erforderlich) — UUID, die vom Convert-Endpoint zurückgegeben wurde; include_validation_report_html (query, optional) — true oder false (Standard false); bei true enthält die Statusantwort den bereinigten HTML-Validierungsbericht des aktuellen strikten Artefakts, sofern verfügbar. Antwort: 200 OK.

Laden Sie die erzeugte Datei herunter (XML oder PDF). Die Ergebnissyntax entspricht dem ursprünglichen Task-Format: XRECHNUNG/EN16931/UBL liefern UBL-XML, CII/ZUGFERD liefern CII-XML, und ZUGFERD + download=pdf liefert ein hybrides PDF/A-3. Bei anderen Formaten kann download=pdf ein gerendertes PDF liefern; bei einem abgeschlossenen Task ist download=xml das erwartbar verfügbare Artefakt, aber kein garantiertes. Wiederholte Downloads können aus zwischengespeicherten Artefakten bedient werden, wenn der Validierungsnachweis noch aktuell ist. Während der Verarbeitung liefert der Endpunkt ein 202 mit dem Standard-Fehlerumschlag ({"code":"TASK_NOT_READY","message":"Strict conversion is still processing. No validated artifact is available yet.","correlation_id":"<uuid>"}); blockierende Validierungsfehler liefern 422 VALIDATION_FAILED, wiederholbare Abhängigkeitslücken 503, endgültige Konvertierungsfehler 500 TASK_FAILED mit dem Grund in details.code und Artefakt-Invariantfehler 500 INTERNAL_ARTIFACT_INVARIANT_FAILED — jeweils ohne Dateiinhalt. Erfolgreiche Downloads enthalten X-Correlation-ID, Content-Disposition, Cache-Control: no-store, X-Artifact-Sha256, X-Validation-Proof-Id, X-Artifact-Proof-Id, X-Artifact-State, X-Validation-State, X-Proof-Status und X-Validator-Bundle-Id; X-Task-Id wird an diesem Endpunkt nicht gesetzt. Rate-Limit 10/min und etwa 134/hour. Anfrage: keins (GET); task_id (path, erforderlich) — UUID, die vom Convert-Endpoint zurückgegeben wurde; download (query, erforderlich) — xml oder pdf. Antwort: 200 OK.

Laden Sie den Bericht zum aktuell validierten Ergebnisartefakt herunter. Der Bericht ist erst verfügbar, nachdem die strikte Konvertierung ein Artefakt mit aktuellem Nachweis gespeichert hat; sonst liefert der Endpunkt 202 oder 404. Antwort-Header identifizieren Artefakt und Berichtsnachweis. X-Artifact-Sha256 bezeichnet das Ergebnisartefakt, nicht die Berichtsdatei. Rate-Limit: 10/min und 120/Stunde. Anfrage: keins (GET); task_id (Pfad, erforderlich) — UUID, die ein Konvertierungsendpunkt zurückgibt; download (Abfrage, optional) — html oder xml. Antwort: 200 OK.

seller_master_data behandelt electronic_address und electronic_address_scheme jetzt als ein optionales Feldpaar. Senden Sie beide Felder oder lassen Sie beide weg; ein unvollständiges Paar liefert 400 INVALID_SELLER_MASTER_DATA.

Korrektur der Preisdokumentation: 1.000 Prepaid-Credits kosten 400 EUR (0,40 EUR je Credit). Die Pakete mit 100, 200 und 500 Credits kosten weiterhin 50, 100 und 250 EUR. Die tatsächlich berechneten Preise und bestehende Käufe bleiben unverändert.

Die Dokumentkonvertierung ignoriert eingebettete Rechnungs-XML jetzt standardmäßig. Setzen Sie use_embedded_xml=true nur, wenn die Integration die eingebettete XML ausdrücklich als primäre Extraktionsquelle akzeptiert. Der E-Mail-Import ignoriert eingebettete Rechnungs-XML immer. Eine Änderung von use_embedded_xml ändert den Idempotenz-Hash des Requests; verwenden Sie bei einer Änderung dieser Option einen neuen Idempotency-Key.

Wenn Verkäufer-Stammdaten ein Feld füllen, bleiben übrige Extraktions-Flags dazu sichtbar, blockieren aber nicht mehr den strengen E-Mail-Import oder die External API. Käufer, Positionen, Steuer, Lieferung, Fälligkeit, Skonto, Verwendungszweck, ungefüllte Profilfelder und ungültige Profilwerte bleiben blockierend.

Enterprise wurde per Direktkauf für 50 EUR/Monat oder 420 EUR/Jahr verfügbar. Enterprise enthält 100 gemeinsame E-Mail/API-Konvertierungen pro Monat; weitere Konvertierungen nutzen Prepaid-Credits zu je 0,40–0,50 EUR. API-Schlüssel brauchen keine manuelle Freigabe mehr.

Aktuellen Fehlerkatalog und code-spezifische Retry-Regeln veröffentlicht. Ein 500-Status ist nicht automatisch wiederholbar; code, details.code und details.retryable prüfen. Beide details-Formen für 402 INSUFFICIENT_API_CREDITS und die unterschiedlichen 409-Idempotenzpfade dokumentiert. Nachweis-Header des Validierungsberichts, 24-Stunden-Aufbewahrung, Task-Timeouts und endpunktspezifische Rate-Limits veröffentlicht. Geschlossene Format/Profil-Tabelle veröffentlicht und Hinweise zu Download, METHOD_NOT_ALLOWED und PROFILE_MISMATCH korrigiert.

API-Konvertierung lehnt eine bestätigte Quelle mit mehreren Rechnungen jetzt endgültig mit MULTIPLE_INVOICES_IN_DOCUMENT ab. Bestätigte Mehrfachrechnungen aufteilen. Ein unsicheres Signal liefert stattdessen 422 VALIDATION_FAILED zur Prüfung.

Aktivierte Verkäufer-Stammdaten ersetzen jetzt passende extrahierte Verkäufer- oder Zahlungswerte. Fehlende Profilfelder lassen extrahierte Werte unverändert; Abweichungen bleiben nicht blockierende Prüfwarnungen.

Durch 2026-07-26 ersetzt: Verkäufer-Stammdaten ersetzen jetzt passende extrahierte Werte, statt nur fehlende Werte zu ergänzen.

Dokumentations-Backfill; keine Änderung des Laufzeitverhaltens. Der Fehlerkatalog dokumentiert jetzt zuvor nicht dokumentierte Laufzeit-Fehlercodes, darunter API_CREDIT_SERVICE_UNAVAILABLE, TASK_NOT_FOUND, INVALID_CLIENT_METADATA, INVALID_SELLER_MASTER_DATA, PROFILE_MISMATCH, ZUGFERD_SOURCE_PDF_REQUIRED, VALIDATION_REPORT_NOT_FOUND, VALIDATION_REPORT_FAILED, INVALID_QUERY_PARAMETER und METHOD_NOT_ALLOWED. Clients, die Fehlerantworten über das maschinenlesbare code-Feld auswerten, benötigen keine Änderungen; Clients mit fester Codeliste sollten die neu dokumentierten Werte ergänzen. Changelog-Daten korrigiert: Die Unterstützung für DOCX/TXT-Quellen erschien am 2026-06-30, nicht am 2026-07-06.

Payloads abgeschlossener Tasks können zusätzliche _processing_warnings- und _validation_warnings-Einträge mit SOURCE_CONTEXT_*-Regel-IDs enthalten, wenn Quellenbelege vor der Extraktion fehlten, zweifelhaft oder abgeschnitten waren. Behandeln Sie SOURCE_CONTEXT_*-Einträge als Prüfsignale für kundenseitige Ausnahmebehandlung; strikte Artefakt-Downloads bleiben durch Validierungsnachweis und Artefaktprüfungen abgesichert.

Strikte ZUGFeRD-Voraussetzungsfehler (fehlende Pflichtfelder für die Hybrid-Erzeugung) schlagen jetzt als 422 VALIDATION_FAILED mit den blockierenden Regel-IDs fehl statt als wiederholbares 503; leiten Sie diese in einen Datenkorrektur-Ablauf, nicht in eine Retry-Schleife. Für XML-only-Formate (XRECHNUNG, EN16931, UBL, CII) ist die PDF-Darstellung jetzt ein Best-Effort-Komfortartefakt: download=xml bleibt bei abgeschlossenen Tasks maßgeblich und verfügbar, während download=pdf nicht verfügbar sein kann, wenn die Darstellung nach der XML-Ausstellung fehlschlug. Konvertierungen mit ungelösten blockierenden Quellkonflikten schlagen jetzt als 422 VALIDATION_FAILED mit blocking_source_conflict-Einträgen fehl, statt ein Artefakt auszustellen.

POST /api/v1/invoices:convert akzeptiert im file-Feld jetzt PDF-, DOCX- und TXT-Rechnungsquelldokumente. Alte DOC-, RTF-, Bild- und andere nicht unterstützte Quelldateien werden vor Start der Konvertierung abgelehnt. ZUGFeRD/Factur-X-Hybrid-PDF-Downloads erfordern weiterhin einen PDF-Quellupload; für DOCX/TXT-Quellkonvertierungen XML-Downloads verwenden. Optionales include_validation_report_html=true auf GET /api/v1/tasks/{task_id} ergänzt, um den bereinigten HTML-Validierungsbericht bei Verfügbarkeit inline zu liefern. Konvertierungsuploads akzeptieren jetzt an beiden Endpunkten optionale use_seller_master_data- und seller_master_data-Felder, damit freigegebene Tenants gespeicherte oder request-bezogene Verkäufer-Stammdaten aktivieren können.

GET /api/v1/tasks/{task_id}/validation-report?download=html|xml ergänzt, um den Validierungsbericht zum aktuellen strikten Ergebnisartefakt-Nachweis abzurufen. Antworten des Validierungsberichts enthalten Task-ID, Artefakt-SHA-256, Validierungsnachweis-ID, Berichtsnachweis-ID, Berichts-Content-Type und Korrelations-ID-Header.

Gesendete Rechnungsdaten sind jetzt die Datenquelle für hybride ZUGFeRD-Ausgaben; deterministische Bereinigung und Steuernormalisierung bleiben aktiv. Tasks schlagen bei ausbleibendem Fortschritt oder am 15-Minuten-Maximum fehl, nicht nach einem festen Fünf-Minuten-Timeout.

Fehler beim Speichern der Nutzungsdaten blockieren keine fertige validierte Antwort und berechnen keinen zusätzlichen Credit; fehlgeschlagene Ereignisse werden abgeglichen.

External API-Zugang ist jetzt als freigabepflichtiger Zugang dokumentiert, nicht als unbeschränkte Key-Erstellung. Klargestellt, dass kein formales SLA, keine Service Credits und keine Vertragsstrafen gelten, sofern nicht in einem Order Form vereinbart. format ist jetzt an beiden Konvertierungsendpunkten erforderlich; fehlende Werte liefern 400 FORMAT_REQUIRED und nicht unterstützte Werte 422 INVALID_FORMAT. download ist jetzt bei Task-Ergebnisrequests erforderlich; fehlende Werte liefern 400 DOWNLOAD_FORMAT_REQUIRED und nicht unterstützte Werte 400 INVALID_DOWNLOAD_FORMAT. Konvertierungsuploads akzeptieren jetzt client_reference/external_invoice_id und source_system für kundenseitigen Abgleich. Angenommene Konvertierungen und Task-Statusantworten enthalten jetzt status_url, primary_result_format, primary_result_url sowie gesendete Abgleichsfelder.

Strukturierte Konvertierung akzeptiert jetzt alle öffentlichen Ausgabeformate: XRECHNUNG, ZUGFeRD, EN16931, UBL und CII. Strukturierte Konvertierung akzeptiert jetzt wiederholbare data_file-Teile sowie die Aliase data_files und data_files[] für getrennte ERP-Exporte. Strukturierte Multi-Datei-Bundles müssen genau eine Rechnung beschreiben und schlagen bei widersprüchlichen oder fehlenden Bundle-Rechnungs-IDs früh fehl. Klargestellt, dass mehrere Rechnungsdokumente als separate Konvertierungs-Tasks mit jeweils eigenem Idempotency-Key eingereicht werden sollten.

POST /api/v1/invoices:convert-structured für Träger-PDF plus CSV/JSON/XML/XLSX/TXT-Konvertierung aus strukturierten Daten über unterstützte Ausgabeformate ergänzt. Dokumentiert, dass strukturierte Daten an diesem Endpunkt die einzige semantische Quelle sind; das PDF wird für die Hybrid-Einbettung verwendet. OpenAPI- und Postman-Artefakte für strukturierte Konvertierung aktualisiert.

Strikte XML- und Hybrid-PDF-Artefakte erhielten interne Paritätsdaten; result_artifacts zeigt Bereitschaft und Validierungsstatus. Die dokumentierte Produktions-Basis-URL wurde auf https://www.invoice-converter.com/api/v1 geändert.

GET /api/v1/tasks/{task_id}/result dient nur noch zum Abruf; der Aufruf erzeugt, repariert oder validiert keine Dateien. Strikte Tasks enden erst nach Speicherung eines validierten Artefakts; ein fehlender aktueller Nachweis führt zum geschlossenen Fehler. External-API-Konvertierung ist fest auf strikte Ausgabe eingestellt, ohne Entwurf oder Warnungsübersteuerung. Der Task-Status erhielt result_artifacts-Diagnosen und dokumentierte delivery_channel-Werte.

Prepaid-API-Credits für Nicht-Enterprise-Mandanten ergänzt. 402 INSUFFICIENT_API_CREDITS für freigegebene Mandanten ohne Enterprise-Abrechnung per Order Form oder Prepaid-Credits dokumentiert. Bestätigt, dass idempotente Replays keine zusätzlichen API-Credits verbrauchen. Klargestellt, dass External API V1 das Modellrouting serverseitig steuert, während Profil- und Lieferkontext vom Aufrufer gesetzt werden.

Der Task-Status erhielt Bereitschaftsdiagnosen für XML/PDF-Artefakte. Strikte Ergebnisdownloads liefern Dateien erst nach serverseitigen Artefaktprüfungen.

Erfolgreiche Ergebnisdownloads erhielten einen serverseitigen Validierungsnachweis für das zurückgegebene Artefakt. Fehlende Validierungs- oder Nachweisabhängigkeiten liefern 503 AUTHORITATIVE_VALIDATION_UNAVAILABLE. Zwischengespeicherte Downloads werden nur mit weiterhin aktuellem gespeichertem Validierungsnachweis wiederverwendet.

Task-result-Downloads für CII- und ZUGFERD-Ausgaben formatgetreu gemacht. Wiederverwendung zwischengespeicherter Ergebnisartefakte für wiederholte XML-/PDF-Downloads desselben Tasks ergänzt. Polling-Kontingente an endpoint-bezogene gewichtete Rate-Limit-Buckets angeglichen.

Klarere und konsistente API-Fehlerantworten über alle Endpunkte ergänzt. Convert-Optionen erweitert und XML-/PDF-Downloadverhalten für Task-Ergebnisse dokumentiert. Retry-Sicherheit mit strengeren Idempotenzanforderungen und Validierung verbessert. OpenAPI-/Postman-Artefakte an das aktuelle API-Verhalten angepasst.