# Set up web push alerts

Web push delivers a native browser notification to whichever device and browser you registered it from. There's
no address to type - the contact is the browser's own push subscription.

## Settings reference

| Setting (UI label) | API field (v2) | Type / allowed values | Default | Plan limits | What it does for you |
|---|---|---|---|---|---|
| Contact Type | `type` | `"webPush"` | - | - | |
| Push subscription | `pushSubscription` (create only) | `{endpoint, p256dh, auth}` - the exact three values the browser's Push API returns | - (required on create) | - | The registration result the browser hands over; there is no typed address at all |

`pushSubscription` can only be set on **create** - it names a specific browser, so re-pointing an existing
contact at a different browser isn't supported (create a new contact instead). It's also never read back on a
`GET` - the values are the endpoint's encryption secrets, not something any read on this API has ever
published.

## Set it up in the app

1. Sign in to the HostTracker web app in the browser you want alerts on.
2. When prompted (or from **Contacts → Add contact → Web push**), allow notifications for the site.
3. That browser is registered as a confirmed contact automatically - HostTracker completes the subscription
   exchange with your browser's push service and creates the contact in one step.

## What the message looks like

A native OS/browser notification: the monitor's name and what happened, clickable to open the relevant page in
HostTracker.

## Do it with the API or MCP

Web push is the one channel whose "address" only a browser can produce - a script can't type one in. The
create call exists for completeness (it's what the app's own browser code calls), but in practice you register
from the browser, not from a script:

```
POST /contact
{ "type": "webPush", "name": "My laptop",
  "pushSubscription": { "endpoint": "https://...", "p256dh": "...", "auth": "..." } }
```

MCP: `create_contact(type="webPush", ...)` is listed as accepted, but supplying a real `pushSubscription` from
outside a browser isn't a realistic agent task - this one is best left to the in-app prompt.

## What happens next

The contact is created and confirmed in the same step - there's no separate confirmation code, since the
browser's own subscription handshake already proves the endpoint is real.

## Limits and gotchas

- The contact is tied to **that browser on that device** - registering from a second browser or device creates
  a separate contact.
- Clearing site data, uninstalling the browser, or revoking the notification permission breaks the contact
  silently; [send a test alert](/alerts/test-a-contact/) periodically if you rely on it.
- Notifications only arrive while the browser is running (and, depending on the OS, may need it to be open in
  the background).
- Web push cannot receive scheduled reports.

## Related

- [What a contact is](/alerts/contacts/)
- [All channels](/alerts/channels/)