Policies decide where each event goes.
Business events map to channels, templates, and binding sets without hardcoding provider behavior inside the upstream service.
NotifyHub centralizes templates, providers, routing, callbacks, retries, and observability so upstream services can stay simple and generic.
Upstream systems send canonical requests. NotifyHub owns the delivery mechanics, provider logic, and the long tail of notification operations.
Business events map to channels, templates, and binding sets without hardcoding provider behavior inside the upstream service.
Provider callbacks update state in the control plane and can be forwarded to subscribed systems as durable webhooks.
Retries, health, and observability are first-class, so the platform remains predictable as volume grows.
The docs are written as a product site: getting started, architecture, providers, deployment, and operations all live in distinct paths.
Client onboarding, auth headers, and the order to create initial records.
02The runtime shape, data flow, and model relationships behind the platform.
03End-to-end send, callback, and reply behavior for each supported channel.
04How to run the stack locally and ship it to Kubernetes or AWS.
05How to create provider accounts, templates, policies, and callback routes.
The client posts a single notification intent, not a provider-specific payload.
Templates, preferences, bindings, and provider accounts are resolved centrally.
Provider credentials stay inside the platform boundary and are resolved at runtime.
Status changes and replies return as normalized events the client can consume.