Wiki · Concept · Last reviewed June 25, 2026

Push API

The Push API is the browser mechanism for subscribing a web application to server-originated messages that can be delivered through a service worker.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, service workers, web push, notifications, agents, attention

Definition

The Push API is a W3C browser API that lets a web application subscribe to push messages from an application server. The browser exposes push through a service worker registration, most visibly through PushManager, PushSubscription, and the service worker push event.

This page is about Web Push, not A2A Push Notifications. A2A push is a protocol-level webhook pattern between agents and clients. Browser Push is a user-agent mediated channel involving a web app, a browser, a push service, a service worker, and usually a notification surface.

How It Works

A page with a registered service worker can ask the browser to subscribe through registration.pushManager.subscribe(). The resulting PushSubscription includes an endpoint and cryptographic key material that the application server uses when sending push messages. The W3C Push API explains that the user agent may rely on a push service to receive and route those messages.

The IETF Web Push protocol, RFC 8030, defines generic event delivery using HTTP push. RFC 8291 defines encryption for Web Push messages so the push service does not need plaintext access to the message content. RFC 8292 defines VAPID, a voluntary application-server identification mechanism for Web Push. Together, those layers separate browser API, network delivery protocol, message encryption, and application-server identity.

When a push message arrives, the browser can start the service worker and dispatch a push event. The web app may then show a notification, refresh local state, or perform other permitted work. Many browsers require user-visible notification behavior for push subscriptions; operational claims should be checked against the exact browser and platform.

Agent Context

Push matters for agents because it is an attention channel that can outlive the visible page. An AI browser, companion, workplace assistant, or agentic commerce surface might want to alert a user about task completion, a request for approval, a failed background action, a checkout change, or a delegated workflow that needs review.

That usefulness creates a governance boundary. A pushed message can feel like the system speaking with urgency, even when the message is generated by a marketing rule, workflow retry, ranking system, or remote agent. Agent-facing push should be treated as a power to interrupt, not merely a transport feature.

Governance Use

A well-governed push system keeps subscription and message purpose legible. Users should be able to tell which site or app subscribed, what categories of messages it sends, how to revoke the subscription, and whether an AI agent can trigger or draft push content.

For agent workflows, push events should be connected to audit trails. A notification that says a task is complete should trace back to a task identifier, model or service version where relevant, human approval status, and any later action the user took from the notification. Push should not become a hidden lane for delegated decisions.

Limits

The Push API is not a consent framework, a guarantee of delivery, or an authorization grant. It does not decide whether a message is manipulative, urgent, lawful, or appropriate. Browser permissions, quiet-notification policies, operating-system settings, battery controls, network conditions, and subscription expiration can all affect behavior.

It is also not the same as Background Sync API. Background Sync retries work the site already queued. Push lets a server initiate a message to the user agent through a subscription channel.

Minimum Evidence Record

For agent-mediated push, record the origin, service worker scope, subscription creation time, permission state, push endpoint host, VAPID application identity where used, message category, triggering task or rule, user-visible notification text class, delivery timestamp, click or dismissal event, and revocation path. Do not log raw endpoint secrets, private keys, message plaintext, or unnecessary personal data.

Source Discipline

Use the W3C Push API for browser interfaces, MDN for implementation-facing API summaries, RFC 8030 for Web Push delivery, RFC 8291 for message encryption, and RFC 8292 for VAPID. Do not collapse Web Push, notifications UI, Background Sync, A2A webhooks, or native mobile push into one system.

Spiralist Reading

Spiralism reads push as the web reaching back toward the person after the page is gone. That can be care: your ride is here, your upload failed, your agent needs approval. It can also be capture: the machine learns when to knock.

The discipline is to make the knock accountable. A push message should carry a reason, a source, a revocation path, and a boundary between reminder and command.

Sources

Return to Wiki