Web Push API

Web Push API to standard W3C, który umożliwia stronom internetowym wysyłanie powiadomień push do przeglądarek — nawet gdy strona nie jest aktualnie otwarta. Definiuje interakcję między serwerem aplikacji (backend), serwisem push (Mozilla, Google FCM, Apple) a przeglądarką, łącznie z szyfrowaniem end-to-end zgodnie z RFC 8291.

Co to jest Web Push API?

Web Push API to otwarta specyfikacja W3C definiująca, w jaki sposób serwer aplikacji dostarcza wiadomość push do przeglądarki. Uzupełnia dwa powiązane standardy: Push API (RFC 8030, opisuje protokół między serwerem aplikacji a serwisem push) oraz Service Worker API (wyświetla odebraną wiadomość w przeglądarce).

W przeciwieństwie do zastrzeżonych serwisów push, jak Apple APNs czy Google FCM, Web Push API jest niezależne od dostawcy: każdy producent przeglądarki obsługuje własny endpoint serwisu push posługujący się tym samym protokołem. Serwery aplikacji nie muszą zatem rozróżniać między Mozillą, Google czy Microsoftem — wysyłają na adres URL endpointu, który przeglądarka zwróciła przy opt-inie.

Przepływ dostarczenia push

Subskrypcja: Strona rejestruje Service Worker przy opt-inie i wywołuje pushManager.subscribe(). Przeglądarka tworzy URL endpointu i dwa klucze kryptograficzne (p256dh i auth) i zwraca je stronie.
Przechowywanie: Strona wysyła obiekt subskrypcji do serwera aplikacji, który przypisuje go do rekordu użytkownika.
Wysyłka: Gdy firma chce wysłać wiadomość push, serwer aplikacji szyfruje ładunek dwoma kluczami zgodnie z RFC 8291 i wysyła go na adres URL endpointu.
Dostarczenie: Serwis push dostawcy przeglądarki przekazuje zaszyfrowaną wiadomość do przeglądarki użytkownika końcowego.
Wyświetlenie: Service Worker odbiera zdarzenie push, odszyfrowuje ładunek i wywołuje showNotification() — pojawia się systemowe powiadomienie.

VAPID — identyfikacja nadawcy

VAPID (Voluntary Application Server Identification, RFC 8292) to mechanizm, dzięki któremu serwer aplikacji identyfikuje się wobec serwisu push. Serwer podpisuje każde żądanie parą kluczy ECDSA (P-256). Klucz publiczny jest przekazywany przeglądarce podczas wywołania subskrypcji; klucz prywatny pozostaje w backendzie. Pozwala to serwisowi push zidentyfikować nadawcę i zapobiec nadużyciom.

VAPID jest wymagany przez wszystkie główne przeglądarki od 2017 roku. Kto buduje własne implementacje push, generuje parę kluczy jednorazowo (np. używając biblioteki web-push dla Node.js lub pywebpush dla Pythona) i używa jej dla wszystkich subskrypcji.

Format ładunku

Web Push API przesyła dowolny zaszyfrowany ładunek (zazwyczaj JSON). Service Worker decyduje, jak wiadomość jest wyświetlana. Typowe pola:

{
  "title": "Zamówienie wysłane",
  "body": "Twoja paczka dotrze jutro.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/zamowienia/12345",
  "tag": "aktualizacja-zamowienia"
}

Ładunek jest ograniczony do kilku kilobajtów (zależnie od przeglądarki, zazwyczaj 4 KB). Duże treści nie są dołączane do ładunku, ale ładowane po kliknięciu.

TTL i best practice

Każda wiadomość push ma czas Time-To-Live (TTL, w sekundach), który serwer aplikacji ustawia w nagłówku HTTP. Jeśli odbiorca jest offline, serwis push przechowuje wiadomość przez określony TTL. Dla treści krytycznych czasowo (np. kody 2FA) TTL powinien wynosić 60–300 sekund; dla kampanii reaktywacyjnych sensowne może być kilka godzin.

Best practice dla MŚP: domyślnie ustaw TTL na 24 godziny, używaj nagłówka urgent tylko dla naprawdę pilnych wiadomości. Utrzymuje to zdrową ocenę jakości przy serwisie push i zapobiega opóźnieniom dostarczenia.

Web Push API w SendSeven

SendSeven używa Web Push API dla kanału browser-push. Klucze VAPID, zarządzanie subskrypcjami, szyfrowanie i kontrola TTL są w całości abstrakcjonowane w obrębie platformy. Push jest wysyłany albo jako zaplanowana kampania przez Reach do segmentu, albo przez bezpośrednie wywołanie REST API z Twojego własnego systemu — który steruje też timingiem. Browser-push nie jest kanałem w Flow Builderze; następujące po nim kroki SMS lub e-mail można jednak tam orkiestrować.