Shopify está trasladando las reglas de envío del comercio a Markets mediante un despliegue gradual. Si una aplicación lee o modifica esas reglas, revisa su compatibilidad y prueba destinos, productos y opciones reales de tu tienda. Una respuesta correcta de la API no demuestra que el checkout utilice la tarifa esperada ni que tu comercio ya haya cambiado.
¿Qué significa que los envíos pasen a configurarse por mercados?
Al vender en varias regiones aparecen diferencias de destino, producto, almacén y recogida. Una regla aparentemente correcta puede fallar cuando una aplicación modifica tarifas. La dificultad no está únicamente en establecer un importe, sino en saber qué sistema tiene autoridad sobre la configuración.
Shopify anunció en julio de 2026 un modelo de envíos basado en Markets. La documentación explica que la configuración de envíos creada por el comercio se asocia a cada mercado y puede variar según condiciones de producto y ubicación. Esto cambia dónde deben leer y escribir las integraciones que gestionan configuraciones de entrega del comerciante. No equivale a decir que todos los transportistas, todos los planes o todas las tiendas tendrán las mismas opciones de inmediato.
La distinción técnica más importante es entre perfiles de entrega propiedad del comercio y perfiles creados por aplicaciones. Shopify indica que los perfiles de aplicaciones siguen utilizando sus API correspondientes y que las tarifas aportadas por esas aplicaciones continúan apareciendo en la experiencia nueva. Por tanto, una auditoría que simplemente busque la palabra «delivery profile» en el código y ordene reemplazarlo todo puede romper algo que todavía es válido.
Para el responsable de la tienda, el objetivo no debería ser «migrar porque hay una API nueva», sino proteger el precio de envío que ve el comprador y la información que recibe el equipo de operaciones. Si el cliente llega al pago y descubre una opción equivocada, la explicación técnica llega demasiado tarde. El proyecto debe empezar por la experiencia de compra y recorrer hacia atrás las reglas que la producen.
¿Cómo saber si tu tienda tiene una integración afectada?
Haz inventario de todas las herramientas que intervienen en el cálculo o mantenimiento de los envíos: aplicaciones de tarifas, conectores con operadores logísticos, software de almacén, automatizaciones internas y scripts que actualizan reglas. Pregunta a cada proveedor si su integración lee o modifica la configuración de envíos del comercio, o si solo utiliza perfiles propios de la aplicación. No basta con preguntar si «es compatible con Shopify»; esa respuesta es demasiado general.
La guía oficial de actualización, consultada el 16/10/2026, señala el campo marketDrivenShipping en ShopFeatures como mecanismo para detectar qué modelo utiliza una tienda. También explica que las integraciones que gestionan la configuración propiedad del comerciante deben migrar a las API adecuadas de Markets o a otros enfoques compatibles según el caso. No intentes deducir el estado de la tienda solo por la fecha del calendario: la activación puede depender de la compatibilidad de las aplicaciones y de decisiones de adopción.
Pide un mapa muy sencillo: origen de la regla, sistema que la modifica, lugar donde se comprueba y persona responsable. Si dos herramientas pueden cambiar el mismo criterio, documenta cuál manda. Si una aplicación únicamente muestra tarifas y otra las actualiza, la prueba debe incluir ambas. Y si nadie sabe de dónde sale una condición especial para un producto voluminoso, ese desconocimiento ya es un riesgo operativo que merece resolverse.
Antes de tocar producción, conserva una descripción de las reglas vigentes y de los casos excepcionales. Incluye destinos habituales, zonas excluidas, productos con restricciones y combinaciones de recogida o entrega. Puedes crear escenarios de prueba sin datos personales reales y con expectativas claras.
¿Qué deberías probar en el checkout antes de activar el cambio?
Empieza con una matriz de escenarios, no con una compra de prueba aislada. Un carrito de un solo producto no demuestra que funcionen combinaciones de artículos, destinos y almacenes. Incluye casos con productos de características distintas, direcciones en mercados diferentes, reglas de envío gratuitas si existen, recogida cuando esté configurada y opciones aportadas por aplicaciones. Anota qué opción debería aparecer y por qué. No supongas que una función está disponible en tu plan: compruébalo con la documentación y la configuración real.
La documentación de Shopify recomienda utilizar una tienda de desarrollo con la vista previa de market-driven shipping para validar rutas de lectura y escritura. Si una integración consulta la configuración antigua, podría mostrar una fotografía obsoleta. Más delicado aún: Shopify advierte de que determinadas mutaciones antiguas sobre perfiles propiedad del comerciante pueden responder sin error y, aun así, no modificar los ajustes activos. Un registro que diga «operación completada» no prueba que el checkout haya cambiado.
Por eso conviene verificar el efecto final. Tras modificar una regla en un entorno de prueba, vuelve a consultar la fuente de verdad y reproduce el checkout correspondiente. Comprueba tanto la opción visible como la lógica que la origina. Si hay varias aplicaciones, ejecuta la prueba con todas conectadas y después con una variación controlada para identificar interferencias. Mantén un registro de diferencias que incluya la regla esperada, el resultado observado y el responsable de corregirlo.
El caso de envío y recogida en un mismo pedido requiere especial atención cuando la tienda utiliza funciones que lo permiten. Shopify señala que puede cambiar cómo circula la información de entrega y preparación entre sistemas, aunque no haya una nueva API específica para esa experiencia. Si tu negocio no ofrece esa modalidad, no conviertas la prueba en una obligación ficticia. Prioriza las rutas que realmente utiliza tu tienda y añade las que estén previstas a corto plazo.
¿Qué calendario debes manejar sin precipitar una migración?
La hoja de ruta oficial sitúa la vista previa para desarrolladores en julio de 2026, el inicio de la adopción por comercios el 1 de octubre de 2026 y la generalización del nuevo modelo para julio de 2027. Son hitos publicados por Shopify, no una garantía de que tu tienda ya haya cambiado. La propia guía advierte de que las fechas objetivo pueden variar y de que la activación automática de determinadas tiendas depende de que las aplicaciones sean compatibles.
Desde octubre, una instalación nueva puede mostrar advertencias de compatibilidad y un comercio que active manualmente el modelo antes de que una aplicación esté preparada puede encontrar fallos. La respuesta correcta no es bloquear todas las mejoras, sino coordinar a proveedores y responsables. Define quién comprueba la compatibilidad, quién aprueba el cambio y cómo se comunica al equipo de atención al cliente si alguna opción de envío se modifica.
También es importante preparar una ventana de pruebas que no coincida con una campaña crítica. Antes de activar, registra qué reglas deben seguir funcionando; durante la transición, revisa incidencias y consultas; después, comprueba que los procesos de almacén reciben la información necesaria. No atribuyas automáticamente cualquier reclamación de entrega al nuevo modelo: separa errores de tarifa, retrasos de transporte y problemas de preparación.
Si una aplicación necesita cambios, solicita al proveedor una confirmación concreta de las rutas afectadas y del plan de pruebas. «Actualizado a la última API» no basta, porque una integración puede usar una versión reciente y continuar leyendo un recurso que ya no representa la configuración activa. El criterio de aceptación debe ser funcional: que la tarifa correcta aparezca y que el proceso posterior reciba los datos adecuados.
¿Cómo convertir la revisión técnica en un procedimiento operativo útil?
La responsable de ecommerce no tiene por qué conocer cada mutación GraphQL, pero sí debe poder responder a tres preguntas: quién configura el envío, quién puede modificarlo y cómo se detecta un cambio inesperado. Una hoja compartida puede recoger respuestas, pruebas y contactos de proveedores.
Cuando el sistema es complejo, añade una revisión periódica de reglas y excepciones. Comprueba que las opciones de entrega visibles coinciden con la política comercial publicada. Si el soporte recibe quejas sobre una zona concreta, necesita identificar rápidamente la configuración aplicable sin recorrer varios paneles. Una automatización puede alertar de discrepancias conocidas, pero no debería cambiar precios de transporte por iniciativa propia sin reglas aprobadas.
Evita confundir preparación con urgencia artificial. No todas las tiendas requieren un desarrollo a medida; algunas solo necesitan que sus proveedores confirmen compatibilidad y que el equipo pruebe el checkout. Otras, con reglas personalizadas y aplicaciones que escriben configuraciones, sí necesitarán intervención técnica. La decisión debe basarse en dependencias reales, no en el tamaño aparente del catálogo.
| Escenario | Resultado esperado | Evidencia necesaria |
|---|---|---|
| Destino habitual | Opción comercial prevista | Checkout de prueba |
| Producto restringido | Regla específica aplicada | Configuración y carrito |
| Tarifa de aplicación | Opción compatible visible | Confirmación del proveedor |
| Cambio de regla | Lectura y efecto coherentes | Comparación antes y después |
Cómo lo hemos abordado en meiika
En meiika estudiamos sistemas a medida conectando reglas, responsables y resultados visibles. En un ecommerce, la prueba debe llegar hasta la opción que ve el comprador y la información que recibe operaciones.
La mirada de Growth & MarTech ayuda a relacionar esa experiencia con la promesa comercial. No describimos una migración ejecutada para un cliente ni garantizamos tarifas o compatibilidad sin revisar la tienda.