Create a website connection
- Open Settings > Channels > Web Push as a workspace owner or admin.
- Name the website, choose its environment, and enter the exact HTTPS origin where visitors will subscribe. Use only one Web Push application per origin; staging and development need distinct origins.
- Import customer-owned VAPID keys or ask Wepy to generate a dedicated pair for this website.
- Use a mailto or HTTPS VAPID subject that your organization controls.
- If Wepy generates the keys, download or copy the one-time private-key backup before acknowledging it. Wepy does not reveal the private key again.
- If saving is interrupted, keep the form unchanged and retry the exact setup. Wepy safely recovers the original completed response instead of creating another website or another set of credentials.
Customer-owned and workspace scoped
Each website connection belongs to the active workspace. Keep production and test origins separate, and never paste VAPID private keys, subscription endpoints, or browser key material into support messages.
Create a new connection when the origin changes
Once an application has subscription records, its origin, environment, service-worker path, and scope remain fixed so old browser bindings cannot be reassigned across origins. Create a new Web Push website connection for a new origin or installation identity; only its internal name, branding, and primer copy remain editable.
VAPID rollover affects new enrollments only
A VAPID rollover changes the key used for new browser enrollments. Generated rollovers expose the new raw private key once and require the same backup acknowledgement as creation. If the response is interrupted, leave the rotation values unchanged and retry the exact action so Wepy can recover that same backup without rotating again. Existing subscriptions keep using retained earlier keys indefinitely, so rollover does not revoke or contain an exposed prior key. Pause the Push app if exposure is suspected.
Rotate signed-identity credentials with an overlap
Owners and admins can separately rotate the backend-only identity signing secret. Wepy returns the new raw secret once, keeps the previous secret valid until the exact overlap deadline shown after rotation, and blocks navigation until the new value is copied or downloaded and acknowledged. Update WEPY_PUSH_IDENTITY_SIGNING_SECRET in approved secret storage and on the customer backend before that deadline. VAPID keys, browser subscriptions, and contact matching data do not change.
Install and verify Web Push
- Generate a short-lived verification code, publish it as the exact plain-text contents of /.well-known/wepy-push-verification.txt on the configured origin, and keep the file available during the installation handshake. You may remove it after Wepy shows Verified.
- Download, review, and self-host the matching immutable SDK and service-worker runtime on the configured website origin for the strongest supply-chain control. The current pair is 1.0.1; replace both files together and use the checksum shown by Wepy. Pinned 1.0.0 files remain available but do not contain the permission-primer fix.
- Configure the versioned browser SDK with the public application ID, service-worker path, and short-lived verification token shown by Wepy.
- Call WepyPush.showPrompt from a meaningful, persistent Notification settings action. The soft primer uses your saved copy; native permission follows only its Allow click. Wepy never asks for browser permission during page load. Use subscribe directly only when your own UI provides the primer.
- Run Verify installation in Wepy and resolve any origin, SDK, service-worker, or configuration diagnostic that fails.
- Subscribe the exact test browser, run WepyPush.createTestDevicePairing() from a protected, explicit website action, and enter its single-use code in Wepy within 10 minutes. Then send a controlled test notification.
Website ownership is checked server-side
Wepy fetches the fixed well-known file from the configured HTTPS origin itself. The verifier pins public DNS resolution, rejects private-network addresses and redirects, and bounds request time, headers, and body size. Supplying the code from a browser or command-line Origin header alone cannot verify a website.
Subscription details stay private
Wepy shows only a device label, broad browser/platform capability, status, and timestamps in Settings. Subscription endpoints, authentication secrets, encryption keys, and raw user-agent strings stay hidden.
Pairing proves control of the current browser
A workspace owner or admin cannot mark an arbitrary subscription by ID. The current browser must create a short-lived code using its purpose-limited revocation capability; Wepy consumes that code once, rechecks that the subscription is reachable and unchanged, and then associates only the sanitized test label with the current admin. Creating a newer code invalidates the older one.
Browser and iPhone/iPad compatibility
Web Push requires HTTPS and a service worker, and works where supported in current Chrome, Edge, Firefox, and Safari. On iOS or iPadOS 16.4 and later, the visitor must first add the website to the Home Screen before it can request permission or subscribe. This is website Push, not native mobile-app Push; Wepy records only bounded capability labels and never a raw user-agent fingerprint.
Signed identity stays server-side
To associate a subscribed browser with a customer, mint a signed assertion only on your authenticated backend. Bind version 1, publicAppId, the exact subscriptionId returned by WepyPush.status() or subscribe(), externalId, a unique jti, iat, and an expiry no more than five minutes later; optional profile fields may be included. Return only the assertion to the browser and pass it to WepyPush.identify(). Never expose the identity signing secret in browser code.
Detach shared browsers before account changes
Before logout or an account switch, await WepyPush.detachIdentity() before clearing the customer session. The SDK invalidates the local browser endpoint first and durably records the detach or revocation without storing endpoint/key material. Do not identify the next customer automatically: show the soft primer again, require fresh Wepy consent even when browser permission remains granted, then mint a new assertion for the new subscription ID.
Campaigns and honest results
After verification, create a Web Push campaign, select the website application, target all active subscribers or narrow by List or Segment, compose and preview the notification, test the exact saved notification on a reachable test browser, then send now or schedule. Results separates device attempts, push-service acceptance, signed presentation callbacks, click events, uncertain outcomes, failures, expirations, and skips without exposing endpoints or recipient identities. For Web Push, a presentation callback means showNotification() resolved; operating-system settings can still suppress visible UI, while a signed click is human-interaction proof.
One Push workflow, transport-specific setup
Web and Mobile destinations now share the Push composer, app-scoped topics, reusable templates, automation sends, quiet hours, frequency controls, experiments, and results vocabulary. Browser setup remains separate because VAPID, service workers, and browser permission do not apply to native apps.
Pause safely without blocking privacy controls
Owners and admins can pause a Web Push website without deleting its installation or history. Pausing stops new subscriptions, controlled tests, and campaign sends, while existing browsers can still unsubscribe or detach identity. Resuming restores future activity after normal readiness checks and never launches a saved campaign automatically.