# Browser notifications > Register, review and revoke a browser device for account or environment notifications. Section: Synapse and Locus. Web page: https://docs.staging.katara.com/products/browser-notifications/ Open **Notifications → Browser Notifications** to register this browser for the selected account-wide or environment scope. Device registration and notification preferences are separate: select **Push** for the categories you want in **Notification Delivery Preferences**. Current source access, quiet hours, snoozes and suppression still apply. Test notifications remain intercepted. Account-wide devices can receive account notices and Live environment notices you currently have permission to read. Registering one grants no organization access. Environment devices cover only that selected environment and reset generation. Test notifications remain intercepted in either case. A working installation needs an enrolled Push provider, application server key and sender, HTTPS, browser support and your browser permission. The presence of device metadata does not prove delivery. ## Register a device Load the current configuration and choose an authorization duration, up to 30 days. **Prepare Browser Subscription** requests browser permission only after you click it. Review the provider, public application server key, scope, reset generation for an environment, and deadline, then explicitly confirm registration. Each scope supports up to eight active, unexpired devices: eight account-wide devices and eight for the selected environment/reset. Delivery merges those sets and removes duplicate endpoints, for at most sixteen destinations. Account opt-in takes precedence when the same endpoint appears in both sets. A frozen delivery never adds another device or falls back to another registration after reservation. The browser keeps its native subscription keys. Katara receives the endpoint and subscription encryption material only during registration and encrypts them for sending. Device lists, operation receipts and audit metadata omit endpoints and authentication secrets. Push messages contain a fixed wake-up marker; the browser shows a generic Katara notification and opens the Notifications page. Message bodies and account or resource identifiers are not included in that payload. An endpoint remains assigned to the first account that registered it, even after revocation. The same account can opt in account-wide and separately across environments. After expiry or an environment reset, registering the same endpoint retires the stale registration for that environment. A different account must create a new browser subscription. **Remove Local Browser Subscription** explicitly unsubscribes the local endpoint; it does not revoke server records. Resolve unknown registration outcomes first, and revoke known records separately. ## Inspect an uncertain result Registration and revocation use an exact operation UUID. The portal saves only scope, identifiers, versions, timestamps, the operation key and a request digest in tab storage. It never saves the endpoint or browser authentication material. After a lost reply, use **Inspect Saved Operation** before retrying. Registration recovery requires explicitly preparing the same browser subscription again and matching the saved digest. A different request cannot reuse that key. A completed receipt describes the original mutation. It does not establish that the device is currently active, unexpired or authorized after a reset. Reload the current device list and review an exact revision before revocation. No recovery flow retries automatically. ## SDK and delivery behavior TypeScript exposes `client.notificationPush`; Python exposes `client.notification_push`. Environment methods are `configuration`, `register`, `list`, `get`, `revoke` and `operation`. TypeScript adds `registerAccount`, `listAccount`, `getAccount`, `revokeAccount` and `accountOperation`; Python uses their snake-case forms. Account requests require `scope: "account"` and cannot select another user or supply organization or reset pins. Registration takes subscription material separately from the public metadata request. Keep the exact request and operation UUID until its result is known. Human-session authentication is required. Delivery freezes the eligible device set and records each device attempt before transport. Up to eight sends run concurrently under the exact current delivery lease. Accepted or uncertain attempts are not dispatched again. A device that definitely never reached transport can be recorded as denied; if recording the outcome itself cannot be confirmed, the reserved attempt remains uncertain. An uncertain device outcome takes precedence over accepted outcomes when reporting aggregate delivery. Provider acceptance is not proof that a browser displayed a message. The sender uses [Web Push encryption](https://www.rfc-editor.org/rfc/rfc8291) and [VAPID authentication](https://www.rfc-editor.org/rfc/rfc8292). Only explicitly enrolled HTTPS destinations are permitted; redirects and private-network DNS answers are refused. Operators must preserve the independent endpoint ownership index key. Unsupported replacement is refused, and encryption-key rotation needs an explicit retained-key migration strategy. Local protocol and database checks cover encryption, destination restrictions, current authority, both subscription scopes, sixteen-device bounded dispatch and one-attempt outcomes. Installed browser compatibility, provider enrollment and external delivery acceptance remain separate checks. ## Operator configuration The API and notification worker read the same reviewed enrollment through `KATARA_NOTIFICATIONS_PUSH_ENROLLMENT_FILE`. The file must be an absolute path to a regular file owned by the process user with mode `0600`. Symlinks, pipes, unknown fields and files over 32 KiB are refused. An absent setting disables this adapter; an invalid configured file prevents startup. No keys or provider enrollments are created by loading it. The version 1 JSON envelope contains `schema_version`, `key_id`, `encryption_key`, `endpoint_index_key`, `vapid_private_key`, `contact` and `providers`. The three private keys are canonical padded base64 encoding of 32 bytes; the VAPID value is a valid P-256 private scalar. `contact` is a reviewed HTTPS contact URL. Each provider declares an `id`, exact HTTPS `origin` and `path_prefix`. Keep this file out of client bundles, logs and source control. The public configuration returns only provider metadata and the derived public application key. The worker pool must allow at least nine connections.