API-Changelog

Entwicklerrelevante Änderungen an der REST-API /api/v1, neueste zuerst. Nicht brechende Ergänzungen (neue optionale Felder, neue Endpunkte) sind zur Kenntnisnahme aufgeführt; alles, was eine bestehende Antwort oder Anfrageform ändert, ist als Geändert gekennzeichnet.

2026-08-19 — Video-Assets

Neu. Die Asset-Bibliothek nimmt Videos an.

• POST /api/v1/assets/upload-url akzeptiert video/mp4, video/webm und video/quicktime mit einer Grenze von jeweils 100 MB. assetType erhält den Wert video, und AssetView.assetType kann ihn nun zurückgeben.
• assetType muss zu mimeType passen: ein video/*-Typ erfordert assetType: "video", ein image/*-Typ erfordert "image". Eine Abweichung ergibt 422. Dokumenttypen sind nicht eingeschränkt, ein PDF darf also weiterhin document, certificate oder other sein.
• Vorsignierte Upload-URLs für Video sind eine Stunde statt zehn Minuten gültig — 100 MB werden auf einer langsamen Verbindung nicht zuverlässig im kürzeren Fenster übertragen, und ein PUT, der das Fenster überdauert, lässt sich nicht bestätigen. Lesen Sie expiresAt, statt einen festen Wert anzunehmen.
• Video wird unverändert gespeichert und ausgeliefert. Es gibt keine Transkodierung und kein Vorschaubild: POST /api/v1/assets/{id}/renditions liefert weiterhin 422 für alles, was kein Bild ist, und beim Upload wird kein Thumbnail erzeugt.

2026-08-19 — Asset-Uploads werden gegen die gespeicherte Datei geprüft

Geändert. POST /api/v1/assets/confirm prüft jetzt das tatsächlich hochgeladene Objekt, nicht die Zahlen im Anfragekörper.

• sizeBytes im Confirm-Body wird ignoriert (und ist nicht mehr erforderlich; es wird weiterhin angenommen, damit bestehende Clients funktionieren). Gespeichert wird — und gegen Ihr Speicherkontingent zählt — die Größe, die der Objektspeicher meldet.
• Die Größengrenze wird gegen diese echte Größe durchgesetzt. Ein Confirm, dessen gespeichertes Objekt die Grenze überschreitet, ergibt 422, und das hochgeladene Objekt wird gelöscht — ein abgelehnter Upload hinterlässt keine Bytes mehr.
• Die ersten Bytes der Datei werden gegen den angegebenen MIME-Typ geprüft. Eine Datei, deren Inhalt nicht zur Angabe passt, wird mit 422 abgelehnt und gelöscht.
• Die PDF-Grenze liegt jetzt bei 50 MB (vorher 100 MB). Bilder bleiben bei 20 MB. Die Grenze greift beim Confirm, bereits gespeicherte Assets sind nicht betroffen.

Neu. POST /api/v1/assets/upload-url akzeptiert ein optionales sizeBytes. Geben Sie es an, und ein zu großer Upload wird abgelehnt, bevor Bytes übertragen werden, statt danach.

Geändert. Das branding.logoAssetId eines Markenportals wird nur berücksichtigt, wenn es auf ein Bild verweist. Ein Verweis auf ein PDF oder ein anderes Nicht-Bild lässt das Logo im veröffentlichten Portal nun weg, statt diese Datei zu veröffentlichen. Portallogos werden ohne Authentifizierung ausgeliefert — dies war also ein Weg, ein beliebiges Bibliotheks-Asset öffentlich zu machen.

2026-08-19 — transformRules aus der Kanal-API entfernt

Geändert. Das Feld transformRules entfällt in POST /api/v1/channels, PATCH /api/v1/channels/{id} und in jedem Kanal-Antwortkörper.

• Es wurde angenommen, gespeichert und zurückgegeben, aber die Syndizierungs-Engine hat es nie gelesen — die Transformation eines Kanals wird seit jeher ausschließlich von attributeMap gesteuert.
• Ein Senden ergibt jetzt 422: Kanal-Anfragekörper weisen unbekannte Felder zurück.
• Nichts geht verloren. Kanalweite Vorgaben und Konstanten lassen sich heute über die Transform-Operationen default und constant innerhalb von attributeMap ausdrücken.

Wenn Sie transformRules gesendet haben, entfernen Sie es aus der Anfrage. Wenn Sie es aus einer Antwort gelesen haben, haben Sie einen Wert gelesen, der immer {} war.

2026-08-13 — Suchfacetten, Veröffentlichungs-Verdikte und eine Verhaltensänderung bei der Syndizierung

Neu. GET /api/v1/search/products erhält Facettierung.

• facetBy — kommagetrennt, aus einer festen Positivliste: categoryId, categoryName, tags, status, qualityScore, supplierName. Alles andere ergibt 422. Bei Angabe enthält die Antwort zusätzlich facets: [{ "field": "...", "counts": [{ "value": "...", "count": 12 }] }].
• qualityBand — red | amber | green, filtert nach Datenvollständigkeit. qualityScore wird als diese drei Bänder facettiert (nicht als rohe 0–100-Werte), mit denselben Schwellen wie das Qualitäts-Dashboard: grün ≥ 90, gelb 60–89, rot unter 60.
• Produktdokumente erhalten optional qualityScore (die minimale Vollständigkeit über die aktivierten Sprachen des Lieferanten — fehlt, wenn das Produkt nie bewertet wurde) und supplierName, das der Einkäuferkatalog bisher als — darstellte, weil es deklariert, aber nie indexiert war.
• categoryName — ein neuer Filterparameter. Die Facette categoryName liefert Namen; erst dadurch wird sie nutzbar (categoryId erwartet weiterhin eine UUID).
• Facettenzahlen werden immer innerhalb Ihres eigenen Zugriffsbereichs berechnet und verraten daher nie die Existenz von Produkten, die Sie nicht lesen dürfen.

Neu. POST /api/v1/rendition-presets/{id}/reprocess → 202 { enqueued, hasMore }. Rendert die Renditions neu, die eine Preset-Änderung veraltet hat, in begrenzten Seiten — rufen Sie auf, bis hasMore false ist. PATCH /rendition-presets/{id} rendert bei einer Änderung von ops zusätzlich eine begrenzte Anzahl direkt neu und meldet dasselbe Objekt wie reprocess.

Neu. Einträge von GET /api/v1/channels/{id}/publications erhalten evaluation — das Verdikt je Veröffentlichung (missingRequired, transformErrors, warnings, localeFallbacks) — sowie externalRef, die vom Ziel vergebene Datensatz-ID. GET /api/v1/analytics/export akzeptiert from / to (das PDF stellte zuvor unabhängig vom Zeitraum einen einzelnen Punkt dar).

Geändert — die Syndizierung liefert wissentlich unvollständige Datensätze nicht mehr aus. Ein Produkt, dessen Attribute-Map-Transformation fehlschlägt oder dem ein als required markiertes Ziel fehlt, wird jetzt mit skipped und der Begründung in last_error und evaluation behandelt, statt mit weggelassenem Feld ausgeliefert zu werden. Wenn Sie sich auf Teillieferungen verlassen haben, kommen diese Produkte am Ziel nicht mehr an, bis Mapping oder Produktdaten korrigiert sind — und genau das ist der Zweck: das bisherige Verhalten schickte stillschweigend falsche Daten an Dritte.

Geändert — die locale eines Kanals wirkt jetzt tatsächlich. Lokalisierte name- und Attribut-Überschreibungen werden gegen die Sprache des Kanals aufgelöst (sie wurden zuvor vollständig ignoriert, jeder Kanal lieferte also die kanonischen Werte). Erwarten Sie, dass die erste Veröffentlichung nach diesem Release Produkte mit Übersetzungen erneut sendet, weil sich ihre Nutzlasten berechtigterweise ändern. evaluation.localeFallbacks listet Felder auf, die auf den kanonischen Wert zurückgefallen sind, weil die Sprache des Kanals keine Überschreibung hat.

Behoben. Zustellwiederholungen funktionieren jetzt (ein vorübergehender Zielfehler wird wiederholt, statt beim ersten Versuch als dauerhafter Fehler festgehalten zu werden), die Stapelzustellung berücksichtigt Ergebnisse je Datensatz, statt ein Verdikt auf den gesamten Satz anzuwenden, und eine erneute Zustellung an ein adressierbares Ziel aktualisiert den bestehenden Datensatz, statt ein Duplikat anzulegen.

2026-08-11 — total in Listen ist jetzt optional

Geändert. GET /api/v1/products und GET /api/v1/admin/orgs/{id}/products enthalten den Zähler total standardmäßig nicht mehr in der Antwort. Übergeben Sie ?withTotal=true, um ihn zu erhalten.

• Warum: Das COUNT(*) je Seite dominierte die Listenlatenz bei großen Datenmengen (es liest weit mehr als die Seite), und Cursor-Paginierung braucht nie einen Gesamtwert. Die Standard-Listenantwort ist jetzt nur noch { "items": [...], "nextCursor": "..." }.
• Migration: Wenn Sie total lesen, ergänzen Sie withTotal=true in der Query. Clients, die total ignoriert haben, müssen nichts ändern. Die Cursor-Paginierung (items + nextCursor) bleibt unverändert — siehe Paginierung.