En esta página
Esta fecha límite importa porque la autenticación es la puerta de entrada a cada devolución o cambio de autoservicio. Una migración fallida puede no impedir que la aplicación siga funcionando, pero sí poner en riesgo la distinción Built for Shopify y la experiencia del comprador durante la temporada alta de devoluciones.
Esta guía explica la regla, identifica las aplicaciones afectadas, distingue las devoluciones de la edición de pedidos antes de su preparación y ofrece a las agencias una auditoría de 7 pasos para completar antes del 1 de diciembre.
Qué cambia con el requisito de Customer Account API de Built for Shopify
A partir del 1 de diciembre de 2026, las aplicaciones de devoluciones y cambios con autoservicio para compradores deben usar Customer Account API como método principal de autenticación de clientes para conservar la distinción Built for Shopify. Shopify anunció el cambio el 17 de junio de 2026 y dio a los desarrolladores de las aplicaciones afectadas aproximadamente cinco meses y medio para migrar.
El registro oficial de cambios para desarrolladores de Shopify también incluye las aplicaciones de suscripciones. Para los equipos de devoluciones, la expresión clave es autoservicio para compradores: un cliente puede iniciar o gestionar una devolución, hacer seguimiento de un cambio o realizar una acción similar sin que el personal tramite la solicitud.
La consecuencia es más limitada de lo que sugieren algunos resúmenes de la fecha límite. Shopify indica que las aplicaciones que no cumplan el requisito corren el riesgo de perder la distinción Built for Shopify. No afirma que todas las aplicaciones afectadas dejarán de funcionar, desaparecerán de Shopify App Store o desactivarán los procesos de los comerciantes a medianoche.
| Pregunta de auditoría | Hasta el 30 de noviembre de 2026 | A partir del 1 de diciembre de 2026 |
|---|---|---|
| Método principal obligatorio de autenticación del comprador | Puede mantenerse el método actual | Customer Account API |
| Categorías afectadas | Devoluciones, cambios y suscripciones | Las mismas categorías |
| ¿Se requiere autoservicio para compradores? | Sí, para que se aplique la regla | Sí, para que se aplique la regla |
| Consecuencia inmediata indicada | El plazo de migración sigue abierto | La distinción Built for Shopify está en riesgo |
| Acción del comerciante | Solicitar pruebas al proveedor | Verificar el funcionamiento en producción |
Trata el 1 de diciembre como una fecha límite para supervisar a los proveedores, no como un cierre automático de la tienda online. Aun así, las agencias deben darle prioridad desde ahora, porque un cambio de distinción o una actualización apresurada de la autenticación pueden crear riesgos evitables durante las devoluciones de fin de año.
A quién afecta el requisito de Built for Shopify
Una aplicación se ve afectada cuando concurren tres condiciones: pertenece a la categoría de devoluciones, cambios o suscripciones; ofrece autoservicio para compradores; y pretende conservar la distinción Built for Shopify después del 1 de diciembre de 2026. El conjunto de aplicaciones de un comerciante no queda automáticamente incluido.
Usa esta lista de verificación para cada aplicación que intervenga después de la compra:
- Comprueba la categoría de la aplicación. Confirma cómo la clasifican Shopify y el proveedor, en lugar de deducir la categoría a partir del nombre de una función.
- Localiza los procesos disponibles para el comprador. Incluye el inicio de devoluciones, el seguimiento de cambios, las modificaciones de suscripciones y cualquier portal de clientes que permita realizar esas tareas.
- Identifica el método de autenticación actual. Pregunta si Customer Account API de Shopify ya es el método principal en producción.
- Confirma si el proveedor busca conservar la distinción Built for Shopify. Una aplicación sin la distinción no puede perderla, aunque la compatibilidad con las cuentas de cliente puede seguir siendo importante para su funcionamiento.
- Distingue las acciones anteriores a la preparación de pedidos de las posteriores a la entrega. Cambiar un pedido que aún no se ha preparado es editar un pedido. Devolver un producto entregado es una devolución. Que los clientes usen palabras parecidas no convierte ambas acciones en el mismo proceso.
Esta última distinción evita el error más común en las auditorías. Un comprador puede llamar «cambio» a una corrección de talla, pero sustituir una variante antes de preparar el pedido evita por completo la logística inversa. Un cambio posterior a la entrega requiere un proceso de devolución, criterios de recepción o inspección y el envío de un producto de reemplazo.
Nuestros datos muestran que, entre más de 10 millones de pedidos de Shopify, aproximadamente 1 de cada 19 (5,2 %) se edita después de la pantalla de pago (Revize, 2026). Por eso, las agencias deben auditar ambas etapas, pero aplicar el requisito de diciembre solo a las categorías que Shopify mencionó.
Qué hace realmente Customer Account API
Customer Account API autentica al comprador y da a una aplicación acceso controlado a los datos de su cuenta de Shopify. Una API, o interfaz de programación de aplicaciones, es una vía de comunicación regulada entre sistemas: la aplicación presenta una solicitud autorizada y Shopify devuelve únicamente los datos a los que esa solicitud puede acceder.
Esto difiere de Admin API, con la que una aplicación suele actuar en nombre del comerciante. La referencia de Customer Account API de Shopify indica que esta API para clientes permite consultar y actualizar la información del propio comprador, incluidos sus pedidos, perfiles y direcciones.
A fecha del 29 de agosto de 2026, la referencia de Shopify muestra 2026-07 como la versión más reciente. También documenta puntos de acceso de descubrimiento, que permiten a una aplicación obtener los puntos de acceso de autenticación y GraphQL correctos para cada tienda, en lugar de fijar un único dominio en el código.
La autenticación y la ubicación de la interfaz son cosas distintas. Una extensión de Customer Account UI determina dónde aparece una experiencia dentro de las cuentas de cliente. Customer Account API controla el acceso autenticado a los datos del cliente. Una aplicación puede tener un componente bien diseñado en la página de la cuenta y, aun así, necesitar que su proveedor confirme que la API exigida es el método principal de autenticación.
Las agencias deben pedir respuestas por escrito a cuatro preguntas técnicas:
- ¿El proceso del comprador en producción se autentica mediante Customer Account API?
- ¿Qué puntos de entrada la usan, incluidas las páginas de cuenta, los correos sobre pedidos, los enlaces directos y los portales externos?
- ¿La migración está activa para todos los comerciantes o solo para un grupo de prueba?
- ¿Qué pruebas aparecerán en el Partner Dashboard del proveedor cuando se evalúe la migración?
Advertencia: No aceptes «admite las nuevas cuentas de cliente» como prueba suficiente. La compatibilidad con esa interfaz y el cumplimiento del requisito de autenticación están relacionados, pero no significan lo mismo.
El lugar de Revize en la auditoría de diciembre
Revize cubre el autoservicio del cliente antes de la preparación de pedidos, mientras que la regla del 1 de diciembre se dirige a las aplicaciones específicas de devoluciones y cambios posteriores a la entrega. Actualmente, Shopify muestra la aplicación de edición de pedidos con la distinción Built for Shopify, compatible con las cuentas de cliente y clasificada en edición de pedidos, no en devoluciones y cambios.
Los clientes pueden usar su portal de autoservicio para editar pedidos y cambiar direcciones, variantes, cantidades o pedidos elegibles antes de su preparación. El proceso aparece en la página de estado del pedido de Shopify, y el comerciante controla el plazo durante el que se permiten las ediciones.
Esta distinción entre categorías resulta útil. Corregir el pedido antes de enviarlo evita que una devolución evitable entre en el sistema de logística inversa. Las devoluciones posteriores a la entrega siguen siendo un proceso aparte, por lo que una tienda con un gran volumen de pedidos puede combinar una aplicación de edición de pedidos con una plataforma específica de devoluciones sin exigir que un sistema haga el trabajo del otro.
| Necesidad del cliente | Etapa operativa | Sistema adecuado | Relación con la regla de diciembre |
|---|---|---|---|
| Corregir la dirección de envío | Antes de la preparación del pedido | Aplicación de edición de pedidos | La categoría por sí sola no está incluida |
| Cambiar la talla antes del despacho | Antes de la preparación del pedido | Aplicación de edición de pedidos | La categoría por sí sola no está incluida |
| Cancelar un pedido elegible | Antes de la preparación del pedido | Aplicación de edición de pedidos | La categoría por sí sola no está incluida |
| Devolver un artículo entregado | Después de la preparación del pedido | Aplicación de devoluciones | Incluida si ofrece autoservicio al comprador |
| Seguir el envío de un reemplazo | Proceso de devolución o cambio | Aplicación de cambios | Incluida si ofrece autoservicio al comprador |
Para las agencias que auditan tiendas de los planes Plus, Advanced y Grow, lo más práctico es mantener esa distinción. Conserva las correcciones anteriores a la preparación de pedidos en la aplicación de edición de pedidos y solicita por separado al proveedor de devoluciones pruebas de cumplimiento. Marcas como Square Enix, Venchi, Shelly, Nude Project, AYBL y TheGameCollection usan el modelo de autoservicio para clientes en distintas categorías de productos.
Si tu conjunto de aplicaciones todavía envía las solicitudes de cambio de dirección, variante y cancelación al equipo de atención al cliente, añade el autoservicio previo a la preparación de pedidos mientras el proveedor de devoluciones completa su migración de diciembre.
Cómo deben auditar las agencias el requisito de Customer Account API
Realiza esta auditoría de 7 pasos antes del 1 de diciembre de 2026 para cada cliente que ofrezca devoluciones, cambios o suscripciones de autoservicio. El resultado debe demostrar cómo funciona el sistema en producción desde cada punto de entrada del comprador, no limitarse a registrar la promesa de migración de un proveedor.
- Haz un inventario de las aplicaciones afectadas. Anota la categoría de Shopify de cada aplicación, su distinción Built for Shopify, las funciones disponibles para clientes, la persona responsable del negocio, la persona responsable de la parte técnica y la fecha de renovación. Separa las funciones de edición de pedidos, seguimiento, devoluciones, cambios, suscripciones, atención al cliente y almacén.
- Solicita una declaración fechada al proveedor. Pregunta si la aplicación está incluida en el requisito anunciado por Shopify para su categoría y si Customer Account API es su método principal de autenticación en producción. Si todavía no lo es, exige una fecha prevista de lanzamiento.
- Identifica todos los puntos de entrada del cliente. Prueba la navegación de la cuenta, las páginas de estado del pedido, los correos de confirmación, los enlaces de devolución, el seguimiento de cambios, los destinos de códigos QR, los navegadores móviles y los enlaces de tiendas headless. La autenticación puede parecer completa desde el menú principal de la cuenta, aunque un enlace directo antiguo todavía abra un portal separado.
- Revisa la transición de identidad. Comprueba qué sucede cuando el comprador ya ha iniciado sesión, ha cerrado sesión o vuelve mediante un marcador antiguo. Registra las redirecciones, las solicitudes repetidas de inicio de sesión, la pérdida del contexto del pedido y cualquier ruta que pida credenciales para un portal separado.
- Prueba los procesos completos de devolución y cambio. Usa pedidos de prueba controlados para comprobar una devolución elegible, un artículo no elegible, una devolución parcial, un cambio, una cancelación y el caso de un cliente que abandona el proceso y luego lo retoma. Verifica el estado final en Shopify y en cada sistema operativo posterior.
- Recopila pruebas de ambas partes. Guarda grabaciones del proceso del comprador, cronologías de los pedidos en Shopify, notas de las versiones del proveedor, confirmaciones del equipo de soporte y la fecha de cada prueba. Pide al desarrollador de la aplicación sus propias pruebas de evaluación de Built for Shopify, si están disponibles.
- Prepara un plan para revertir los cambios y escalar los problemas. Documenta la persona responsable por parte del cliente, la responsable en la agencia, el contacto del proveedor, el proceso alternativo de atención al cliente y la fecha para decidir si se sustituye una aplicación que no pueda aportar pruebas creíbles. Fija esa fecha antes de los periodos de restricción de cambios de la temporada alta.
No pospongas las pruebas hasta que cambie la distinción. El problema más costoso rara vez es la distinción en sí. Es que un cliente no pueda identificar su pedido, retomar un cambio o entender por qué la ruta habitual de su cuenta ahora funciona de otra manera.
¿Qué problemas pueden surgir después del 1 de diciembre?
La única consecuencia que Shopify indica expresamente para el 1 de diciembre es que una aplicación afectada que no cumpla el requisito corre el riesgo de perder la distinción Built for Shopify. Cualquier afirmación más contundente, incluida su eliminación automática de Shopify App Store o el cierre inmediato de los portales de devoluciones, va más allá del aviso publicado.
Aun así, los comerciantes deben evaluar tres riesgos prácticos:
- Riesgo de confianza: La aplicación puede perder una señal de calidad que los comerciantes usan al contratar herramientas y revisar su conjunto de aplicaciones.
- Riesgo de lanzamiento: Una migración tardía de la autenticación puede introducir bucles de inicio de sesión, redirecciones que no funcionan o pérdida del contexto del pedido. Comprueba estos casos con pedidos de prueba, en lugar de dar por hecho que ocurrirán.
- Riesgo para la atención al cliente: Si una ruta de autoservicio deja de ser fiable, los clientes pueden recurrir al correo electrónico o al chat durante el periodo de mayor actividad de devoluciones.
La distinción es el mecanismo de cumplimiento que Shopify ha señalado. La experiencia del comprador es lo que el comerciante debe probar en la práctica.
Consejo: Guarda la declaración del proveedor y las pruebas que hayas realizado en el mismo registro de auditoría. Una fecha en la hoja de ruta demuestra intención; un proceso completo del comprador demuestra que está listo.
Lo esencial para quienes gestionan tiendas Plus
Con 94 días por delante a fecha del 29 de agosto, las agencias deberían terminar la fase de identificación en septiembre, las pruebas en producción en octubre y las decisiones sobre correcciones antes de las restricciones de cambios de noviembre. La fecha límite del 1 de diciembre es concreta, verificable y lo bastante acotada para auditarla sin sustituir todo el conjunto de aplicaciones posteriores a la compra.
Esto es lo que debes hacer esta semana:
- Haz un inventario de todas las aplicaciones de devoluciones, cambios y suscripciones que usan los compradores.
- Pregunta a cada proveedor si la autenticación mediante Customer Account API es el método principal en producción.
- Prueba todos los puntos de entrada del comprador con pedidos controlados.
- Separa la edición anterior a la preparación de pedidos de las devoluciones posteriores a la entrega.
- Registra las pruebas, las personas responsables, las fechas límite y una ruta alternativa.
El objetivo es disponer de una identidad de cliente fiable a lo largo de toda la experiencia posterior a la compra, respaldada por pruebas que tu agencia pueda demostrar.
Preguntas frecuentes
Estas respuestas abordan las 10 preguntas que las agencias y quienes gestionan tiendas Plus deben resolver antes del 1 de diciembre de 2026. La regla publicada es breve, así que conviene distinguir el requisito exacto de Shopify de las conclusiones operativas que todavía necesitan pruebas del proveedor y pedidos de prueba.
¿Qué cambia el 1 de diciembre de 2026?
Las aplicaciones afectadas de devoluciones, cambios y suscripciones deben usar Customer Account API como método principal de autenticación de clientes para conservar la distinción Built for Shopify. La regla se aplica cuando la aplicación ofrece una experiencia de autoservicio para compradores. Shopify anunció la fecha límite el 17 de junio de 2026.
¿Dejará de funcionar una aplicación de devoluciones el 1 de diciembre?
Shopify no ha dicho que las aplicaciones afectadas dejarán de funcionar automáticamente el 1 de diciembre. La consecuencia publicada es que las aplicaciones que no cumplan el requisito corren el riesgo de perder la distinción Built for Shopify. Los comerciantes deben preguntar a los proveedores sobre la continuidad del servicio y verificar la experiencia del cliente con pedidos de prueba, en vez de predecir una interrupción.
¿Se aplica el requisito a todas las aplicaciones de Shopify?
No, el requisito anunciado no se aplica a todas las aplicaciones de Shopify. Shopify mencionó las aplicaciones de devoluciones y cambios, y las de suscripciones con autoservicio para compradores. No se debe considerar incluidas las categorías de seguimiento, atención al cliente, edición de pedidos, almacén y otras, salvo que Shopify o el proveedor aporten pruebas específicas de esa categoría.
¿Es el comerciante responsable de la migración de la API?
El desarrollador de la aplicación implementa la migración de la API, mientras que el comerciante sigue siendo responsable de gestionar los riesgos relacionados con el proveedor y las operaciones. Las agencias deben obtener información sobre el estado de producción del proveedor, probar los procesos afectados del comprador y documentar una alternativa. Un comerciante no puede corregir la arquitectura de autenticación de una aplicación de terceros desde la configuración de Shopify Admin.
¿Qué es Customer Account API?
Customer Account API es la interfaz de Shopify para el acceso autenticado del comprador a los datos de su cuenta. Permite a una aplicación trabajar con información que pertenece al cliente que ha iniciado sesión, como pedidos, datos del perfil y direcciones. Shopify la presenta como la capa de autenticación común para las cuentas de cliente, las tiendas online y las aplicaciones conectadas.
¿Es la API lo mismo que una extensión de Customer Account UI?
No, la autenticación y la ubicación de la interfaz son aspectos distintos. Customer Account API regula el acceso autenticado a los datos. Las extensiones de Customer Account UI sitúan las experiencias de las aplicaciones dentro de las interfaces de las cuentas de Shopify. Una aplicación puede necesitar ambas y, aun así, tener que demostrar que la API es su método principal de autenticación.
¿Es necesario trasladar todo el portal de devoluciones?
La regla publicada para diciembre exige específicamente Customer Account API como método principal de autenticación. No indica que todas las pantallas deban reconstruirse dentro de una única interfaz de Shopify. Las agencias deben preguntar a los proveedores qué componentes de la interfaz y del sistema interno van a cambiar y, después, probar el proceso completo, porque la autenticación afecta a todos los pasos posteriores.
¿Cómo deben probarse los pedidos de invitados?
Prueba los pedidos de invitados mediante los enlaces y estados de autenticación reales que admite el proveedor. Incluye el acceso desde el correo de confirmación, navegadores sin sesión iniciada, sesiones caducadas y visitas posteriores desde otro dispositivo. No des por hecho que una prueba correcta con una cuenta que ya tiene la sesión iniciada demuestra que todas las rutas de invitados o anteriores a la autenticación están listas.
¿Puede un comerciante conservar su aplicación de devoluciones actual?
Sí, siempre que el proveedor pueda demostrar una vía creíble para cumplir el requisito y el proceso en producción supere las pruebas. La fecha límite no obliga por sí sola a los comerciantes a sustituir una aplicación. Sustituirla pasa a ser una decisión operativa cuando el proveedor no puede aportar pruebas, incumple los hitos acordados o falla las pruebas controladas del proceso del comprador.
¿Qué debe conservar una agencia como prueba de cumplimiento?
Conserva la declaración del proveedor, la fecha de la prueba, la grabación del proceso del comprador, los identificadores de los pedidos afectados, los estados finales en Shopify y la persona responsable de escalar los problemas. Añade capturas del estado actual de la distinción Built for Shopify de la aplicación y las pruebas pertinentes del Partner Dashboard cuando el proveedor pueda compartirlas. El registro debe mostrar el comportamiento observado, no solo el trabajo previsto.
Reúne las pruebas ahora, mantén cada sistema centrado en la etapa operativa que le corresponde y llega al 1 de diciembre con una experiencia de cliente probada, no con una suposición.