One event language
Product teams trigger named events while the service owns channel and delivery policy.
Product messaging operations
Reach every customer through one delivery system.
Notifications gives product and operations teams one source-owned domain for event routing, templates, delivery policy, retries, and customer-visible message history.
Inspect the published API contractNotifications domain
Tenant-aware delivery workflow
Operational workspace
One event enters. Every delivery decision stays visible.
Payment confirmed
Event accepted with tenant and recipient context
Channel policy
Preferences, locale, quiet hours, and TTL evaluated
Provider delivery
Email, SMS, push, or webhook adapter selected
Delivery history
Attempt state retained for support and product workflows
Tenant scopedRetry awareProvider adaptable
- Lifecycle
- Available · v1
- Interfaces
- REST · Connect/gRPC · MCP via Agent Gateway
- AWS path
- Design-partner pilot
- Commercial basis
- Perpetual source license
Product outcome
Product messaging should behave like a system, not a collection of provider calls.
As products grow, every team starts sending email, SMS, push, and webhooks differently. Notifications keeps product events, customer preferences, tenant context, and delivery outcomes behind one explicit boundary your team can operate.
Customer-aware delivery
Tenant context, quiet hours, locale, and user preferences can shape each delivery path.
An inspectable history
Operations can follow a message from accepted event to provider response and final state.
01 / Domain capabilities
A complete Notifications boundary, not a thin endpoint wrapper.
Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.
01
Event catalog and routing
Define product events once, validate their payloads, and route them to the right channels without embedding provider logic in every service.
02
Localized templates
Keep message content, locale variants, and rendering inputs inside a reviewable product contract.
03
Delivery policy
Apply preferences, quiet hours, schedules, TTL, and tenant-specific rules before a message leaves the system.
04
Retries and delivery history
Track attempts and provider outcomes so operations can investigate failures and retry through controlled workflows.
02 / Product workflow
One path from product intent to an enforceable result.
The overview stays business-readable. The documentation and published contract contain field-level detail.
- 01
Trigger the event
A product service submits the event name, tenant, recipient, payload, and idempotency context.
- 02
Resolve policy
Notifications checks the catalog, template, recipient preferences, timing, and eligible channels.
- 03
Deliver through adapters
The service renders the message and hands it to the configured provider path.
- 04
Inspect the outcome
Product and support workflows can read delivery state without querying provider dashboards.
03 / Technical depth
Clear operational boundaries for the team that owns it.
Support is 12 months of updates and support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.
Trigger a product notificationHTTP / JSON
POST /notify.v1.NotifyService/TriggerEvent
Authorization: Bearer $TOKEN
Content-Type: application/json
{
"event_name": "billing.payment_successful",
"tenant_id": "company_72",
"user_id": "user_19",
"payload": {
"plan_name": "Growth"
},
"idempotency_key": "event_8f4b"
}Event contract
Named events and validated payloads keep producers independent from channel implementation.
Delivery state
Attempts, provider responses, and final state remain queryable for the owning tenant.
Provider boundary
Email, SMS, push, and webhook adapters can evolve without changing product event calls.
04 / Where it fits
Notifications supports products with real tenant and commercial complexity.
These are product patterns, not customer case studies or measured outcomes.
Lifecycle communication
Send invitations, onboarding prompts, account changes, and security notices through a consistent customer-aware policy.
Commercial workflows
Turn entitlement, subscription, and usage events into messages without coupling billing logic to a provider.
Operational alerts
Route workflow changes and exception states to the right recipient and preserve the delivery trail for support.
Ownership model
Own the service without owning every release problem.
The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.
01
Licensed Go source for the notification domain
02
Published REST and Connect/gRPC contract
03
Customer-selected providers and customer-cloud deployment
04
Optional adapters or domain channels scoped as custom work
Published API evidence active
Customer-cloud deployment path
Depends on identity
Notifications architecture review
Put Notifications behind a product boundary your team can own.
Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.
Frequently Asked Questions
Common Questions & Answers
Everything you need to know about integrating and hosting this Launch Rail service.