Arquitectura · 27 de octubre de 2026 · Daniel Murillo

Cómo funcionan las notificaciones push: VAPID, FCM, APNs y multiplataforma

Push no es una conexión directa al móvil. Tokens, topics, VAPID, FCM, APNs, Web Push y qué cambia con Capacitor, React Native o Flutter.

Una notificación push no se envía directamente desde tu backend al celular. Tu sistema identifica una instalación o una audiencia; un servicio de push de la plataforma enruta el mensaje al sistema operativo o al navegador, que decide cómo presentarlo y cuándo despertar la aplicación.

Introducción: parece un mensaje, pero es una cadena de sistemas

Cuando una aplicación muestra «Tienes un mensaje nuevo», puede parecer que el backend abrió una conexión con el teléfono y le envió un texto. En realidad, el mecanismo suele ser diferente.

El backend de tu aplicación decide que hay algo que notificar. Envía una solicitud a un proveedor de push, como Firebase Cloud Messaging (FCM), Apple Push Notification service (APNs) o el servicio push del navegador. Ese proveedor mantiene o administra la infraestructura de entrega hacia los dispositivos. El sistema operativo o el navegador recibe el mensaje y, dependiendo de su contenido y del estado de la aplicación, puede mostrar una notificación, entregar datos a la app o ejecutar un manejador permitido.

Esto permite que el backend no tenga que mantener una conexión WebSocket propia con cada teléfono solo para notificarlo cuando está inactivo.

Este artículo recorre el proceso completo: cómo se registra un dispositivo, qué son los tokens, qué significa VAPID, cómo funcionan los topics, qué diferencias hay entre iOS y Android y qué cambia al desarrollar con web, Capacitor, Cordova, React Native o Flutter.

1. Push, notificación local y mensajería en tiempo real no son lo mismo

Antes de hablar de proveedores, conviene distinguir tres mecanismos.

Notificación local

La aplicación programa o genera la notificación en el propio dispositivo. Por ejemplo, un recordatorio para dentro de dos horas. No necesita que tu backend envíe un mensaje en ese instante, aunque la aplicación podría haber obtenido previamente los datos.

Notificación push remota

Tu backend solicita al proveedor push que entregue un mensaje a una instalación o a una audiencia. El proveedor se encarga de la ruta hasta el dispositivo. Puede que la aplicación no esté abierta.

Mensajería en tiempo real

Un WebSocket o una conexión similar mantiene un canal de comunicación entre el cliente y un servidor mientras la conexión está activa. Es útil para chat, presencia y actualizaciones interactivas. No sustituye por sí solo al push cuando la app está suspendida o el sistema operativo ha cerrado su proceso.

Una arquitectura puede combinar ambos mecanismos: WebSocket mientras la app está activa y push para avisar de eventos importantes cuando está en segundo plano.

2. La arquitectura general de una notificación push

Evento de negocio en el backend
              |
              v
   Servicio de notificaciones
              |
              v
     Resolver destinatarios
        |              |
        v              v
 Token / instalación   Topic / segmento
        |              |
        +------+-------+
               |
               v
      FCM / APNs / Web Push
               |
               v
  Sistema operativo o navegador
               |
               v
 Notificación visible / callback / service worker
               |
               v
  Deep link o navegación dentro de la app

Los componentes principales son:

Backend de negocio: detecta un evento, como un mensaje nuevo, una compra o un recordatorio.
Servicio de notificaciones: decide a quién notificar, construye el payload y aplica preferencias, prioridades y reglas.
Registro de instalaciones: relaciona cuentas de usuario con tokens o suscripciones de cada instalación.
Proveedor push: FCM, APNs, Web Push u otra capa que se integra con los servicios de plataforma.
Sistema operativo o navegador: recibe, presenta y enruta la interacción.
Aplicación: interpreta los datos y abre la pantalla adecuada cuando corresponde.

Apple describe una cadena equivalente para notificaciones remotas: servidor proveedor, APNs, dispositivo y aplicación. APNs administra la infraestructura de conexión hacia el dispositivo; el servidor de la aplicación no necesita sostener una conexión directa con cada teléfono.

Fuente: Apple — Setting up a remote notification server

3. ¿Cómo se registra un dispositivo?

Para enviar un push dirigido, tu sistema necesita un identificador que el proveedor pueda enrutar.

Un flujo típico es:

El usuario instala o abre la aplicación, o entra a una web compatible.
La aplicación explica el valor de las notificaciones y solicita permiso cuando corresponda.
El SDK o la plataforma registra esa instalación con el proveedor.
El proveedor devuelve un token o una suscripción.
La aplicación envía ese identificador a tu backend autenticado.
Tu backend lo guarda y lo relaciona con el usuario, la plataforma y la instalación.
Cuando ocurre un evento, el backend consulta el registro y envía el push al destinatario correcto.

En Apple, el token APNs identifica una combinación de aplicación y dispositivo: dos aplicaciones instaladas en el mismo iPhone no comparten el mismo token. En FCM, el registration token se utiliza para dirigir mensajes a una instancia registrada de la aplicación. En Web Push, el cliente guarda una suscripción que incluye un endpoint y claves de cifrado.

El token no es el ID del usuario

No diseñes la base de datos suponiendo que cada usuario tiene un único token. Una persona puede tener:

un iPhone y una tablet;
un teléfono personal y otro de trabajo;
una app instalada y una PWA suscrita;
varias instalaciones después de reinstalar;
sesiones de una misma cuenta en dispositivos distintos.

Por eso, una tabla de registro puede tener una fila por instalación o destino de push, no solo una columna push_token en users.

Campo	Para qué sirve
`id`	ID interno del registro
`user_id`	Cuenta a la que pertenece, si hay sesión
`platform`	`ios`, `android`, `web`
`provider`	`apns`, `fcm`, `webpush`, etc.
`token` o `subscription`	Dirección/token de push; proteger y limitar acceso
`installation_id`	ID interno de la instalación
`app_version`	Diagnóstico y compatibilidad
`last_seen_at`	Última actividad conocida
`enabled`	Preferencia o estado de registro
`created_at`, `updated_at`	Ciclo de vida del registro

En Web Push, la suscripción incluye endpoint y material criptográfico; no se debe tratar como si fuera exactamente el mismo tipo de token que FCM o APNs.

Los tokens cambian

Tokens y suscripciones pueden rotar, invalidarse o dejar de ser válidos después de reinstalar, restaurar, cambiar configuraciones o revocar permisos. La app debe actualizar el registro en el backend cuando reciba un token nuevo y el servidor debe retirar destinos que el proveedor reporte como inválidos.

No uses el token como contraseña de usuario ni como prueba suficiente de identidad. Debe registrarse mediante un endpoint autenticado, validarse la relación con la cuenta y evitar que una persona pueda asociar arbitrariamente el token de otra.

4. ¿Cómo sabe el proveedor a qué dispositivo enviar la notificación?

Esta es la pregunta clave: ¿cómo es que una notificación le llega a un solo dispositivo y no a todos?

Porque el backend no envía simplemente «una notificación para la aplicación». Envía un mensaje con un destino concreto.

Envío directo a un token

Supongamos que una cuenta está conectada en tres instalaciones:

iPhone de la persona: token token-A
Android de la persona: token token-B
navegador del portátil: suscripción subscription-C

Si el backend envía el mensaje al token-A, el proveedor intenta entregarlo a esa instalación asociada con el token A. No lo enruta automáticamente al token B ni a la suscripción C.

Si quieres que la persona reciba el aviso en todos sus dispositivos, el backend debe enviar el mensaje a cada destino activo, o utilizar una abstracción de proveedor que gestione esa lista. El proveedor no adivina qué dispositivos pertenecen a la misma persona: tu sistema debe mantener esa relación.

El identificador no siempre representa un teléfono físico

Un token normalmente identifica un destino de aplicación o instalación en una plataforma, no necesariamente un hardware único. La semántica exacta depende del proveedor.

APNs: token asociado a la app y al dispositivo.
FCM: token de registro de una instancia de la app.
Web Push: suscripción de un service worker para un sitio/origen y navegador.
Un proveedor intermediario puede crear su propio ID de instalación o endpoint y mantener el token de plataforma detrás.

¿Y si el usuario tiene varias sesiones?

Define una política de producto:

enviar a todas las instalaciones activas;
enviar solo a la instalación que inició la acción;
excluir el dispositivo actual;
enviar a todos los dispositivos excepto los que ya recibieron o leyeron el evento;
agrupar o silenciar mensajes duplicados.

No es una decisión automática del sistema push. Es lógica de tu backend.

5. Topics, tokens y grupos: tres estrategias diferentes

La palabra topic se utiliza en varios sistemas y no siempre significa lo mismo.

Destinatario individual: token

Se utiliza cuando conoces exactamente la instalación a la que quieres enviar el mensaje.

Ejemplos:

«Tu pedido fue enviado» a las instalaciones de la cuenta.
«Tienes un mensaje nuevo» a un usuario concreto.
«Se inició sesión en tu cuenta» a sus dispositivos registrados.

Topic de FCM

Un topic de FCM es una audiencia a la que las instancias de la aplicación se suscriben. El backend publica en ese topic y FCM distribuye el mensaje a los registros suscritos.

Ejemplos: product_updates, team_42_announcements, weather_city_abc.

Los topics sirven para difusiones y audiencias amplias. No son lo ideal para información privada o altamente personalizada. Si una notificación contiene información confidencial, no la envíes a un topic público o demasiado amplio.

Fuente: Firebase — Topic messaging

Topic de un broker, como Google Cloud Pub/Sub

Un topic de Google Cloud Pub/Sub distribuye eventos entre servicios backend y suscripciones de procesamiento. No es lo mismo que un topic de FCM dirigido a instalaciones móviles.

Pedido actualizado
       |
       v
Google Cloud Pub/Sub: orders-events
       |
       v
Worker de notificaciones
       |
       +--> Busca al usuario y sus instalaciones
       |
       +--> Envía a FCM / APNs / Web Push

Pub/Sub desacopla productores y consumidores del backend; FCM o APNs se encargan del último tramo hacia dispositivos. Google Cloud indica expresamente que Pub/Sub está orientado a comunicación entre servicios, mientras FCM es una opción más apropiada para entregar mensajes a aplicaciones web y móviles.

Topics propios en tu aplicación

También puedes mantener segmentos en tu base de datos: por ejemplo, todos los usuarios que siguen a un artista. Tu backend resuelve esa audiencia a una lista de tokens y realiza envíos por lotes. En este caso, «topic» es una abstracción de tu dominio, no necesariamente un topic de FCM.

6. VAPID: qué es y cuándo se utiliza

VAPID significa Voluntary Application Server Identification. Es un mecanismo de identificación/autenticación del servidor de aplicación en el protocolo Web Push.

En Web Push, el navegador o el sistema de push proporciona una suscripción que contiene un endpoint y claves de cifrado. El servidor de tu aplicación genera un mensaje cifrado y lo envía a ese endpoint. VAPID permite que el servidor se identifique ante el servicio push usando un par de claves: pública y privada.

Qué hace VAPID

Identifica al servidor de aplicación ante el servicio push.
Usa una clave pública que se proporciona al crear la suscripción.
Firma un token de autorización con la clave privada.
Ayuda al servicio push a relacionar una suscripción con el servidor autorizado para enviarle mensajes.

Qué no hace VAPID

No es el token del dispositivo.
No es el contenido de la notificación.
No es un topic.
No reemplaza el cifrado del payload Web Push.
No es la credencial que usa una app nativa para autenticar directamente contra APNs.
No es obligatorio para todas las rutas de notificaciones nativas con FCM/APNs.

En aplicaciones web, la clave pública VAPID se utiliza en el flujo de suscripción; la clave privada debe mantenerse en el backend y nunca incluirse en el frontend.

Apple documenta VAPID como parte de la preparación del servidor para Web Push. También especifica que se construye y cifra el payload y se envía a la URL de endpoint de la suscripción.

Fuente: Apple — Sending web push notifications

Flujo simplificado de Web Push

El usuario acepta notificaciones.
El navegador registra un service worker.
El navegador crea una PushSubscription, usando la clave pública VAPID cuando corresponda.
El frontend envía la suscripción al backend.
El backend almacena endpoint y claves de suscripción.
Cuando ocurre un evento, el backend cifra el payload y firma la solicitud con VAPID.
Envía la solicitud al endpoint del servicio push.
El navegador recibe el evento push en el service worker y puede mostrar una notificación.

const registration = await navigator.serviceWorker.register("/sw.js");

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: PUBLIC_VAPID_KEY,
});

await fetch("/api/push-subscriptions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(subscription),
});

La clave pública puede estar en el cliente; la privada nunca. El backend debe usar una biblioteca Web Push mantenida para cifrado, formato y firma, en lugar de implementar manualmente el protocolo.

7. Google FCM y Apple APNs: qué hace cada uno

Firebase Cloud Messaging (FCM)

FCM es el servicio de Google para enviar mensajes a instancias de aplicaciones. Se integra especialmente con Android y también puede participar en flujos de iOS y Web Push. Para enviar mensajes desde un servidor se usa normalmente la API HTTP v1 o el Admin SDK, con credenciales de servidor.

FCM permite direccionar mensajes a:

un token de registro;
un topic;
una condición basada en topics.

El payload puede contener una sección notification, datos personalizados (data) o ambas. El comportamiento depende de la plataforma y del estado de la aplicación.

Fuente: Firebase — Send a message using FCM HTTP v1

Apple Push Notification service (APNs)

APNs es la infraestructura de Apple para las notificaciones remotas de sus plataformas. El servidor proveedor se autentica con APNs, por ejemplo con un token de proveedor firmado con una clave de autenticación o mediante certificados según la configuración. APNs enruta el mensaje hacia el dispositivo.

El servidor de la aplicación no necesita mantener una conexión directa con cada iPhone. APNs administra las conexiones de entrega y puede almacenar temporalmente notificaciones para dispositivos fuera de línea, sujeto a las políticas y límites del servicio.

¿FCM reemplaza a APNs en iOS?

No exactamente. En una app iOS que utiliza Firebase Cloud Messaging, FCM puede proporcionar una API unificada para el backend, pero el registro y la entrega en el ecosistema Apple siguen implicando APNs. La app debe estar configurada con las capacidades y credenciales necesarias para la plataforma.

En otras palabras, FCM puede ser una capa común para tu backend, pero no elimina las reglas de Apple ni hace desaparecer APNs de la ruta de entrega en iOS.

8. ¿Qué ocurre en Android, iOS y navegadores?

Android nativo

La aplicación se registra con FCM y obtiene un token. Tu backend lo almacena y envía mensajes mediante FCM. El sistema Android gestiona la presentación de las notificaciones según el payload, el canal de notificación, los permisos y el estado de la app.

Desde Android 13, las aplicaciones deben solicitar el permiso de ejecución POST_NOTIFICATIONS para mostrar notificaciones no exentas. Que FCM acepte un mensaje no significa que el usuario vaya a ver una alerta si el permiso está denegado o los ajustes del sistema la bloquean.

Fuente: Android Developers — Notification runtime permission

iOS nativo

La app solicita autorización al usuario, se registra con APNs y recibe un device token. Ese token se envía al backend. El servidor envía el payload a APNs, que lo enruta al dispositivo.

La autorización del usuario, los ajustes del sistema, el modo de concentración, el resumen programado, la conectividad y las políticas del sistema pueden afectar la presentación. El servidor no puede forzar que una notificación aparezca como banner en todos los contextos.

Fuente: Apple — User Notifications

Web y PWA

La web usa la Push API y un service worker. La suscripción contiene un endpoint y claves criptográficas; el backend usa Web Push y VAPID para enviar el payload al servicio push del navegador.

Las posibilidades varían según navegador, sistema operativo, instalación de la PWA y permisos. No asumas el mismo comportamiento en Chrome para Android, Safari en macOS y Safari en iPhone.

En iOS/iPadOS 16.4+, Web Push solo funciona para sitios añadidos a la pantalla de inicio y abiertos como web app. En una pestaña normal de Safari, Notification puede no existir y no podrás suscribir al usuario. La petición de permiso debe ocurrir en respuesta a un gesto (por ejemplo, un tap en «Activar notificaciones»). Si muestras un botón de suscripción que no puede funcionar en una pestaña, estás rompiendo la experiencia.

Safari exige notificación visible: el service worker debe llamar a showNotification al recibir el evento push. Si no muestras una notificación, Safari puede revocar la suscripción. No uses push «silencioso» como mecanismo general de despertar en segundo plano.

Desde iOS/iPadOS 18.4+, WebKit documenta Declarative Web Push: un formato de mensaje que el navegador puede mostrar aunque falle el manejador del service worker (o sin depender tanto de él). Es una opción a evaluar cuando quieras más resiliencia en Safari; sigue siendo compatible con el flujo Web Push estándar en otros navegadores si diseñas con feature detection.

Fuentes:

9. Nativa, Capacitor, Cordova, React Native y Flutter

Una app multiplataforma no elimina las diferencias de push entre sistemas. Normalmente ofrece una API o plugin común que conecta el código compartido con SDKs nativos. El plugin simplifica el trabajo, pero las credenciales, capacidades, permisos, entitlements y restricciones del sistema operativo siguen existiendo.

Tecnología	Cómo suele implementar push	Consideraciones
Nativa Android	SDK de FCM y APIs de Android	Token FCM, permisos, canales y callbacks nativos
Nativa iOS	APNs y UserNotifications; opcionalmente FCM como capa común	Capability, entitlements, APNs token y autorización
Web/PWA	Push API, service worker y Web Push/VAPID o integración FCM web	Suscripción, permisos, compatibilidad del navegador y contexto de instalación
Capacitor	Plugin que puentea JavaScript con capacidades nativas	Android utiliza FCM; iOS requiere configuración de Push Notifications/APNs
Cordova	Plugin nativo, por ejemplo un plugin que integra Firebase	El estado y mantenimiento del plugin importan; hay que revisar compatibilidad con versiones actuales
React Native	Librerías comunitarias que integran FCM/APNs y módulos nativos	La API de React Native no elimina la configuración nativa; elegir librerías mantenidas
Flutter	Plugins como Firebase Messaging que conectan Dart con SDKs nativos	Configuración de Firebase, APNs y permisos según plataforma

Capacitor

El plugin oficial @capacitor/push-notifications ofrece una API para registrar el dispositivo, recibir eventos y manejar interacciones. Su documentación indica que Android utiliza Firebase Cloud Messaging y que en iOS se debe habilitar la capacidad Push Notifications y configurar el puente nativo requerido.

Fuente: Capacitor — Push Notifications

Cordova

Cordova depende de plugins para exponer APIs nativas a JavaScript. No basta con instalar cualquier plugin de push: revisa actividad reciente, soporte para las versiones actuales de Android/iOS, requisitos de Xcode, configuración de Firebase y compatibilidad con tu versión de Cordova. Un plugin abandonado puede bloquear una actualización de sistema operativo.

React Native

La antigua API PushNotificationIOS del propio React Native está marcada como obsoleta; la documentación recomienda usar paquetes comunitarios. Una opción común es React Native Firebase Messaging, pero hay que revisar la compatibilidad con la versión de React Native y las instrucciones de configuración nativa.

Flutter

Flutter utiliza plugins que conectan el código Dart con SDKs nativos. Firebase Messaging es una opción frecuente para FCM y los flujos de notificaciones en iOS/Android. Sigue siendo necesario configurar los proyectos nativos, permisos, credenciales y comportamiento en foreground/background.

Fuente: Firebase — Flutter Cloud Messaging

La diferencia real

El framework cambia cómo escribes el código cliente y cómo configuras el puente nativo. No cambia las reglas fundamentales de entrega: necesitas registrar cada instalación, guardar su destino, solicitar permisos y manejar los estados de la app.

10. ¿Qué partes tiene una notificación?

Una notificación puede combinar información visible y datos que la app procesa.

Contenido visible

Título.
Texto o cuerpo.
Icono o imagen, según la plataforma.
Sonido.
Badge o contador.
Prioridad o nivel de interrupción.
Categoría/canal.
Acciones, según las capacidades de la plataforma.

Datos personalizados

{
  "type": "chat.message",
  "conversationId": "conv_123",
  "messageId": "msg_456",
  "route": "/chat/conv_123"
}

Este objeto representa datos para que la aplicación sepa qué recurso abrir. No conviene incluir información privada innecesaria en el payload: la pantalla puede recuperar el contenido completo desde tu API después de autenticar al usuario.

FCM distingue entre mensajes de notificación y mensajes de datos. El comportamiento cambia según Android/iOS, foreground/background y la implementación del cliente. No asumas que un payload data siempre se ejecutará de inmediato si la app está suspendida.

Fuente: Firebase — Message types

No uses el push como fuente de verdad

Un push puede retrasarse, agruparse, expirar o no mostrarse. La base de datos y la API siguen siendo la fuente de verdad. El mensaje debe funcionar como una señal: «hay algo que consultar», no como la única copia de un evento crítico.

11. Acciones: qué pasa cuando el usuario toca una notificación

Una notificación puede tener una acción predeterminada (abrir la app) o botones específicos, por ejemplo:

Abrir conversación.
Marcar como leído.
Aceptar o rechazar una invitación.
Responder rápidamente.
Abrir una orden o una reserva.
Descartar o posponer un recordatorio.

El sistema operativo permite definir categorías o acciones, pero el soporte y la experiencia dependen de la plataforma y del framework. Algunas acciones pueden ejecutarse sin abrir la interfaz completa; otras abren la app para completar la operación.

Deep links

El payload puede incluir un identificador o una ruta lógica, por ejemplo conversationId. Cuando el usuario toca la notificación:

El sistema abre o trae la app al frente.
El plugin entrega el evento de interacción.
La app obtiene el destino y valida el estado de autenticación.
La app navega a la pantalla correspondiente.
La pantalla carga los datos actuales desde la API.

No confíes en una ruta recibida como si fuera una autorización. El backend debe validar que el usuario puede acceder al recurso. Si el usuario cerró sesión, muestra el flujo de autenticación y reanuda la navegación solo después de validar permisos.

Foreground, background y terminated

Hay al menos tres estados que debes probar:

Foreground: la app está visible. El sistema puede no mostrar automáticamente un banner; la app puede decidir mostrar UI propia o presentar la notificación.
Background: la app no está visible, pero el sistema puede gestionar el mensaje y mostrarlo.
Terminated: el proceso no está activo. Al tocar la notificación, la app se inicia y debe recuperar la notificación inicial o el intent de lanzamiento según el framework.

El comportamiento de mensajes silenciosos o de datos en background está sujeto a restricciones del sistema operativo y no debe tratarse como ejecución garantizada.

12. ¿Qué servicios de nube puedo usar?

Hay dos categorías diferentes: proveedores que entregan push a dispositivos y servicios de mensajería que conectan componentes de tu backend.

Proveedores push

Servicio	Qué aporta	Cuándo considerarlo
Firebase Cloud Messaging (FCM)	Envío a tokens, topics y condiciones; integración Android y web, y capa de integración con APNs para iOS	Buen punto de partida multiplataforma
Apple APNs	Entrega remota nativa en plataformas Apple	Necesario en la ruta nativa de iOS, directamente o detrás de un proveedor
Amazon SNS Mobile Push	Abstracción de endpoint de plataforma y envío a FCM/APNs y otros servicios soportados	Si la infraestructura ya vive en AWS o se requiere segmentación por topics de SNS
Azure Notification Hubs	Gestión de instalaciones/tags y envíos cross-platform a PNS	Si ya se utiliza Azure o se necesita segmentación y administración de dispositivos
OneSignal	Plataforma administrada con segmentación, campañas, analítica e integración con proveedores de plataforma	Si se necesita más que una API de envío, como campañas y gestión de audiencias
Expo Push Service	Capa de envío para aplicaciones Expo/React Native según su configuración	Si el proyecto usa Expo y el servicio cubre sus requisitos

Servicios de mensajería para el backend

Servicio	Papel	No confundir con
Google Cloud Pub/Sub	Eventos asíncronos entre servicios y workers	No es por sí solo el servicio de push al móvil
AWS SNS	Puede distribuir mensajes a endpoints y también integra mobile push	No es lo mismo que SQS
AWS SQS	Cola de trabajos para procesar envíos de forma asíncrona	No entrega directamente una notificación al sistema operativo
Azure Service Bus	Colas y topics para comunicación backend	No sustituye a APNs/FCM
RabbitMQ / Kafka	Eventos o colas dentro de tu arquitectura	Requieren un worker que resuelva destinatarios y llame al proveedor push
Cloud Tasks	Ejecución asíncrona y controlada de tareas HTTP	No es el proveedor que entrega el push al teléfono

Google Cloud Pub/Sub separa productores y consumidores y está orientado a comunicación entre servicios. FCM, en cambio, proporciona destinos para aplicaciones cliente. Se pueden usar juntos: Pub/Sub recibe eventos de negocio y un worker consume esos eventos, resuelve usuarios y tokens y llama a FCM/APNs.

Arquitectura cloud sugerida

API de negocio
   |
   v
Evento: order.shipped
   |
   v
Cola o topic backend (opcional)
   |
   v
Worker de notificaciones
   |
   +--> Consulta preferencias y usuarios
   +--> Resuelve instalaciones activas
   +--> Construye payload por plataforma
   +--> Envía a FCM / APNs / Web Push
   +--> Guarda resultado y reintentos

No necesitas un broker desde el primer día. Una aplicación pequeña puede enviar directamente desde un servicio backend con una cola persistente para reintentos si la fiabilidad lo exige. Un broker se vuelve útil cuando quieres desacoplar eventos, absorber picos, reintentar y escalar workers de forma independiente.

13. ¿Qué significa «enviado», «entregado» y «visto»?

No son el mismo estado.

Aceptado por el proveedor: la API aceptó la solicitud; no significa que el teléfono ya la mostró.
Entregado al dispositivo o transporte: puede haber señales o métricas disponibles, pero no siempre existe confirmación exacta para cada plataforma y tipo de mensaje.
Mostrado por el sistema: el SO presentó la notificación, si el mensaje y los permisos lo permitieron.
Abierto por el usuario: la persona tocó la notificación o ejecutó una acción.
Procesado por la app: la aplicación completó una operación, como marcar el mensaje como leído.

FCM ofrece métricas de entrega agregadas para determinados escenarios y Android; no todas las rutas proporcionan una confirmación individual idéntica. APNs puede aceptar una petición sin que eso garantice que el usuario haya visto la notificación.

Para eventos importantes, registra tus propios estados de negocio y las interacciones que el cliente pueda confirmar. No prometas «entrega exactamente una vez» basándote solo en la API push.

Fuente: Firebase — Understanding message delivery

14. Reintentos, duplicados, expiración y orden

La entrega push es asíncrona y está sujeta a redes, políticas del sistema y estados del dispositivo. Diseña el backend asumiendo que puede haber retrasos, mensajes obsoletos o reintentos.

Buenas prácticas:

Asignar un notification_id o event_id único.
Hacer idempotente el procesamiento de acciones.
Definir TTL para que una notificación antigua no aparezca después de perder sentido.
Usar collapse keys o mecanismos equivalentes solo cuando sea apropiado agrupar mensajes reemplazables.
Retirar tokens inválidos.
No reintentar indefinidamente errores permanentes.
Registrar códigos de respuesta y causa de fallo.
Mantener una bandeja de notificaciones en backend si la experiencia requiere historial fiable.
Al abrir la app, sincronizar el estado real desde la API.

Por ejemplo, si un usuario recibe diez actualizaciones de «pedido en preparación», quizá baste con mostrar el estado más reciente. En cambio, no conviene colapsar diez eventos financieros que el producto necesita registrar individualmente.

15. Seguridad y privacidad

Los tokens y las suscripciones son identificadores sensibles desde el punto de vista operativo. No los expongas en logs públicos ni los aceptes sin validación.

Guarda las credenciales de servidor de FCM, claves privadas VAPID y credenciales de APNs solo en backend o un gestor de secretos.
Nunca incluyas credenciales privadas en el frontend, APK o bundle de JavaScript.
Registra tokens a través de una sesión autenticada y verifica a qué cuenta pertenecen.
Desasocia instalaciones al cerrar sesión cuando sea necesario para la política de privacidad.
Evita enviar secretos, datos financieros o contenido privado completo en payloads visibles.
Valida permisos al abrir un deep link.
Permite desactivar notificaciones por categoría y respeta las preferencias del usuario.
Elimina destinos inválidos y establece una política de retención de registros.

El cifrado de transporte y del payload Web Push no sustituye la autorización del recurso al que la notificación invita a navegar.

16. Errores frecuentes

Guardar un solo token por usuario. Una cuenta puede tener múltiples instalaciones.
Intentar Web Push en una pestaña de Safari iOS. En iPhone/iPad hace falta la web app en la pantalla de inicio; pide el permiso solo ahí, tras un gesto.
Confundir VAPID con FCM o APNs. VAPID pertenece al flujo Web Push; no reemplaza las credenciales nativas de APNs.
Pensar que un topic de Pub/Sub es un topic de FCM. Uno conecta servicios backend; el otro dirige mensajes a una audiencia de apps registradas.
Creer que HTTP 200 significa que el usuario vio la notificación. Normalmente solo indica aceptación de la solicitud en esa etapa.
Enviar datos privados a topics amplios. Los topics son para audiencias, no para información individual confidencial.
No actualizar tokens. Las instalaciones cambian y los tokens pueden invalidarse.
Probar solo con la app abierta. Foreground, background y terminated se comportan de forma distinta.
Suponer que un plugin multiplataforma elimina la configuración nativa. Los certificados, capabilities, permisos y SDKs siguen existiendo.
Usar push como almacenamiento fiable. La fuente de verdad debe estar en el backend.
No manejar el tap/deep link. La notificación aparece, pero la app no sabe a qué pantalla navegar.
Omitir showNotification en Safari. Si el service worker no muestra una notificación visible, la suscripción puede revocarse.

17. Recomendación de arquitectura

Para una aplicación multiplataforma nueva, una arquitectura inicial razonable podría ser:

Un servicio backend de notificaciones desacoplado de la lógica de negocio.
Una tabla de instalaciones/destinos, con múltiples registros por usuario.
FCM como punto de partida para Android y, si conviene, como capa de envío unificada; configuración de APNs para iOS.
Web Push con service worker y VAPID para una PWA, o Firebase Messaging Web si sus características encajan.
Un adaptador por proveedor (FCM, APNs, WebPush) detrás de una interfaz propia si se necesita cambiar o combinar proveedores.
Una cola como SQS, Pub/Sub o Service Bus cuando se necesiten reintentos, absorción de picos o procesamiento independiente.
Payloads pequeños con IDs de recursos y rutas lógicas.
Deep links validados por la aplicación y autorización en backend.
Métricas de aceptación, fallos, tokens inválidos y aperturas.
Tests para foreground, background, terminated, permisos denegados y tokens rotados.

No empieces construyendo una abstracción enorme que soporte diez proveedores si solo necesitas uno. Encapsula lo que de verdad varía: registro de destinos, envío, errores, TTL, datos por plataforma y telemetría.

Conclusión

Una notificación push no es una conexión directa del backend al teléfono. Es un mensaje enrutado por una infraestructura que conoce el destino registrado de una aplicación o suscripción.

Para que llegue a un solo dispositivo, el backend envía al token o endpoint específico de esa instalación. Para que llegue a todos los dispositivos de una persona, mantiene la relación entre usuario e instalaciones y envía a cada destino activo. Para una audiencia amplia, puede utilizar topics del proveedor o resolver un segmento en su propio backend.

VAPID identifica al servidor en Web Push; FCM ofrece una capa de mensajería para aplicaciones; APNs administra la entrega remota de Apple; y frameworks como Capacitor, Cordova, React Native y Flutter simplifican el código cliente sin eliminar las reglas nativas.

Tu backend decide quién debe recibir el mensaje; el proveedor push enruta el mensaje; el sistema operativo decide cómo presentarlo; y la aplicación valida qué debe ocurrir cuando el usuario interactúa.

Lecturas relacionadas

Referencias

Apple y Web Push

Google y FCM

Frameworks y proveedores cloud

Las capacidades y APIs de push cambian según versión de sistema operativo, navegador, SDK y plugin. Antes de implementar, valida la documentación de la plataforma elegida. Los ejemplos de código de este artículo son ilustrativos y no incluyen un sistema completo de autenticación.

Índice

Arquitectura · 27 de octubre de 2026 · Daniel Murillo

Cómo funcionan las notificaciones push: VAPID, FCM, APNs y multiplataforma

Push no es una conexión directa al móvil. Tokens, topics, VAPID, FCM, APNs, Web Push y qué cambia con Capacitor, React Native o Flutter.

Una notificación push no se envía directamente desde tu backend al celular. Tu sistema identifica una instalación o una audiencia; un servicio de push de la plataforma enruta el mensaje al sistema operativo o al navegador, que decide cómo presentarlo y cuándo despertar la aplicación.

Introducción: parece un mensaje, pero es una cadena de sistemas

Cuando una aplicación muestra «Tienes un mensaje nuevo», puede parecer que el backend abrió una conexión con el teléfono y le envió un texto. En realidad, el mecanismo suele ser diferente.

Esto permite que el backend no tenga que mantener una conexión WebSocket propia con cada teléfono solo para notificarlo cuando está inactivo.

1. Push, notificación local y mensajería en tiempo real no son lo mismo

Antes de hablar de proveedores, conviene distinguir tres mecanismos.

Notificación local

Notificación push remota

Tu backend solicita al proveedor push que entregue un mensaje a una instalación o a una audiencia. El proveedor se encarga de la ruta hasta el dispositivo. Puede que la aplicación no esté abierta.

Mensajería en tiempo real

Una arquitectura puede combinar ambos mecanismos: WebSocket mientras la app está activa y push para avisar de eventos importantes cuando está en segundo plano.

2. La arquitectura general de una notificación push

Evento de negocio en el backend
              |
              v
   Servicio de notificaciones
              |
              v
     Resolver destinatarios
        |              |
        v              v
 Token / instalación   Topic / segmento
        |              |
        +------+-------+
               |
               v
      FCM / APNs / Web Push
               |
               v
  Sistema operativo o navegador
               |
               v
 Notificación visible / callback / service worker
               |
               v
  Deep link o navegación dentro de la app

Los componentes principales son:

Backend de negocio: detecta un evento, como un mensaje nuevo, una compra o un recordatorio.
Servicio de notificaciones: decide a quién notificar, construye el payload y aplica preferencias, prioridades y reglas.
Registro de instalaciones: relaciona cuentas de usuario con tokens o suscripciones de cada instalación.
Proveedor push: FCM, APNs, Web Push u otra capa que se integra con los servicios de plataforma.
Sistema operativo o navegador: recibe, presenta y enruta la interacción.
Aplicación: interpreta los datos y abre la pantalla adecuada cuando corresponde.

Fuente: Apple — Setting up a remote notification server

3. ¿Cómo se registra un dispositivo?

Para enviar un push dirigido, tu sistema necesita un identificador que el proveedor pueda enrutar.

Un flujo típico es:

El usuario instala o abre la aplicación, o entra a una web compatible.
La aplicación explica el valor de las notificaciones y solicita permiso cuando corresponda.
El SDK o la plataforma registra esa instalación con el proveedor.
El proveedor devuelve un token o una suscripción.
La aplicación envía ese identificador a tu backend autenticado.
Tu backend lo guarda y lo relaciona con el usuario, la plataforma y la instalación.
Cuando ocurre un evento, el backend consulta el registro y envía el push al destinatario correcto.

El token no es el ID del usuario

No diseñes la base de datos suponiendo que cada usuario tiene un único token. Una persona puede tener:

un iPhone y una tablet;
un teléfono personal y otro de trabajo;
una app instalada y una PWA suscrita;
varias instalaciones después de reinstalar;
sesiones de una misma cuenta en dispositivos distintos.

Por eso, una tabla de registro puede tener una fila por instalación o destino de push, no solo una columna push_token en users.

Campo	Para qué sirve
`id`	ID interno del registro
`user_id`	Cuenta a la que pertenece, si hay sesión
`platform`	`ios`, `android`, `web`
`provider`	`apns`, `fcm`, `webpush`, etc.
`token` o `subscription`	Dirección/token de push; proteger y limitar acceso
`installation_id`	ID interno de la instalación
`app_version`	Diagnóstico y compatibilidad
`last_seen_at`	Última actividad conocida
`enabled`	Preferencia o estado de registro
`created_at`, `updated_at`	Ciclo de vida del registro

En Web Push, la suscripción incluye endpoint y material criptográfico; no se debe tratar como si fuera exactamente el mismo tipo de token que FCM o APNs.

Los tokens cambian

4. ¿Cómo sabe el proveedor a qué dispositivo enviar la notificación?

Esta es la pregunta clave: ¿cómo es que una notificación le llega a un solo dispositivo y no a todos?

Porque el backend no envía simplemente «una notificación para la aplicación». Envía un mensaje con un destino concreto.

Envío directo a un token

Supongamos que una cuenta está conectada en tres instalaciones:

iPhone de la persona: token token-A
Android de la persona: token token-B
navegador del portátil: suscripción subscription-C

Si el backend envía el mensaje al token-A, el proveedor intenta entregarlo a esa instalación asociada con el token A. No lo enruta automáticamente al token B ni a la suscripción C.

El identificador no siempre representa un teléfono físico

Un token normalmente identifica un destino de aplicación o instalación en una plataforma, no necesariamente un hardware único. La semántica exacta depende del proveedor.

APNs: token asociado a la app y al dispositivo.
FCM: token de registro de una instancia de la app.
Web Push: suscripción de un service worker para un sitio/origen y navegador.
Un proveedor intermediario puede crear su propio ID de instalación o endpoint y mantener el token de plataforma detrás.

¿Y si el usuario tiene varias sesiones?

Define una política de producto:

enviar a todas las instalaciones activas;
enviar solo a la instalación que inició la acción;
excluir el dispositivo actual;
enviar a todos los dispositivos excepto los que ya recibieron o leyeron el evento;
agrupar o silenciar mensajes duplicados.

No es una decisión automática del sistema push. Es lógica de tu backend.

5. Topics, tokens y grupos: tres estrategias diferentes

La palabra topic se utiliza en varios sistemas y no siempre significa lo mismo.

Destinatario individual: token

Se utiliza cuando conoces exactamente la instalación a la que quieres enviar el mensaje.

Ejemplos:

«Tu pedido fue enviado» a las instalaciones de la cuenta.
«Tienes un mensaje nuevo» a un usuario concreto.
«Se inició sesión en tu cuenta» a sus dispositivos registrados.

Topic de FCM

Un topic de FCM es una audiencia a la que las instancias de la aplicación se suscriben. El backend publica en ese topic y FCM distribuye el mensaje a los registros suscritos.

Ejemplos: product_updates, team_42_announcements, weather_city_abc.

Fuente: Firebase — Topic messaging

Topic de un broker, como Google Cloud Pub/Sub

Un topic de Google Cloud Pub/Sub distribuye eventos entre servicios backend y suscripciones de procesamiento. No es lo mismo que un topic de FCM dirigido a instalaciones móviles.

Pedido actualizado
       |
       v
Google Cloud Pub/Sub: orders-events
       |
       v
Worker de notificaciones
       |
       +--> Busca al usuario y sus instalaciones
       |
       +--> Envía a FCM / APNs / Web Push

Topics propios en tu aplicación

6. VAPID: qué es y cuándo se utiliza

VAPID significa Voluntary Application Server Identification. Es un mecanismo de identificación/autenticación del servidor de aplicación en el protocolo Web Push.

Qué hace VAPID

Identifica al servidor de aplicación ante el servicio push.
Usa una clave pública que se proporciona al crear la suscripción.
Firma un token de autorización con la clave privada.
Ayuda al servicio push a relacionar una suscripción con el servidor autorizado para enviarle mensajes.

Qué no hace VAPID

No es el token del dispositivo.
No es el contenido de la notificación.
No es un topic.
No reemplaza el cifrado del payload Web Push.
No es la credencial que usa una app nativa para autenticar directamente contra APNs.
No es obligatorio para todas las rutas de notificaciones nativas con FCM/APNs.

En aplicaciones web, la clave pública VAPID se utiliza en el flujo de suscripción; la clave privada debe mantenerse en el backend y nunca incluirse en el frontend.

Apple documenta VAPID como parte de la preparación del servidor para Web Push. También especifica que se construye y cifra el payload y se envía a la URL de endpoint de la suscripción.

Fuente: Apple — Sending web push notifications

Flujo simplificado de Web Push

El usuario acepta notificaciones.
El navegador registra un service worker.
El navegador crea una PushSubscription, usando la clave pública VAPID cuando corresponda.
El frontend envía la suscripción al backend.
El backend almacena endpoint y claves de suscripción.
Cuando ocurre un evento, el backend cifra el payload y firma la solicitud con VAPID.
Envía la solicitud al endpoint del servicio push.
El navegador recibe el evento push en el service worker y puede mostrar una notificación.

const registration = await navigator.serviceWorker.register("/sw.js");

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: PUBLIC_VAPID_KEY,
});

await fetch("/api/push-subscriptions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(subscription),
});

La clave pública puede estar en el cliente; la privada nunca. El backend debe usar una biblioteca Web Push mantenida para cifrado, formato y firma, en lugar de implementar manualmente el protocolo.

7. Google FCM y Apple APNs: qué hace cada uno

Firebase Cloud Messaging (FCM)

FCM permite direccionar mensajes a:

un token de registro;
un topic;
una condición basada en topics.

El payload puede contener una sección notification, datos personalizados (data) o ambas. El comportamiento depende de la plataforma y del estado de la aplicación.

Fuente: Firebase — Send a message using FCM HTTP v1

Apple Push Notification service (APNs)

¿FCM reemplaza a APNs en iOS?

En otras palabras, FCM puede ser una capa común para tu backend, pero no elimina las reglas de Apple ni hace desaparecer APNs de la ruta de entrega en iOS.

8. ¿Qué ocurre en Android, iOS y navegadores?

Android nativo

Fuente: Android Developers — Notification runtime permission

iOS nativo

La app solicita autorización al usuario, se registra con APNs y recibe un device token. Ese token se envía al backend. El servidor envía el payload a APNs, que lo enruta al dispositivo.

Fuente: Apple — User Notifications

Web y PWA

La web usa la Push API y un service worker. La suscripción contiene un endpoint y claves criptográficas; el backend usa Web Push y VAPID para enviar el payload al servicio push del navegador.

Las posibilidades varían según navegador, sistema operativo, instalación de la PWA y permisos. No asumas el mismo comportamiento en Chrome para Android, Safari en macOS y Safari en iPhone.

Fuentes:

9. Nativa, Capacitor, Cordova, React Native y Flutter

Tecnología	Cómo suele implementar push	Consideraciones
Nativa Android	SDK de FCM y APIs de Android	Token FCM, permisos, canales y callbacks nativos
Nativa iOS	APNs y UserNotifications; opcionalmente FCM como capa común	Capability, entitlements, APNs token y autorización
Web/PWA	Push API, service worker y Web Push/VAPID o integración FCM web	Suscripción, permisos, compatibilidad del navegador y contexto de instalación
Capacitor	Plugin que puentea JavaScript con capacidades nativas	Android utiliza FCM; iOS requiere configuración de Push Notifications/APNs
Cordova	Plugin nativo, por ejemplo un plugin que integra Firebase	El estado y mantenimiento del plugin importan; hay que revisar compatibilidad con versiones actuales
React Native	Librerías comunitarias que integran FCM/APNs y módulos nativos	La API de React Native no elimina la configuración nativa; elegir librerías mantenidas
Flutter	Plugins como Firebase Messaging que conectan Dart con SDKs nativos	Configuración de Firebase, APNs y permisos según plataforma

Capacitor

Fuente: Capacitor — Push Notifications

Cordova

React Native

Flutter

Fuente: Firebase — Flutter Cloud Messaging

La diferencia real

10. ¿Qué partes tiene una notificación?

Una notificación puede combinar información visible y datos que la app procesa.

Contenido visible

Título.
Texto o cuerpo.
Icono o imagen, según la plataforma.
Sonido.
Badge o contador.
Prioridad o nivel de interrupción.
Categoría/canal.
Acciones, según las capacidades de la plataforma.

Datos personalizados

{
  "type": "chat.message",
  "conversationId": "conv_123",
  "messageId": "msg_456",
  "route": "/chat/conv_123"
}

Fuente: Firebase — Message types

No uses el push como fuente de verdad

11. Acciones: qué pasa cuando el usuario toca una notificación

Una notificación puede tener una acción predeterminada (abrir la app) o botones específicos, por ejemplo:

Abrir conversación.
Marcar como leído.
Aceptar o rechazar una invitación.
Responder rápidamente.
Abrir una orden o una reserva.
Descartar o posponer un recordatorio.

Deep links

El payload puede incluir un identificador o una ruta lógica, por ejemplo conversationId. Cuando el usuario toca la notificación:

El sistema abre o trae la app al frente.
El plugin entrega el evento de interacción.
La app obtiene el destino y valida el estado de autenticación.
La app navega a la pantalla correspondiente.
La pantalla carga los datos actuales desde la API.

Foreground, background y terminated

Hay al menos tres estados que debes probar:

Foreground: la app está visible. El sistema puede no mostrar automáticamente un banner; la app puede decidir mostrar UI propia o presentar la notificación.
Background: la app no está visible, pero el sistema puede gestionar el mensaje y mostrarlo.
Terminated: el proceso no está activo. Al tocar la notificación, la app se inicia y debe recuperar la notificación inicial o el intent de lanzamiento según el framework.

El comportamiento de mensajes silenciosos o de datos en background está sujeto a restricciones del sistema operativo y no debe tratarse como ejecución garantizada.

12. ¿Qué servicios de nube puedo usar?

Hay dos categorías diferentes: proveedores que entregan push a dispositivos y servicios de mensajería que conectan componentes de tu backend.

Proveedores push

Servicio	Qué aporta	Cuándo considerarlo
Firebase Cloud Messaging (FCM)	Envío a tokens, topics y condiciones; integración Android y web, y capa de integración con APNs para iOS	Buen punto de partida multiplataforma
Apple APNs	Entrega remota nativa en plataformas Apple	Necesario en la ruta nativa de iOS, directamente o detrás de un proveedor
Amazon SNS Mobile Push	Abstracción de endpoint de plataforma y envío a FCM/APNs y otros servicios soportados	Si la infraestructura ya vive en AWS o se requiere segmentación por topics de SNS
Azure Notification Hubs	Gestión de instalaciones/tags y envíos cross-platform a PNS	Si ya se utiliza Azure o se necesita segmentación y administración de dispositivos
OneSignal	Plataforma administrada con segmentación, campañas, analítica e integración con proveedores de plataforma	Si se necesita más que una API de envío, como campañas y gestión de audiencias
Expo Push Service	Capa de envío para aplicaciones Expo/React Native según su configuración	Si el proyecto usa Expo y el servicio cubre sus requisitos

Servicios de mensajería para el backend

Servicio	Papel	No confundir con
Google Cloud Pub/Sub	Eventos asíncronos entre servicios y workers	No es por sí solo el servicio de push al móvil
AWS SNS	Puede distribuir mensajes a endpoints y también integra mobile push	No es lo mismo que SQS
AWS SQS	Cola de trabajos para procesar envíos de forma asíncrona	No entrega directamente una notificación al sistema operativo
Azure Service Bus	Colas y topics para comunicación backend	No sustituye a APNs/FCM
RabbitMQ / Kafka	Eventos o colas dentro de tu arquitectura	Requieren un worker que resuelva destinatarios y llame al proveedor push
Cloud Tasks	Ejecución asíncrona y controlada de tareas HTTP	No es el proveedor que entrega el push al teléfono

Arquitectura cloud sugerida

API de negocio
   |
   v
Evento: order.shipped
   |
   v
Cola o topic backend (opcional)
   |
   v
Worker de notificaciones
   |
   +--> Consulta preferencias y usuarios
   +--> Resuelve instalaciones activas
   +--> Construye payload por plataforma
   +--> Envía a FCM / APNs / Web Push
   +--> Guarda resultado y reintentos

13. ¿Qué significa «enviado», «entregado» y «visto»?

No son el mismo estado.

Aceptado por el proveedor: la API aceptó la solicitud; no significa que el teléfono ya la mostró.
Entregado al dispositivo o transporte: puede haber señales o métricas disponibles, pero no siempre existe confirmación exacta para cada plataforma y tipo de mensaje.
Mostrado por el sistema: el SO presentó la notificación, si el mensaje y los permisos lo permitieron.
Abierto por el usuario: la persona tocó la notificación o ejecutó una acción.
Procesado por la app: la aplicación completó una operación, como marcar el mensaje como leído.

Para eventos importantes, registra tus propios estados de negocio y las interacciones que el cliente pueda confirmar. No prometas «entrega exactamente una vez» basándote solo en la API push.

Fuente: Firebase — Understanding message delivery

14. Reintentos, duplicados, expiración y orden

La entrega push es asíncrona y está sujeta a redes, políticas del sistema y estados del dispositivo. Diseña el backend asumiendo que puede haber retrasos, mensajes obsoletos o reintentos.

Buenas prácticas:

Asignar un notification_id o event_id único.
Hacer idempotente el procesamiento de acciones.
Definir TTL para que una notificación antigua no aparezca después de perder sentido.
Usar collapse keys o mecanismos equivalentes solo cuando sea apropiado agrupar mensajes reemplazables.
Retirar tokens inválidos.
No reintentar indefinidamente errores permanentes.
Registrar códigos de respuesta y causa de fallo.
Mantener una bandeja de notificaciones en backend si la experiencia requiere historial fiable.
Al abrir la app, sincronizar el estado real desde la API.

15. Seguridad y privacidad

Los tokens y las suscripciones son identificadores sensibles desde el punto de vista operativo. No los expongas en logs públicos ni los aceptes sin validación.

Guarda las credenciales de servidor de FCM, claves privadas VAPID y credenciales de APNs solo en backend o un gestor de secretos.
Nunca incluyas credenciales privadas en el frontend, APK o bundle de JavaScript.
Registra tokens a través de una sesión autenticada y verifica a qué cuenta pertenecen.
Desasocia instalaciones al cerrar sesión cuando sea necesario para la política de privacidad.
Evita enviar secretos, datos financieros o contenido privado completo en payloads visibles.
Valida permisos al abrir un deep link.
Permite desactivar notificaciones por categoría y respeta las preferencias del usuario.
Elimina destinos inválidos y establece una política de retención de registros.

El cifrado de transporte y del payload Web Push no sustituye la autorización del recurso al que la notificación invita a navegar.

16. Errores frecuentes

Guardar un solo token por usuario. Una cuenta puede tener múltiples instalaciones.
Intentar Web Push en una pestaña de Safari iOS. En iPhone/iPad hace falta la web app en la pantalla de inicio; pide el permiso solo ahí, tras un gesto.
Confundir VAPID con FCM o APNs. VAPID pertenece al flujo Web Push; no reemplaza las credenciales nativas de APNs.
Pensar que un topic de Pub/Sub es un topic de FCM. Uno conecta servicios backend; el otro dirige mensajes a una audiencia de apps registradas.
Creer que HTTP 200 significa que el usuario vio la notificación. Normalmente solo indica aceptación de la solicitud en esa etapa.
Enviar datos privados a topics amplios. Los topics son para audiencias, no para información individual confidencial.
No actualizar tokens. Las instalaciones cambian y los tokens pueden invalidarse.
Probar solo con la app abierta. Foreground, background y terminated se comportan de forma distinta.
Suponer que un plugin multiplataforma elimina la configuración nativa. Los certificados, capabilities, permisos y SDKs siguen existiendo.
Usar push como almacenamiento fiable. La fuente de verdad debe estar en el backend.
No manejar el tap/deep link. La notificación aparece, pero la app no sabe a qué pantalla navegar.
Omitir showNotification en Safari. Si el service worker no muestra una notificación visible, la suscripción puede revocarse.

17. Recomendación de arquitectura

Para una aplicación multiplataforma nueva, una arquitectura inicial razonable podría ser:

Un servicio backend de notificaciones desacoplado de la lógica de negocio.
Una tabla de instalaciones/destinos, con múltiples registros por usuario.
FCM como punto de partida para Android y, si conviene, como capa de envío unificada; configuración de APNs para iOS.
Web Push con service worker y VAPID para una PWA, o Firebase Messaging Web si sus características encajan.
Un adaptador por proveedor (FCM, APNs, WebPush) detrás de una interfaz propia si se necesita cambiar o combinar proveedores.
Una cola como SQS, Pub/Sub o Service Bus cuando se necesiten reintentos, absorción de picos o procesamiento independiente.
Payloads pequeños con IDs de recursos y rutas lógicas.
Deep links validados por la aplicación y autorización en backend.
Métricas de aceptación, fallos, tokens inválidos y aperturas.
Tests para foreground, background, terminated, permisos denegados y tokens rotados.

Conclusión

Una notificación push no es una conexión directa del backend al teléfono. Es un mensaje enrutado por una infraestructura que conoce el destino registrado de una aplicación o suscripción.

Lecturas relacionadas

Referencias

Apple y Web Push

Google y FCM

Frameworks y proveedores cloud

Índice

Arquitectura · 27 de octubre de 2026 · Daniel Murillo

Cómo funcionan las notificaciones push: VAPID, FCM, APNs y multiplataforma

Push no es una conexión directa al móvil. Tokens, topics, VAPID, FCM, APNs, Web Push y qué cambia con Capacitor, React Native o Flutter.

Una notificación push no se envía directamente desde tu backend al celular. Tu sistema identifica una instalación o una audiencia; un servicio de push de la plataforma enruta el mensaje al sistema operativo o al navegador, que decide cómo presentarlo y cuándo despertar la aplicación.

Introducción: parece un mensaje, pero es una cadena de sistemas

Cuando una aplicación muestra «Tienes un mensaje nuevo», puede parecer que el backend abrió una conexión con el teléfono y le envió un texto. En realidad, el mecanismo suele ser diferente.

Esto permite que el backend no tenga que mantener una conexión WebSocket propia con cada teléfono solo para notificarlo cuando está inactivo.

1. Push, notificación local y mensajería en tiempo real no son lo mismo

Antes de hablar de proveedores, conviene distinguir tres mecanismos.

Notificación local

Notificación push remota

Tu backend solicita al proveedor push que entregue un mensaje a una instalación o a una audiencia. El proveedor se encarga de la ruta hasta el dispositivo. Puede que la aplicación no esté abierta.

Mensajería en tiempo real

Una arquitectura puede combinar ambos mecanismos: WebSocket mientras la app está activa y push para avisar de eventos importantes cuando está en segundo plano.

2. La arquitectura general de una notificación push

Evento de negocio en el backend
              |
              v
   Servicio de notificaciones
              |
              v
     Resolver destinatarios
        |              |
        v              v
 Token / instalación   Topic / segmento
        |              |
        +------+-------+
               |
               v
      FCM / APNs / Web Push
               |
               v
  Sistema operativo o navegador
               |
               v
 Notificación visible / callback / service worker
               |
               v
  Deep link o navegación dentro de la app

Los componentes principales son:

Backend de negocio: detecta un evento, como un mensaje nuevo, una compra o un recordatorio.
Servicio de notificaciones: decide a quién notificar, construye el payload y aplica preferencias, prioridades y reglas.
Registro de instalaciones: relaciona cuentas de usuario con tokens o suscripciones de cada instalación.
Proveedor push: FCM, APNs, Web Push u otra capa que se integra con los servicios de plataforma.
Sistema operativo o navegador: recibe, presenta y enruta la interacción.
Aplicación: interpreta los datos y abre la pantalla adecuada cuando corresponde.

Fuente: Apple — Setting up a remote notification server

3. ¿Cómo se registra un dispositivo?

Para enviar un push dirigido, tu sistema necesita un identificador que el proveedor pueda enrutar.

Un flujo típico es:

El usuario instala o abre la aplicación, o entra a una web compatible.
La aplicación explica el valor de las notificaciones y solicita permiso cuando corresponda.
El SDK o la plataforma registra esa instalación con el proveedor.
El proveedor devuelve un token o una suscripción.
La aplicación envía ese identificador a tu backend autenticado.
Tu backend lo guarda y lo relaciona con el usuario, la plataforma y la instalación.
Cuando ocurre un evento, el backend consulta el registro y envía el push al destinatario correcto.

El token no es el ID del usuario

No diseñes la base de datos suponiendo que cada usuario tiene un único token. Una persona puede tener:

un iPhone y una tablet;
un teléfono personal y otro de trabajo;
una app instalada y una PWA suscrita;
varias instalaciones después de reinstalar;
sesiones de una misma cuenta en dispositivos distintos.

Por eso, una tabla de registro puede tener una fila por instalación o destino de push, no solo una columna push_token en users.

Campo	Para qué sirve
`id`	ID interno del registro
`user_id`	Cuenta a la que pertenece, si hay sesión
`platform`	`ios`, `android`, `web`
`provider`	`apns`, `fcm`, `webpush`, etc.
`token` o `subscription`	Dirección/token de push; proteger y limitar acceso
`installation_id`	ID interno de la instalación
`app_version`	Diagnóstico y compatibilidad
`last_seen_at`	Última actividad conocida
`enabled`	Preferencia o estado de registro
`created_at`, `updated_at`	Ciclo de vida del registro

En Web Push, la suscripción incluye endpoint y material criptográfico; no se debe tratar como si fuera exactamente el mismo tipo de token que FCM o APNs.

Los tokens cambian

4. ¿Cómo sabe el proveedor a qué dispositivo enviar la notificación?

Esta es la pregunta clave: ¿cómo es que una notificación le llega a un solo dispositivo y no a todos?

Porque el backend no envía simplemente «una notificación para la aplicación». Envía un mensaje con un destino concreto.

Envío directo a un token

Supongamos que una cuenta está conectada en tres instalaciones:

iPhone de la persona: token token-A
Android de la persona: token token-B
navegador del portátil: suscripción subscription-C

Si el backend envía el mensaje al token-A, el proveedor intenta entregarlo a esa instalación asociada con el token A. No lo enruta automáticamente al token B ni a la suscripción C.

El identificador no siempre representa un teléfono físico

Un token normalmente identifica un destino de aplicación o instalación en una plataforma, no necesariamente un hardware único. La semántica exacta depende del proveedor.

APNs: token asociado a la app y al dispositivo.
FCM: token de registro de una instancia de la app.
Web Push: suscripción de un service worker para un sitio/origen y navegador.
Un proveedor intermediario puede crear su propio ID de instalación o endpoint y mantener el token de plataforma detrás.

¿Y si el usuario tiene varias sesiones?

Define una política de producto:

enviar a todas las instalaciones activas;
enviar solo a la instalación que inició la acción;
excluir el dispositivo actual;
enviar a todos los dispositivos excepto los que ya recibieron o leyeron el evento;
agrupar o silenciar mensajes duplicados.

No es una decisión automática del sistema push. Es lógica de tu backend.

5. Topics, tokens y grupos: tres estrategias diferentes

La palabra topic se utiliza en varios sistemas y no siempre significa lo mismo.

Destinatario individual: token

Se utiliza cuando conoces exactamente la instalación a la que quieres enviar el mensaje.

Ejemplos:

«Tu pedido fue enviado» a las instalaciones de la cuenta.
«Tienes un mensaje nuevo» a un usuario concreto.
«Se inició sesión en tu cuenta» a sus dispositivos registrados.

Topic de FCM

Un topic de FCM es una audiencia a la que las instancias de la aplicación se suscriben. El backend publica en ese topic y FCM distribuye el mensaje a los registros suscritos.

Ejemplos: product_updates, team_42_announcements, weather_city_abc.

Fuente: Firebase — Topic messaging

Topic de un broker, como Google Cloud Pub/Sub

Un topic de Google Cloud Pub/Sub distribuye eventos entre servicios backend y suscripciones de procesamiento. No es lo mismo que un topic de FCM dirigido a instalaciones móviles.

Pedido actualizado
       |
       v
Google Cloud Pub/Sub: orders-events
       |
       v
Worker de notificaciones
       |
       +--> Busca al usuario y sus instalaciones
       |
       +--> Envía a FCM / APNs / Web Push

Topics propios en tu aplicación

6. VAPID: qué es y cuándo se utiliza

VAPID significa Voluntary Application Server Identification. Es un mecanismo de identificación/autenticación del servidor de aplicación en el protocolo Web Push.

Qué hace VAPID

Identifica al servidor de aplicación ante el servicio push.
Usa una clave pública que se proporciona al crear la suscripción.
Firma un token de autorización con la clave privada.
Ayuda al servicio push a relacionar una suscripción con el servidor autorizado para enviarle mensajes.

Qué no hace VAPID

No es el token del dispositivo.
No es el contenido de la notificación.
No es un topic.
No reemplaza el cifrado del payload Web Push.
No es la credencial que usa una app nativa para autenticar directamente contra APNs.
No es obligatorio para todas las rutas de notificaciones nativas con FCM/APNs.

En aplicaciones web, la clave pública VAPID se utiliza en el flujo de suscripción; la clave privada debe mantenerse en el backend y nunca incluirse en el frontend.

Apple documenta VAPID como parte de la preparación del servidor para Web Push. También especifica que se construye y cifra el payload y se envía a la URL de endpoint de la suscripción.

Fuente: Apple — Sending web push notifications

Flujo simplificado de Web Push

El usuario acepta notificaciones.
El navegador registra un service worker.
El navegador crea una PushSubscription, usando la clave pública VAPID cuando corresponda.
El frontend envía la suscripción al backend.
El backend almacena endpoint y claves de suscripción.
Cuando ocurre un evento, el backend cifra el payload y firma la solicitud con VAPID.
Envía la solicitud al endpoint del servicio push.
El navegador recibe el evento push en el service worker y puede mostrar una notificación.

const registration = await navigator.serviceWorker.register("/sw.js");

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: PUBLIC_VAPID_KEY,
});

await fetch("/api/push-subscriptions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(subscription),
});

La clave pública puede estar en el cliente; la privada nunca. El backend debe usar una biblioteca Web Push mantenida para cifrado, formato y firma, en lugar de implementar manualmente el protocolo.

7. Google FCM y Apple APNs: qué hace cada uno

Firebase Cloud Messaging (FCM)

FCM permite direccionar mensajes a:

un token de registro;
un topic;
una condición basada en topics.

El payload puede contener una sección notification, datos personalizados (data) o ambas. El comportamiento depende de la plataforma y del estado de la aplicación.

Fuente: Firebase — Send a message using FCM HTTP v1

Apple Push Notification service (APNs)

¿FCM reemplaza a APNs en iOS?

En otras palabras, FCM puede ser una capa común para tu backend, pero no elimina las reglas de Apple ni hace desaparecer APNs de la ruta de entrega en iOS.

8. ¿Qué ocurre en Android, iOS y navegadores?

Android nativo

Fuente: Android Developers — Notification runtime permission

iOS nativo

La app solicita autorización al usuario, se registra con APNs y recibe un device token. Ese token se envía al backend. El servidor envía el payload a APNs, que lo enruta al dispositivo.

Fuente: Apple — User Notifications

Web y PWA

La web usa la Push API y un service worker. La suscripción contiene un endpoint y claves criptográficas; el backend usa Web Push y VAPID para enviar el payload al servicio push del navegador.

Las posibilidades varían según navegador, sistema operativo, instalación de la PWA y permisos. No asumas el mismo comportamiento en Chrome para Android, Safari en macOS y Safari en iPhone.

Fuentes:

9. Nativa, Capacitor, Cordova, React Native y Flutter

Tecnología	Cómo suele implementar push	Consideraciones
Nativa Android	SDK de FCM y APIs de Android	Token FCM, permisos, canales y callbacks nativos
Nativa iOS	APNs y UserNotifications; opcionalmente FCM como capa común	Capability, entitlements, APNs token y autorización
Web/PWA	Push API, service worker y Web Push/VAPID o integración FCM web	Suscripción, permisos, compatibilidad del navegador y contexto de instalación
Capacitor	Plugin que puentea JavaScript con capacidades nativas	Android utiliza FCM; iOS requiere configuración de Push Notifications/APNs
Cordova	Plugin nativo, por ejemplo un plugin que integra Firebase	El estado y mantenimiento del plugin importan; hay que revisar compatibilidad con versiones actuales
React Native	Librerías comunitarias que integran FCM/APNs y módulos nativos	La API de React Native no elimina la configuración nativa; elegir librerías mantenidas
Flutter	Plugins como Firebase Messaging que conectan Dart con SDKs nativos	Configuración de Firebase, APNs y permisos según plataforma

Capacitor

Fuente: Capacitor — Push Notifications

Cordova

React Native

Flutter

Fuente: Firebase — Flutter Cloud Messaging

La diferencia real

10. ¿Qué partes tiene una notificación?

Una notificación puede combinar información visible y datos que la app procesa.

Contenido visible

Título.
Texto o cuerpo.
Icono o imagen, según la plataforma.
Sonido.
Badge o contador.
Prioridad o nivel de interrupción.
Categoría/canal.
Acciones, según las capacidades de la plataforma.

Datos personalizados

{
  "type": "chat.message",
  "conversationId": "conv_123",
  "messageId": "msg_456",
  "route": "/chat/conv_123"
}

Fuente: Firebase — Message types

No uses el push como fuente de verdad

11. Acciones: qué pasa cuando el usuario toca una notificación

Una notificación puede tener una acción predeterminada (abrir la app) o botones específicos, por ejemplo:

Abrir conversación.
Marcar como leído.
Aceptar o rechazar una invitación.
Responder rápidamente.
Abrir una orden o una reserva.
Descartar o posponer un recordatorio.

Deep links

El payload puede incluir un identificador o una ruta lógica, por ejemplo conversationId. Cuando el usuario toca la notificación:

El sistema abre o trae la app al frente.
El plugin entrega el evento de interacción.
La app obtiene el destino y valida el estado de autenticación.
La app navega a la pantalla correspondiente.
La pantalla carga los datos actuales desde la API.

Foreground, background y terminated

Hay al menos tres estados que debes probar:

Foreground: la app está visible. El sistema puede no mostrar automáticamente un banner; la app puede decidir mostrar UI propia o presentar la notificación.
Background: la app no está visible, pero el sistema puede gestionar el mensaje y mostrarlo.
Terminated: el proceso no está activo. Al tocar la notificación, la app se inicia y debe recuperar la notificación inicial o el intent de lanzamiento según el framework.

El comportamiento de mensajes silenciosos o de datos en background está sujeto a restricciones del sistema operativo y no debe tratarse como ejecución garantizada.

12. ¿Qué servicios de nube puedo usar?

Hay dos categorías diferentes: proveedores que entregan push a dispositivos y servicios de mensajería que conectan componentes de tu backend.

Proveedores push

Servicio	Qué aporta	Cuándo considerarlo
Firebase Cloud Messaging (FCM)	Envío a tokens, topics y condiciones; integración Android y web, y capa de integración con APNs para iOS	Buen punto de partida multiplataforma
Apple APNs	Entrega remota nativa en plataformas Apple	Necesario en la ruta nativa de iOS, directamente o detrás de un proveedor
Amazon SNS Mobile Push	Abstracción de endpoint de plataforma y envío a FCM/APNs y otros servicios soportados	Si la infraestructura ya vive en AWS o se requiere segmentación por topics de SNS
Azure Notification Hubs	Gestión de instalaciones/tags y envíos cross-platform a PNS	Si ya se utiliza Azure o se necesita segmentación y administración de dispositivos
OneSignal	Plataforma administrada con segmentación, campañas, analítica e integración con proveedores de plataforma	Si se necesita más que una API de envío, como campañas y gestión de audiencias
Expo Push Service	Capa de envío para aplicaciones Expo/React Native según su configuración	Si el proyecto usa Expo y el servicio cubre sus requisitos

Servicios de mensajería para el backend

Servicio	Papel	No confundir con
Google Cloud Pub/Sub	Eventos asíncronos entre servicios y workers	No es por sí solo el servicio de push al móvil
AWS SNS	Puede distribuir mensajes a endpoints y también integra mobile push	No es lo mismo que SQS
AWS SQS	Cola de trabajos para procesar envíos de forma asíncrona	No entrega directamente una notificación al sistema operativo
Azure Service Bus	Colas y topics para comunicación backend	No sustituye a APNs/FCM
RabbitMQ / Kafka	Eventos o colas dentro de tu arquitectura	Requieren un worker que resuelva destinatarios y llame al proveedor push
Cloud Tasks	Ejecución asíncrona y controlada de tareas HTTP	No es el proveedor que entrega el push al teléfono

Arquitectura cloud sugerida

API de negocio
   |
   v
Evento: order.shipped
   |
   v
Cola o topic backend (opcional)
   |
   v
Worker de notificaciones
   |
   +--> Consulta preferencias y usuarios
   +--> Resuelve instalaciones activas
   +--> Construye payload por plataforma
   +--> Envía a FCM / APNs / Web Push
   +--> Guarda resultado y reintentos

13. ¿Qué significa «enviado», «entregado» y «visto»?

No son el mismo estado.

Aceptado por el proveedor: la API aceptó la solicitud; no significa que el teléfono ya la mostró.
Entregado al dispositivo o transporte: puede haber señales o métricas disponibles, pero no siempre existe confirmación exacta para cada plataforma y tipo de mensaje.
Mostrado por el sistema: el SO presentó la notificación, si el mensaje y los permisos lo permitieron.
Abierto por el usuario: la persona tocó la notificación o ejecutó una acción.
Procesado por la app: la aplicación completó una operación, como marcar el mensaje como leído.

Para eventos importantes, registra tus propios estados de negocio y las interacciones que el cliente pueda confirmar. No prometas «entrega exactamente una vez» basándote solo en la API push.

Fuente: Firebase — Understanding message delivery

14. Reintentos, duplicados, expiración y orden

La entrega push es asíncrona y está sujeta a redes, políticas del sistema y estados del dispositivo. Diseña el backend asumiendo que puede haber retrasos, mensajes obsoletos o reintentos.

Buenas prácticas:

Asignar un notification_id o event_id único.
Hacer idempotente el procesamiento de acciones.
Definir TTL para que una notificación antigua no aparezca después de perder sentido.
Usar collapse keys o mecanismos equivalentes solo cuando sea apropiado agrupar mensajes reemplazables.
Retirar tokens inválidos.
No reintentar indefinidamente errores permanentes.
Registrar códigos de respuesta y causa de fallo.
Mantener una bandeja de notificaciones en backend si la experiencia requiere historial fiable.
Al abrir la app, sincronizar el estado real desde la API.

15. Seguridad y privacidad

Los tokens y las suscripciones son identificadores sensibles desde el punto de vista operativo. No los expongas en logs públicos ni los aceptes sin validación.

Guarda las credenciales de servidor de FCM, claves privadas VAPID y credenciales de APNs solo en backend o un gestor de secretos.
Nunca incluyas credenciales privadas en el frontend, APK o bundle de JavaScript.
Registra tokens a través de una sesión autenticada y verifica a qué cuenta pertenecen.
Desasocia instalaciones al cerrar sesión cuando sea necesario para la política de privacidad.
Evita enviar secretos, datos financieros o contenido privado completo en payloads visibles.
Valida permisos al abrir un deep link.
Permite desactivar notificaciones por categoría y respeta las preferencias del usuario.
Elimina destinos inválidos y establece una política de retención de registros.

El cifrado de transporte y del payload Web Push no sustituye la autorización del recurso al que la notificación invita a navegar.

16. Errores frecuentes

Guardar un solo token por usuario. Una cuenta puede tener múltiples instalaciones.
Intentar Web Push en una pestaña de Safari iOS. En iPhone/iPad hace falta la web app en la pantalla de inicio; pide el permiso solo ahí, tras un gesto.
Confundir VAPID con FCM o APNs. VAPID pertenece al flujo Web Push; no reemplaza las credenciales nativas de APNs.
Pensar que un topic de Pub/Sub es un topic de FCM. Uno conecta servicios backend; el otro dirige mensajes a una audiencia de apps registradas.
Creer que HTTP 200 significa que el usuario vio la notificación. Normalmente solo indica aceptación de la solicitud en esa etapa.
Enviar datos privados a topics amplios. Los topics son para audiencias, no para información individual confidencial.
No actualizar tokens. Las instalaciones cambian y los tokens pueden invalidarse.
Probar solo con la app abierta. Foreground, background y terminated se comportan de forma distinta.
Suponer que un plugin multiplataforma elimina la configuración nativa. Los certificados, capabilities, permisos y SDKs siguen existiendo.
Usar push como almacenamiento fiable. La fuente de verdad debe estar en el backend.
No manejar el tap/deep link. La notificación aparece, pero la app no sabe a qué pantalla navegar.
Omitir showNotification en Safari. Si el service worker no muestra una notificación visible, la suscripción puede revocarse.

17. Recomendación de arquitectura

Para una aplicación multiplataforma nueva, una arquitectura inicial razonable podría ser:

Un servicio backend de notificaciones desacoplado de la lógica de negocio.
Una tabla de instalaciones/destinos, con múltiples registros por usuario.
FCM como punto de partida para Android y, si conviene, como capa de envío unificada; configuración de APNs para iOS.
Web Push con service worker y VAPID para una PWA, o Firebase Messaging Web si sus características encajan.
Un adaptador por proveedor (FCM, APNs, WebPush) detrás de una interfaz propia si se necesita cambiar o combinar proveedores.
Una cola como SQS, Pub/Sub o Service Bus cuando se necesiten reintentos, absorción de picos o procesamiento independiente.
Payloads pequeños con IDs de recursos y rutas lógicas.
Deep links validados por la aplicación y autorización en backend.
Métricas de aceptación, fallos, tokens inválidos y aperturas.
Tests para foreground, background, terminated, permisos denegados y tokens rotados.

Conclusión

Una notificación push no es una conexión directa del backend al teléfono. Es un mensaje enrutado por una infraestructura que conoce el destino registrado de una aplicación o suscripción.