Jedes API-Release. Jeder Breaking Change. Dokumentiert.
Fabrixa veröffentlicht API- und Plattform-Updates in regelmäßigen Abständen. Jede neue Version wird zuerst hier veröffentlicht – mit Informationen dazu, was sich geändert hat, was neu ist, was nicht mehr unterstützt wird und wann es tatsächlich zu Fehlern kommt. Schauen Sie hier vorbei, bevor Sie ein Upgrade durchführen.
Was sich in den letzten Wochen geändert hat.
Neueste Einträge zuerst. Jeder Eintrag ist mit Datum und Semver-Tag versehen und in die Standardkategorien unterteilt: Hinzugefügt / Geändert / Veraltet / Entfernt / Behoben / Sicherheit.
- CHANGEDBreaking: Der Basispfad wurde verschoben nach
/v2/integration. Die v1-Endpoints werden abgelöst – bestehende v1-Integrationen funktionieren während der Auslaufphase weiterhin; siehe die Integrationsleitfaden,. - CHANGEDBreaking: Die Authentifizierung erfolgt nun über zwei Header —
Authorization: Bearer(Application Access Token) sowieX-Application-Key. Die Single-Token-Authentifizierung der Version 1 wird nicht mehr akzeptiert. - ADDEDFabrixa Studio — einbettbarer White-Label-Produktkonfigurator: Einbettung über iframe, Hinzufügen eines gespeicherten Designs zu einer Bestellzeile mit
cart_item_keyund Abrufen einer Vorschau von/v2/studio/customizations/{key}/preview. - CHANGEDStandard-Antwortumschlag für List-Endpoints:
links/meta/datamit Paginierungslinks. - CHANGEDWebhooks zusammengefasst unter
order.createdundorder.updated, signiert mitx-webhook-signature(HMAC-SHA256) und versehen mit dem Tagx-webhook-topic. - CHANGEDDas Rate Limit liegt bei 30 Anfragen pro Anwendung und Minute und wird über die Header
X-RateLimit-LimitundX-RateLimit-Remainingausgegeben.
- ADDED
GET /v1/products/:id/pricing- Vorschau der Stückpreise für die verschiedenen Volumenstufen pro SKU. - CHANGEDDie Webhook-Payload für Bestellungen enthalten nun eine
production_hubFeld (PT, ES oder NL). Abwärtskompatibel.
- ADDEDPersonalisierungs-Pipeline mit fünf Modi für Bettwäsche, Tischwäsche und Zubehör: Text, Namen, Zahlen, Bilder und dynamische Datenfelder.
- ADDED
order.failedWebhook-Event mit strukturierten Fehlergründen (Ablehnung des Motivs, Stoff nicht vorrätig und Ähnliches). - FIXEDRandfall bei der Paginierung von
GET /v1/ordersbeim Filtern nach Status über Seitengrenzen hinweg.
- ADDEDSKUs für Outdoor-Kissen, Tischdecken und Sitzsäcke für den Einsatz im Freien aus synthetischem Material. Erhältlich über
GET /v1/products?category=home-living. - DEPRECATED
artwork_base64Feld im Order-Body – geben Sie stattdessen die URL der Quelldatei an. Geplante Entfernung: v1.20.0 (28.03.2027). - SECURITYDas Signaturverfahren für Webhooks wurde sicherer gestaltet. Die bisherige HMAC-Variante bleibt bis einschließlich Version 1.18.0 gültig; ab sofort wird automatisch das neue Signaturverfahren angewendet.
- ADDEDKategorie „Bettwäsche“ (Bettbezüge 1P / 2P / Lits Jumeaux, Tagesdecken, Spannbettlaken) im spanischen Hub.
- ADDEDSKUs für Sublimations-Servietten im niederländischen Hub mit einem SLA von 2–3 Werktagen.
- CHANGEDDer Endpoint der Bestellung akzeptiert jetzt
recipient.countryals ISO 3166-1 Alpha-2; die Alpha-3-Ausweichbezeichnung wurde entfernt.
Ältere Versionen erhalten Sie per E-Mail an developers@fabrixa.com.
SemVer mit konservativen Breaking Changes.
Breaking Changes an bestehenden Endpoints
Selten. Wird 12 Monate vor der Veröffentlichung angekündigt. Die alte Hauptversion wird noch 12 Monate nach der Veröffentlichung der neuen Hauptversion unterstützt. Wir führen keine Hauptversionswechsel leichtfertig durch.
Neue Endpoints, Felder, Verhaltensweisen
Abwärtskompatible Erweiterungen. Bestehender Code funktioniert weiterhin ohne Änderungen. Die meisten Veröffentlichungen sind kleinere Updates, die in Abständen von etwa zwei bis vier Wochen erscheinen.
Fehlerbehebungen, Leistung, Sicherheit
Strikt nicht-breaking. Wird fortlaufend ohne vorherige Ankündigung bereitgestellt und nach der Bereitstellung im Changelog vermerkt.
12 Monate von der Deprecation-Ankündigung bis zur Entfernung.
Wenn wir ein Feld, einen Endpoint oder ein Verhalten als veraltet kennzeichnen, wird der Changelog-Eintrag mit DEPRECATED markiert und nennt die Version sowie das Datum, zu denen die Funktion entfernt werden soll. Die veraltete Funktion bleibt nach der Ankündigung noch mindestens 12 Monate lang funktionsfähig.
Wir versenden drei Erinnerungsbenachrichtigungen – sechs Monate, drei Monate und einen Monat vor der Löschung – an die für den API-Schlüssel hinterlegte E-Mail-Adresse.
Veraltete Endpoints geben ebenfalls einen X-Fabrixa-Deprecation Antwort-Header, der auf den Migrationspfad verweist, sodass er in Ihren Protokollen sichtbar ist.
So behalten Sie den Überblick über Änderungen.
Keine Feeds, die Sie einbinden müssen – diese Seite ist die verlässliche Informationsquelle. So bleiben Sie über alles auf dem Laufenden, was Ihre Integration betrifft.
Schauen Sie zuerst hier nach
Jede neue Version wird auf dieser Seite veröffentlicht, wobei die aktuellste ganz oben steht. Setzen Sie ein Lesezeichen und sehen Sie sich die Seite an, bevor Sie eine Abhängigkeit aktualisieren oder eine neue Integration bereitstellen.
Ein klarer Vorlauf
Wenn etwas ausläuft, wird der entsprechende Eintrag mit dem Tag DEPRECATED versehen, mit Angabe der Zielversion und des Datums für die Entfernung – Vorankündigung im Kontext.
Fragen Sie nach einer Änderung
Planen Sie eine Umstellung oder eine Migration auf eine neue Hauptversion? Ein Solutions Engineer kann Ihnen den Zeitplan und die Auswirkungen Ihrer Integration erläutern.
Wenn Breaking Changes ausgeliefert werden können.
Die Veröffentlichung neuer Hauptversionen wird auf bestimmte Zeitfenster terminiert, damit sie nicht mit den Drop-Terminen der Kunden oder den Hauptverkaufszeiten im Einzelhandel zusammenfallen. In den meisten Jahren werden keine neuen Hauptversionen veröffentlicht.
Februar und September sind die typischen Breaking-Change-Fenster – beide liegen nach der Hauptverkaufssaison und vor der Hochsaison, was Integratoren Zeit gibt, die Umstellung vor ihrem nächsten großen Drop durchzuführen.
November–Dezember (Weihnachtsgeschäft), März–Mai (Fespa und Frühjahrs-Drops) sowie die zwei Wochen vor bekannten Branchenveranstaltungen sind Zeiträume, in denen keine Breaking Changes ausgeliefert werden. Es werden weiterhin Patches veröffentlicht, aber keine Minor- oder Major-Verhaltensänderungen.
Das Solutions Engineering begleitet Integratoren durch die Major-Versionssprünge.
Bei größeren Versionswechseln veröffentlichen wir neben den Versionshinweisen auch einen Migrationsleitfaden. Das Solutions Engineering bietet außerdem während des Auslaufzeitraums kostenlose 30-minütige Migrations-Sprechstunden für alle aktiven Integrationspartner an – eine Terminvereinbarung ist über die Seite „contact-engineer“ möglich. Unternehmenskunden erhalten im Rahmen ihres MSA dedizierten Migrationssupport sowie 90 Tage vor der öffentlichen Verfügbarkeit frühzeitigen Zugriff auf die neue Hauptversion über einen Staging-Vertriebskanal.
Bitte lesen Sie dies, bevor Sie das Upgrade durchführen.
Jede neue Version erscheint zuerst hier – was sich geändert hat und wann es zu Fehlern kommt. Auslaufende Funktionen werden mit einer Übergangsfrist angekündigt, und bei Versionssprüngen wird Unterstützung bei der Migration geboten.