> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/platform/platform-services/notifications.md). # Notifications How OpenG2P sends notifications. Product services emit business events. The Connector delivers these events to the Notification Provider, which handles notification workflows, channel orchestration, a **How OpenG2P Sends Notifications:** Product services emit business events. The **Connector** delivers these events to the **Notification Provider**, which handles notification workflows, channel orchestration, and the in-app inbox. The **client package** consumes the in-app inbox state and exposes it to OpenG2P user interfaces. Two libraries live in [OpenG2P/notifications](https://github.com/OpenG2P/notifications). The connector and the client package talk to the notification provider. The default system is self-hosted Novu. Its install, workflow seeding, and email and SMS channel notes are in [Novu](/platform/platform-services/notifications/notification-provider/novu.md). | Piece | What it is | | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Connector](/platform/platform-services/notifications/connector.md) | The [`connector/`](https://github.com/OpenG2P/notifications/tree/develop/connector) library in [OpenG2P/notifications](https://github.com/OpenG2P/notifications). A service uses it to send a notification. | | [Client](/platform/platform-services/notifications/client.md) | The [`client/`](https://github.com/OpenG2P/notifications/tree/develop/client) library in the same repository. A UI uses it to show the inbox. | | [Notification provider](/platform/platform-services/notifications/notification-provider.md) | Workflows, channel steps, retries, and inbox state. [Novu](/platform/platform-services/notifications/notification-provider/novu.md) is the built-in notification provider. | The connector and the client do not import each other. Replacing the notification provider does not change Registry or AWE call sites, and it does not change the `Inbox` component. ## Design at a glance ```mermaid flowchart LR subgraph products["OpenG2P Product Services"] Registry["Registry Staff API / Celery"] AWE["AWE API"] end Connector["OpenG2P Notification Connector"] subgraph novu["Novu — Notification Provider"] Workflows["Notification Workflows"] Channels["Channel Orchestration"] Inbox["In-App Inbox"] Email["Email"] SMS["SMS"] end Client["@openg2p/notification"] UI["OpenG2P User Interfaces"] Registry -->|"Business events"| Connector AWE -->|"Business events"| Connector Connector -->|"API key · send / send_bulk"| Workflows Workflows --> Channels Workflows --> Inbox Client -->|"Inbox state / socket"| Inbox UI --> Client Channels --> Email Channels --> SMS ``` | Piece | What it does | | --------------------- | ------------------------------------------------------------------------------------------- | | Product service | Decides that something happened, who should hear about it, and which payload fields to send | | Connector | Maps the event key to a notification provider workflow id and calls `send` or `send_bulk` | | Notification provider | Runs the workflow: in-app, email, SMS, retries, and inbox state | | Client | Lists the inbox and opens the live socket. It does not send | `NOTIFICATION_WORKFLOWS` is the allow-list. An event key that is missing from that map is not sent. An empty map sends nothing. `NOTIFICATION_ENABLED=false` skips every send even when the map lists the event. A send that fails is logged and swallowed. The change request, the intake submission, the export, and the approval still succeed. ## Who reads which page | You are | Start here | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Adding notifications to a new service and its UI | [Integrating a new service](/platform/platform-services/notifications/integrating.md) | | Adding a send to a service | [Implementing a send](/platform/platform-services/notifications/implementing.md), then [Connector](/platform/platform-services/notifications/connector.md) | | Putting the bell in a UI | [Client](/platform/platform-services/notifications/client.md) | | Wiring Helm for Registry or AWE | [Deployment](/platform/platform-services/notifications/deployment.md) | | Installing Novu or seeding workflows | [Novu](/platform/platform-services/notifications/notification-provider/novu.md) | | Adding an email or SMS integration | [Email and SMS](/platform/platform-services/notifications/notification-provider/novu.md#email-and-sms) | | Changing who receives a registrant email | [Workflows and payloads](/platform/platform-services/notifications/workflows-and-payloads.md#registrant-contact-in-an-extension) | | Replacing the notification provider | [Switch provider on the connector](/platform/platform-services/notifications/connector.md#switch-provider) and [on the client](/platform/platform-services/notifications/client.md#switch-provider) | | Checking why one event is silent | [Architecture](/platform/platform-services/notifications/architecture.md#when-a-send-does-not-happen) | ## In this section | Page | Covers | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [Architecture](/platform/platform-services/notifications/architecture.md) | Hops, identity, and what each side owns | | [Connector](/platform/platform-services/notifications/connector.md) | Python API, environment variables, and switching the provider | | [Client](/platform/platform-services/notifications/client.md) | npm package, packaging, and the staff UI bell | | [Integrating a new service](/platform/platform-services/notifications/integrating.md) | Backend send and UI inbox for a new app | | [Implementing a send](/platform/platform-services/notifications/implementing.md) | How a service calls the connector | | [Workflows and payloads](/platform/platform-services/notifications/workflows-and-payloads.md) | Registry and AWE events, recipients, and template fields | | [Deployment](/platform/platform-services/notifications/deployment.md) | Helm values, secrets, and Docker build args | | [Notification provider](/platform/platform-services/notifications/notification-provider.md) | Index of the notification provider pages | | [Novu](/platform/platform-services/notifications/notification-provider/novu.md) | Default install, secrets, workflow seeding, and email and SMS links | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openg2p.org/platform/platform-services/notifications.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.