Web Push API

La Web Push API es el estándar W3C con el que los sitios web pueden enviar notificaciones Push a los navegadores, incluso cuando el sitio web no está abierto en ese momento. Define la interacción entre el servidor de aplicaciones (backend), el servicio Push (Mozilla, Google FCM, Apple) y el navegador, incluido el cifrado de extremo a extremo según el RFC 8291.

¿Qué es la Web Push API?

La Web Push API es una especificación W3C abierta que define cómo un servidor de aplicaciones entrega un mensaje Push a un navegador. Complementa dos estándares relacionados: la Push API (RFC 8030, describe el protocolo entre el servidor de aplicaciones y el servicio Push) y la Service Worker API (muestra el mensaje recibido en el navegador).

A diferencia de los servicios Push propietarios como los APNs de Apple o el FCM de Google, la Web Push API es neutral en cuanto al proveedor: cada fabricante de navegadores opera su propio endpoint de servicio Push que habla el mismo protocolo. Los servidores de aplicaciones no necesitan distinguir entre Mozilla, Google o Microsoft: envían a la URL del endpoint que el navegador devolvió en el momento del opt-in.

Proceso de entrega de un Push

  1. Suscripción: en el momento del opt-in, el sitio web registra un Service Worker y llama a pushManager.subscribe(). El navegador genera una URL de endpoint y dos claves criptográficas (p256dh y auth) y las devuelve al sitio web.
  2. Almacenamiento: el sitio web envía el objeto de suscripción al servidor de aplicaciones, que lo asocia a un registro de usuario.
  3. Envío: cuando la empresa quiere enviar un mensaje Push, el servidor de aplicaciones cifra el payload con las dos claves según el RFC 8291 y lo envía a la URL del endpoint.
  4. Entrega: el servicio Push del fabricante del navegador reenvía el mensaje cifrado al navegador del usuario final.
  5. Visualización: el Service Worker recibe el evento Push, descifra el payload y llama a showNotification(): aparece la notificación del sistema.

VAPID: identificación del remitente

VAPID (Voluntary Application Server Identification, RFC 8292) es el mecanismo con el que un servidor de aplicaciones se identifica ante el servicio Push. El servidor firma cada solicitud con un par de claves ECDSA (P-256). La clave pública se pasa al navegador en la llamada de suscripción; la clave privada permanece en el backend. Así el servicio Push puede identificar al remitente y evitar abusos.

VAPID es obligatorio en todos los navegadores principales desde 2017. Quien construye sus propias implementaciones Push genera el par de claves una sola vez (por ejemplo con la librería web-push para Node.js o pywebpush para Python) y lo utiliza para todas las suscripciones.

Formato del payload

La Web Push API transmite un payload cifrado arbitrario (típicamente JSON). El Service Worker decide cómo se muestra el mensaje. Campos habituales:

{
  "title": "Pedido enviado",
  "body": "Su paquete llega mañana.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/orders/12345",
  "tag": "order-update"
}

El payload está limitado a pocos kilobytes (específico del navegador, normalmente 4 KB). Los contenidos grandes no se transmiten en el payload, sino que se cargan al hacer clic en la notificación.

TTL y mejores prácticas

Cada mensaje Push tiene un Time-To-Live (TTL, en segundos) que el servidor de aplicaciones establece en el encabezado HTTP. Si el destinatario está sin conexión, el servicio Push guarda el mensaje durante el TTL indicado. Para contenidos con límite de tiempo (como códigos 2FA) el TTL debe establecerse en 60 a 300 segundos; para campañas de reactivación pueden ser útiles varias horas.

Mejor práctica para pymes: TTL por defecto a 24 horas; usar el encabezado urgent solo para mensajes realmente urgentes. Así se mantiene una buena calificación de calidad con el servicio Push y las entregas no se retrasan.

Web Push API en SendSeven

SendSeven utiliza la Web Push API para el canal Browser Push. Las claves VAPID, la gestión de suscripciones, el cifrado y el control del TTL están abstraídos en la plataforma. El Push se envía como campaña programada a través de Reach a un segmento, o mediante llamada directa a la REST API desde su propio sistema, que también controla así el timing. Browser Push no es un canal en el Flow Builder; los pasos posteriores de SMS o email se pueden orquestar allí sin embargo.