Ogni release API. Ogni breaking change. Registrato.
Fabrixa rilascia le versioni API e gli aggiornamenti della piattaforma con cadenza regolare. Ogni versione viene pubblicata qui per prima: cosa è cambiato, quali sono le novità, quali funzionalità sono in fase di dismissione e quando smetteranno effettivamente di funzionare. Controlla qui prima di effettuare l'aggiornamento.
Cosa è cambiato nelle ultime settimane.
Le voci più recenti per prime. Ogni voce è datata, contrassegnata secondo lo schema SemVer e suddivisa nelle categorie standard: Added / Changed / Deprecated / Removed / Fixed / Security.
- CHANGEDUltime notizie: il percorso di base è stato spostato in
/v2/integration. Gli endpoint v1 sono stati sostituiti — le integrazioni v1 esistenti continueranno a funzionare per tutto il periodo di obsolescenza; consultare la Guida all'integrazione. - CHANGEDUltime notizie: L'autenticazione ora prevede due intestazioni —
Authorization: Bearer(Application Access Token) piùX-Application-Key. L'autenticazione v1 con token singolo non è più accettata. - ADDEDFabrixa Studio — configuratore di prodotto white label integrabile: da incorporare tramite iframe, allegare un progetto salvato a una riga dell'ordine con
cart_item_key, e visualizzare un'anteprima da/v2/studio/customizations/{key}/preview. - CHANGEDRisposta standard relativa agli endpoint della lista:
links/meta/datacon i link di paginazione. - CHANGEDWebhook raggruppati in
order.createdeorder.updated, firmato conx-webhook-signature(HMAC-SHA256) e contrassegnato conx-webhook-topic. - CHANGEDRate limit fissato a 30 richieste per applicazione al minuto, visualizzato tramite
X-RateLimit-LimiteX-RateLimit-Remainingintestazioni.
- ADDED
GET /v1/products/:id/pricing- anteprima dei prezzi unitari tra i livelli di volume per SKU. - CHANGEDIl payload del webhook "Order" ora include un
production_hubcampo (PT, ES o NL). Compatibile con le versioni precedenti.
- ADDEDProcesso di personalizzazione in cinque modalità per biancheria da letto, da tavola e accessori: testo, nomi, numeri, immagini e campi dati dinamici.
- ADDED
order.failedevento webhook con motivi di errore strutturati (rifiuto della grafica, tessuto esaurito e simili). - FIXEDCaso limite di paginazione su
GET /v1/ordersquando si filtra per stato attraverso i confini della pagina.
- ADDEDSKU di cuscini da esterno, tovaglie e pouf per uso esterno in materiale sintetico. Disponibile tramite
GET /v1/products?category=home-living. - DEPRECATED
artwork_base64campo nel corpo dell'ordine — fornire invece l'URL del file sorgente. Data di rimozione prevista: v1.20.0 (28/03/2027). - SECURITYRafforzato lo schema di firma dei webhook. La precedente variante HMAC rimane valida fino alla versione 1.18.0; d'ora in poi verrà applicato automaticamente il nuovo schema di firma.
- ADDEDCategoria "Biancheria da letto" (copripiumini 1P / 2P / Lits Jumeaux, copriletti, lenzuola con angoli) sull'hub spagnolo.
- ADDEDSKU di tovaglioli a sublimazione disponibili sull'hub olandese con uno SLA di 2–3 giorni lavorativi.
- CHANGEDL'endpoint dell'ordine ora accetta
recipient.countrycome ISO 3166-1 alfa-2; il fallback alfa-3 è stato rimosso.
Per le versioni precedenti, inviare un’e-mail a developers@fabrixa.com.
SemVer, con breaking change applicati con cautela.
Breaking change agli endpoint esistenti
Raro. Annunciato 12 mesi prima del rilascio. La versione principale precedente continua a essere supportata per 12 mesi dopo l’uscita di quella nuova. Non passiamo da una versione principale all’altra con leggerezza.
Nuovi endpoint, campi, comportamenti
Aggiunte retrocompatibili. Il codice esistente continua a funzionare senza modifiche. La maggior parte delle versioni è minore, con una cadenza di circa due-quattro settimane.
Correzioni di bug, prestazioni, sicurezza
Modifiche che non comportano alcun problema di compatibilità. Implementate in modo continuativo senza preavviso e registrate nel changelog dopo l'implementazione.
12 mesi dall'avviso di deprecazione alla rimozione.
Quando rendiamo obsoleto un campo, un endpoint o un comportamento, la voce nel changelog lo contrassegna come DEPRECATED e indica la versione e la data previste per la rimozione. La funzionalità deprecata continuerà a funzionare per almeno 12 mesi dopo la notifica.
Inviamo tre notifiche di promemoria — sei mesi, tre mesi e un mese prima della rimozione — all'indirizzo e-mail registrato per la chiave API.
Anche gli endpoint obsoleti restituiscono un X-Fabrixa-Deprecation intestazione di risposta che indica il percorso di migrazione, in modo che sia visibile nei log.
Come tenere traccia delle modifiche.
Non servono feed da configurare: questa pagina è la fonte di riferimento. Ecco come rimanere sempre aggiornati su tutto ciò che riguarda la vostra integrazione.
Controlla prima qui
In questa pagina vengono pubblicati tutti gli aggiornamenti, con il più recente in cima alla lista. Aggiungila ai preferiti e dai un'occhiata prima di aggiornare una dipendenza o rilasciare una nuova integrazione.
Una pista libera
Quando un elemento sta per essere ritirato, la relativa voce viene contrassegnata DEPRECATED con l'indicazione della versione e della data previste per la rimozione — preavviso, nel contesto.
Chiedi informazioni su una modifica
State pianificando un cambiamento o una migrazione a una versione principale? Un ingegnere delle soluzioni posso illustrarLe le tempistiche e le ripercussioni della Sua integrazione.
Quando i breaking change possono essere rilasciati.
Il rilascio delle versioni principali viene programmato in finestre specifiche, in modo da non coincidere con le date dei drop dei clienti o con i periodi di picco delle vendite al dettaglio. Nella maggior parte degli anni non vengono rilasciate versioni principali.
Febbraio e settembre sono le finestre tipiche per i breaking change: entrambe seguono l'alta stagione retail e precedono il picco delle vendite, il che offre agli integratori il tempo necessario per effettuare la migrazione prima del loro prossimo grande drop.
Novembre-dicembre (vendite natalizie), marzo-maggio (Fespa e i drop di primavera) e le due settimane precedenti gli eventi di settore più importanti sono finestre senza breaking change. Il rilascio di patch prosegue, ma non vengono introdotte modifiche comportamentali, né minori né maggiori.
Il team di Solutions Engineering aiuta gli integratori a superare i passaggi di versione più impegnativi.
Per i passaggi a versioni principali, pubblichiamo una guida alla migrazione insieme alle note di rilascio. Il team di Solutions Engineering organizza inoltre sessioni gratuite di 30 minuti dedicate alla migrazione per tutti i partner di integrazione attivi durante il periodo di deprecazione: è possibile prenotare tramite la pagina “Contatta un ingegnere”. I clienti Enterprise ricevono supporto dedicato alla migrazione nell’ambito del proprio MSA, oltre all’accesso anticipato alla nuova versione principale su un canale di vendita di staging 90 giorni prima della disponibilità al pubblico.
Controlla qui prima di eseguire l'aggiornamento.
Ogni nuova versione viene pubblicata qui per prima: cosa è cambiato e quando potrebbero verificarsi dei malfunzionamenti. Le funzionalità deprecate vengono accompagnate da un periodo di transizione, mentre i passaggi a versioni principali sono supportati da procedure di migrazione.