Adobe Commerce Cloud Service: la release de octubre abre el back office a las integraciones

En Adobe Commerce as a Cloud Service las reglas del juego han cambiado: nada de módulos PHP a medida, nada de acceso directo a la base de datos. Lo que la API no sabe hacer, tu integración tampoco lo hará. Por eso la release del 7 de octubre de 2026 merece una lectura atenta: de una docena de novedades, casi todas amplían la superficie de integración — carritos, precios, B2B, correo. Esto es lo que se abre, y la restricción que lo acompaña.

El carrito se abre a los sistemas terceros

Tres novedades apuntan al mismo escenario: un sistema externo — un OMS, un call center, una herramienta de venta asistida — que necesita crear o modificar carritos sin molestar al cliente.

• El precio a medida. El atributo de extensión custom_price permite fijar un precio arbitrario en una línea de carrito a través de los endpoints REST estándar, reservado a los tokens de admin y de integración. Presupuestos negociados, tarifas de call center, gestos comerciales: hasta ahora había que retorcer las reglas de carrito para simular todo esto.
• Los carritos aislados. Una opción, desactivada por defecto, separa los carritos creados por el admin o las integraciones del carrito de storefront activo del cliente. Se acabó el carrito de presupuesto que machaca el que el cliente estaba llenando en ese mismo momento.
• El descuento de envío libre. Un endpoint de admin aplica un descuento de envío arbitrario a un carrito, para los casos que las reglas estándar no cubren — portes gratis tras una incidencia, una condición negociada en contrato.

Los precios de catálogo salen de la pantalla de admin

Las reglas de precio de catálogo ahora se gestionan por REST: creación, modificación, borrado, búsqueda y descubrimiento de metadatos. Un motor de pricing o un PIM puede por fin sincronizar las reglas en lugar de exigir una entrada manual. Y esas reglas se programan ahora a la hora exacta, no solo al día: una venta flash de 9 a 13 ya no exige un script casero.

En B2B, el webhook sabe con quién habla

El webhook de tarifas de envío recibe ahora el company_id del carrito y los atributos personalizados de la empresa: una integración de App Builder puede decidir si aplica una tarifa negociada sin volver a llamar a Commerce. Llegan dos cerrojos a la vez: una opción bloquea el registro de empresas por invitados no autenticados (mutación createCompany), y reCAPTCHA puede proteger las subidas de ficheros prefirmados. En devoluciones, la API REST acepta atributos personalizados en las líneas de devolución — sincronizar los RMA con un ERP ya no obliga a pasar por el GraphQL del storefront.

Los correos transaccionales dejan el monolito

Nuevos eventos permiten enviar los correos transaccionales desde una plataforma externa — Salesforce Marketing Cloud, por ejemplo — a través de App Builder. Si ya gestionas tus campañas de marketing en un ESP, es la ocasión de consolidar: mismas plantillas, misma entregabilidad, mismo reporting para la confirmación de pedido y la newsletter.

La restricción que acompaña a la apertura

Una línea de la release no aporta nada y puede romper lo existente: la Bulk API impone ahora un máximo de entidades por petición, no configurable, con error al superarlo. Si tus importaciones envían lotes masivos, revísalas antes de la próxima sincronización completa — trocear en bloques pasa a ser la norma, no una optimización.

Por dónde empezar

• Rescata el backlog de integración congelado « a la espera de la API » y crúzalo con esta release: reglas de precio de catálogo, precios custom y descuentos de envío quizá ya estén en él.
• Revisa tu uso de la Bulk API: tamaño de los lotes, gestión del error al superar el límite.
• En B2B, activa la restricción de registro de empresas y estudia el webhook enriquecido si tus tarifas de envío dependen del contrato del cliente.
• Si una renovación del emailing está en espera, la vía de los eventos hacia un ESP externo se convierte en la opción por defecto en el cloud service.

En una plataforma SaaS, la hoja de ruta del proveedor también es la tuya: lo que la API no ofrece hoy no está « por desarrollar », está « por esperar ». La release de octubre demuestra que la espera puede ser corta — y que una lista de carencias sin fecha, también aquí, es una lista equivocada.