Skip to main content
This document provides two key workflows for the Notification Service:
  • Notification Onboarding Workflow
  • Notification Processing Workflow
Each workflow is explained in detail and references a diagram illustrating the sequence of actions and system interactions.

​
1. Notification Onboarding Workflow

Purpose
The onboarding workflow enables a client (consumer) to register or onboard new Products and optionally Organizations under these Products. This process is essential for generating the unique API credentials (keys and IDs) required for all further Notification Service interactions. Key Steps
1

Create Product

The client submits a request to add a new Product.
2

Persist Product Data

The Notification Service stores the Product details and returns a unique Product API Key and Product ID.
3

Check for Organizations

If the Product requires Organizations (typical in B2B scenarios), the client can create one or more Organizations under that Product.
4

Organization Onboarding

The service then stores each Organization’s details, linking them to the Product, and generates Organization credentials (Org API Key & Org ID).
5

Ready to Use

With credentials generated, the client can start using the notification endpoints.
Diagram

​
2. Notification Processing Workflow

Purpose
Once the client has valid Product and/or Organization API keys, they can trigger notifications to be sent through various channels (Email, SMS, Push, etc.). This workflow shows how the system validates credentials, processes notifications (including queueing), and handles success/failure outcomes. Key Steps
1

Trigger API

The client calls the Notification Service’s trigger endpoint, supplying valid API keys and the notification payload.
2

Validation

The service checks the Product/Org API keys for authorization and also validates the request body.
3

Audit Logging

Key events (triggering, processing, delivery) are recorded for traceability.
4

Queueing

The message is placed into a queue with the appropriate priority, returning a Request ID for client tracking.
5

Delivery Attempt

The service (or a worker) attempts delivery. Success or failure is noted in the audit logs.
6

Retry & Error Handling

On failure, the system retries according to a predefined policy before ultimately logging the final outcome.
Diagram

​
Final Notes

  • Security & Authorization: Always ensure valid API keys are included with each request.
  • Multi-Tenancy: B2B products may use multiple Organizations, while B2C products typically do not require Organizations.
  • Audit Trails: Every major event (creation, updates, notification triggers, retries) is recorded to facilitate debugging and compliance.
  • Scalability: Leveraging a queue-based architecture ensures high throughput and fault tolerance for large-scale notification deliveries.
By following these two workflows, you can seamlessly onboard your Products and Organizations and reliably send notifications to your users. If you have any questions or need further assistance, please let us know.