Cada release de API. Cada breaking change. Registrado.
Fabrixa publica actualizaciones de API y de la plataforma con una periodicidad predecible. Cada lanzamiento se publica aquí primero: qué ha cambiado, qué novedades hay, qué elementos quedan obsoletos y cuándo dejarán de funcionar. Consulta esta página antes de actualizar.
Lo que ha cambiado en las últimas semanas.
De más reciente a más antigua. Cada entrada está fechada, etiquetada según el semver y clasificada en las categorías estándar: Añadido / Modificado / Obsoleto / Eliminado / Corregido / Seguridad.
- CHANGEDÚltima hora: La ruta base se ha trasladado a
/v2/integration. Los endpoints de la versión 1 quedan obsoletos; las integraciones existentes de la versión 1 seguirán funcionando durante el periodo de transición; consulta el guía de integración paso a paso. - CHANGEDÚltima hora: La autenticación se realiza ahora mediante dos encabezados: —
Authorization: Bearer(Token de acceso de la aplicación) másX-Application-Key. Ya no se acepta la autenticación v1 con un solo token. - ADDEDFabrixa Studio — personalizador de productos de marca blanca que se puede integrar: intégrelo mediante un iframe, adjunte un diseño guardado a una línea de pedido con
cart_item_key, y obtener una vista previa de/v2/studio/customizations/{key}/preview. - CHANGEDRespuesta estándar sobre los endpoints de la lista:
links/meta/datacon enlaces de paginación. - CHANGEDWebhooks agrupados en
order.createdyorder.updated, firmado conx-webhook-signature(HMAC-SHA256) y etiquetado conx-webhook-topic. - CHANGEDLímite de solicitudes fijado en 30 por aplicación y minuto, mostrado a través de
X-RateLimit-LimityX-RateLimit-Remainingencabezados.
- ADDED
GET /v1/products/:id/pricing- previsión de precios unitarios por volumen por SKU. - CHANGEDLel payload del webhook de pedido incluye ahora un
production_hubcampo (PT, ES o NL). Compatible con versiones anteriores.
- ADDEDProceso de personalización en cinco modalidades para ropa de cama, mantelería y accesorios: texto, nombre, números, imágenes y campos de datos dinámicos.
- ADDED
order.failedEvento de webhook con motivos de error estructurados (rechazo del diseño, falta de existencias de la tela y similares). - FIXEDCaso extremo de paginación en
GET /v1/ordersal filtrar por estado a través de los límites de página.
- ADDEDCojín para exterior, mantel y puf SKUs para uso en exteriores, fabricados en material sintético. Disponible a través de
GET /v1/products?category=home-living. - DEPRECATED
artwork_base64campo del cuerpo de la orden: introduce en su lugar la URL del archivo de origen. Fecha prevista de eliminación: v1.20.0 (28 de marzo de 2027). - SECURITYSe ha reforzado el esquema de firma de los webhooks. La variante HMAC anterior seguirá siendo válida hasta la versión 1.18.0; a partir de ahora se aplicará automáticamente el nuevo método de firma.
- ADDEDCategoría de ropa de cama (fundas nórdicas para 1 persona / 2 personas / camas gemelas, colchas, sábanas bajeras) en la plataforma española.
- ADDEDServilleta de sublimación SKUs en el centro de distribución de los Países Bajos con un plazo de entrega de 2 a 3 días laborables.
- CHANGEDEl endpoint de pedido ahora acepta
recipient.countrycomo ISO 3166-1 alfa-2; se ha eliminado la alternativa alfa-3.
Las versiones anteriores están disponibles si las necesita — escriba a developers@fabrixa.com.
SemVer, con cambios que rompen la compatibilidad de forma conservadora.
Cambios de última hora en los endpoints existentes
Es poco habitual. Se anuncia con 12 meses de antelación al lanzamiento. La versión principal anterior sigue recibiendo soporte durante 12 meses tras el lanzamiento de la nueva versión principal. No eliminamos versiones principales a la ligera.
Nuevos endpoints, campos y comportamientos
Novedades compatibles con versiones anteriores. El código existente sigue funcionando sin necesidad de modificaciones. La mayoría de las actualizaciones son menores y se publican cada dos o cuatro semanas, aproximadamente.
Corrección de errores, rendimiento, seguridad
Sin ningún tipo de incompatibilidad. Se implementa de forma continua sin previo aviso y se registra en el registro de cambios tras la implementación.
12 meses desde la notificación de depreciación hasta la eliminación.
Cuando marcamos como obsoleto un campo, un endpoint o un comportamiento, la entrada del Changelog lo etiqueta como DEPRECATED y enumera la versión y la fecha previstas para su retirada. La funcionalidad obsoleta seguirá funcionando durante al menos 12 meses tras el aviso.
Enviamos tres notificaciones de recordatorio —seis meses, tres meses y un mes antes de la eliminación— a la dirección de correo electrónico que figura en el registro de la clave API.
Los endpoints obsoletos también devuelven un X-Fabrixa-Deprecation encabezado de respuesta que indique la ruta de migración, para que quede reflejado en sus registros.
Cómo llevar un control de los cambios.
No hay que conectar ningún canal de datos: esta página es la fuente de información de referencia. A continuación le explicamos cómo mantenerte al día de todo lo que pueda afectar a su integración.
Echa un vistazo aquí primero
Todas las versiones se publican en esta página, con la más reciente en primer lugar. Añádala a sus favoritos y échele un vistazo antes de actualizar una dependencia o lanzar una nueva integración.
Una pista despejada
Cuando algo está a punto de dejar de estar disponible, se etiqueta su entrada DEPRECATED con la versión y la fecha previstas para la retirada: aviso previo, en su contexto.
Pregunta por un cambio
¿Estás planificando un cambio o una migración a una versión principal? Un ingeniero de soluciones puedo explicarte los plazos y las repercusiones de su integración.
Cuándo pueden enviarse los cambios de última hora.
Los lanzamientos de versiones principales se programan en franjas temporales específicas para que no coincidan con las fechas de los drops de los clientes ni con las temporadas altas de ventas al por menor. La mayoría de los años no se producen lanzamientos de versiones principales.
Febrero y septiembre son los periodos habituales para introducir cambios radicales, ya que se sitúan tras la temporada alta de ventas al por menor y antes del pico de demanda, lo que da tiempo a los integradores para realizar la migración antes de su próximo gran lanzamiento.
Noviembre-diciembre (temporada de compras navideñas), marzo-mayo (Fespa y lanzamientos de primavera) y las dos semanas previas a eventos destacados del sector son periodos en los que no se introducen cambios que afecten al funcionamiento. Se siguen publicando parches, pero no se realizan cambios de comportamiento, ni menores ni mayores.
La ingeniería de soluciones guía a los integradores en los cambios de versión principal.
Para los cambios de versión principales, publicamos una guía de migración junto con las notas de la versión. El equipo de ingeniería de soluciones también ofrece sesiones gratuitas de 30 minutos sobre migración para cualquier socio de integración activo durante el periodo de obsolescencia; puede reservar su plaza a través de la página «contact-engineer». Los clientes empresariales disponen de asistencia dedicada para la migración incluida en su MSA, además de acceso anticipado a la nueva versión principal a través de un canal de ventas de pruebe 90 días antes de su disponibilidad pública.
Consulta esto antes de actualizar.
Todas las actualizaciones se publican aquí primero: qué ha cambiado y cuándo deja de funcionar. Las funciones en desuso cuentan con un plazo de transición, y los cambios de versión principal incluyen asistencia para la migración.