Web Push API

Die Web Push API ist der W3C-Standard, mit dem Webseiten Push-Benachrichtigungen an Browser senden können – auch wenn die Webseite gerade nicht geöffnet ist. Sie definiert das Zusammenspiel zwischen Application Server (Backend), Push Service (Mozilla, Google FCM, Apple) und Browser inklusive End-to-End-Verschlüsselung nach RFC 8291.

Was ist die Web Push API?

Die Web Push API ist eine offene W3C-Spezifikation, die definiert, wie ein Anwendungs-Server eine Push-Nachricht an einen Browser zustellt. Sie ergänzt zwei verwandte Standards: die Push API (RFC 8030, beschreibt das Protokoll zwischen Application Server und Push Service) und die Service Worker API (zeigt die empfangene Nachricht im Browser an).

Im Unterschied zu proprietären Push-Diensten wie Apples APNs oder Googles FCM ist die Web Push API vendor-neutral: Jeder Browser-Hersteller betreibt einen eigenen Push-Service-Endpoint, der das gleiche Protokoll spricht. Application Server müssen also nicht zwischen Mozilla, Google oder Microsoft unterscheiden – sie senden an die Endpoint-URL, die der Browser beim Opt-in zurückgegeben hat.

Ablauf einer Push-Zustellung

  1. Subscription: Die Webseite registriert beim Opt-in einen Service Worker und ruft pushManager.subscribe() auf. Der Browser erzeugt eine Endpoint-URL und zwei kryptografische Schlüssel (p256dh und auth) und gibt sie an die Webseite zurück.
  2. Speicherung: Die Webseite sendet das Subscription-Objekt an den Application Server, der es einem Nutzer-Datensatz zuordnet.
  3. Versand: Möchte das Unternehmen eine Push-Nachricht senden, verschlüsselt der Application Server den Payload mit den beiden Schlüsseln nach RFC 8291 und schickt ihn an die Endpoint-URL.
  4. Zustellung: Der Push Service des Browser-Herstellers leitet die verschlüsselte Nachricht an den Browser des Endnutzers weiter.
  5. Anzeige: Der Service Worker empfängt das Push-Event, entschlüsselt den Payload und ruft showNotification() auf – die System-Notification erscheint.

VAPID – Identifikation des Senders

VAPID (Voluntary Application Server Identification, RFC 8292) ist der Mechanismus, mit dem sich ein Application Server gegenüber dem Push Service ausweist. Der Server signiert jede Request mit einem ECDSA-Schlüsselpaar (P-256). Der Public Key wird beim Subscription-Aufruf an den Browser übergeben, der Private Key bleibt im Backend. So kann der Push Service den Sender identifizieren und Missbrauch verhindern.

VAPID ist seit 2017 in allen großen Browsern Pflicht. Wer eigene Push-Implementierungen baut, generiert das Schlüsselpaar einmalig (z.B. über die Bibliothek web-push für Node.js oder pywebpush für Python) und verwendet es für alle Subscriptions.

Payload-Format

Die Web Push API überträgt einen beliebigen verschlüsselten Payload (typisch JSON). Der Service Worker entscheidet, wie die Nachricht angezeigt wird. Übliche Felder:

{
  "title": "Bestellung versandt",
  "body": "Ihr Paket trifft morgen ein.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/orders/12345",
  "tag": "order-update"
}

Der Payload ist auf wenige Kilobyte begrenzt (Browser-spezifisch, meist 4 KB). Große Inhalte werden nicht im Payload übertragen, sondern beim Klick auf die Notification nachgeladen.

TTL und Best Practice

Jede Push-Nachricht hat eine Time-To-Live (TTL, in Sekunden), die der Application Server im HTTP-Header setzt. Ist der Empfänger offline, hält der Push Service die Nachricht für die angegebene TTL bereit. Für zeitkritische Inhalte (z.B. 2FA-Codes) sollte TTL auf 60–300 Sekunden gesetzt werden; für Reaktivierungs-Kampagnen können einige Stunden sinnvoll sein.

Best Practice für KMU: TTL standardmäßig auf 24 Stunden, urgent-Header nur bei wirklich dringlichen Nachrichten setzen. So bleibt das Quality-Rating beim Push Service gut und Auslieferungen werden nicht verzögert.

Web Push API in SendSeven

SendSeven nutzt die Web Push API für den Kanal Browser-Push. VAPID-Schlüssel, Subscription-Management, Verschlüsselung und TTL-Steuerung sind in der Plattform abstrahiert. Push wird entweder als geplante Kampagne über Reach an ein Segment gesendet oder per direktem Aufruf der REST API aus Ihrem eigenen System, das damit auch das Timing steuert. Browser-Push ist kein Kanal im Flow Builder; nachgelagerte SMS- oder E-Mail-Schritte lassen sich dort jedoch orchestrieren.