Web Push API

The Web Push API is the W3C standard that allows websites to send push notifications to browsers — even when the website is not currently open. It defines the interaction between the application server (backend), the push service (Mozilla, Google FCM, Apple), and the browser, including end-to-end encryption per RFC 8291.

What is the Web Push API?

The Web Push API is an open W3C specification that defines how an application server delivers a push message to a browser. It complements two related standards: the Push API (RFC 8030, describing the protocol between the application server and the push service) and the Service Worker API (which displays the received message in the browser).

In contrast to proprietary push services like Apple's APNs or Google's FCM, the Web Push API is vendor-neutral: every browser vendor operates its own push service endpoint that speaks the same protocol. Application servers therefore do not need to distinguish between Mozilla, Google, or Microsoft — they send to the endpoint URL that the browser returned at opt-in.

Push delivery flow

  1. Subscription: The website registers a service worker at opt-in and calls pushManager.subscribe(). The browser creates an endpoint URL and two cryptographic keys (p256dh and auth) and returns them to the website.
  2. Storage: The website sends the subscription object to the application server, which maps it to a user record.
  3. Send: When the company wants to send a push message, the application server encrypts the payload with the two keys per RFC 8291 and sends it to the endpoint URL.
  4. Delivery: The browser vendor's push service forwards the encrypted message to the end user's browser.
  5. Display: The service worker receives the push event, decrypts the payload, and calls showNotification() — the system notification appears.

VAPID — identifying the sender

VAPID (Voluntary Application Server Identification, RFC 8292) is the mechanism by which an application server identifies itself to the push service. The server signs each request with an ECDSA key pair (P-256). The public key is passed to the browser during the subscription call; the private key stays in the backend. This allows the push service to identify the sender and prevent abuse.

VAPID has been required by all major browsers since 2017. Anyone building their own push implementations generates the key pair once (e.g. using the web-push library for Node.js or pywebpush for Python) and uses it for all subscriptions.

Payload format

The Web Push API transmits an arbitrary encrypted payload (typically JSON). The service worker decides how the message is displayed. Common fields:

{
  "title": "Order dispatched",
  "body": "Your parcel arrives tomorrow.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/orders/12345",
  "tag": "order-update"
}

The payload is limited to a few kilobytes (browser-specific, usually 4 KB). Large content is not included in the payload but loaded on click.

TTL and best practice

Every push message has a Time-To-Live (TTL, in seconds) that the application server sets in the HTTP header. If the recipient is offline, the push service holds the message for the specified TTL. For time-critical content (e.g. 2FA codes), TTL should be set to 60–300 seconds; for re-engagement campaigns, several hours can make sense.

Best practice for SMBs: set TTL to 24 hours by default, use the urgent header only for genuinely urgent messages. This keeps the quality rating with the push service healthy and prevents delivery delays.

Web Push API in SendSeven

SendSeven uses the Web Push API for the browser push channel. VAPID keys, subscription management, encryption, and TTL control are all abstracted within the platform. Push is either sent as a scheduled campaign via Reach to a segment, or via a direct call to the REST API from your own system — which also controls the timing. Browser push is not a channel in the Flow Builder; downstream SMS or email steps can however be orchestrated there.