Las apps públicas necesitan tokens offline con caducidad antes de 2027

El 20 de mayo de 2026 Shopify publicó una entrada de changelog que importará más de lo que su extensión sugiere: a partir del 1 de enero de 2027, todas las apps públicas deben usar tokens de acceso offline con caducidad. Las apps que sigan guardando tokens permanentes dejarán de funcionar después de esa fecha, incluidas las creadas mucho antes de que se escribiera la regla.

Qué cambia exactamente

Un token de acceso offline es la credencial que usa una app cuando nadie ha iniciado sesión: la que hay detrás del procesamiento de webhooks, los trabajos programados, las sincronizaciones en segundo plano y cada parte de una app que corre mientras el comerciante duerme. Históricamente esos tokens no caducaban. Una vez concedidos, valían hasta que se desinstalara la app.

Con la nueva regla caducan, y la app es responsable de renovarlos. Ese es todo el cambio, y la razón es la de siempre: una credencial que nunca caduca es una credencial que nunca se rota, y una filtrada sigue siendo útil indefinidamente.

Qué significa para una app que ya está publicada

El detalle importante es quién hace el trabajo. Los comerciantes no reinstalan. No hay pantalla de consentimiento, ni campaña de correo, ni cola de soporte llena de gente preguntando por qué se cerró su sesión. La migración ocurre del lado del desarrollador: intercambiar la credencial, guardar la nueva junto con su caducidad y renovarla antes de que expire.

En concreto, eso son tres cosas dentro de la app.

• El almacenamiento cambia de forma. Una fila que guardaba una cadena ahora guarda un token, una caducidad y lo necesario para obtener el siguiente. Todo punto del código que leía "el token" pasa a leer "un token actualmente válido".
• La renovación tiene que centralizarse. Si las lecturas del token están repartidas por una docena de sitios, esta migración es donde eso se arregla, porque la alternativa son doce lugares que necesitan saber de caducidades.
• El fallo tiene que manejarse. Una renovación puede fallar por motivos que no son transitorios —app desinstalada, tienda cerrada, permiso revocado— y esos piden una respuesta distinta a la de un corte de red. Shopify documenta una ventana de reintento: úsala para el caso transitorio y detente en el resto.

Por qué es fácil que se pase por alto

Esta retirada no tiene ninguna de las señales que hacen visible una fecha límite. No rompe una página que el comerciante mire, y no es de los cambios que aparecen donde alguien ya está mirando. Falla en una fecha, en segundo plano, en la parte de la app que nadie enseña en una demo.

Además es el tipo de trabajo que se aplaza porque es invisible cuando está hecho. Después nada de la app se ve distinto, lo que dificulta priorizarlo frente a funcionalidades y facilita empujarlo al siguiente sprint, una y otra vez, hasta diciembre.

Qué haríamos ahora

Averiguar si aplica. Si la app es pública y guarda un token offline sin una columna de caducidad al lado, aplica.

Después, tratarlo como una migración de datos y no como un cambio de autenticación, porque ahí está el riesgo real. El intercambio de credenciales es un flujo documentado. Lo que sale mal es un almacén de tokens escrito hace cinco años por alguien que dio por hecho que bastaba con una cadena, leído desde sitios anteriores a la arquitectura actual, en una app que no se puede apagar mientras se arregla.

De este anuncio a la fecha límite hay algo más de siete meses, que da holgura. Empezar en diciembre, no.

Una cosa más que conviene hacer ya que estás dentro: registra los fallos de renovación con el dominio de la tienda y el motivo. Cuando algo salga mal en enero, la diferencia entre una tarde y una semana es si puedes decir qué tiendas están afectadas sin recorrer todas las filas.

Si mantienes una app publicada, esto va con el resto del trabajo de apps públicas; si la app es a medida o privada, la misma pregunta de almacenamiento aplica a las apps privadas.