Notification infrastructure: what it is and what it takes.
Notification infrastructure is everything between "something happened in your product" and "the right person saw a message about it". It decides who gets told, on which channel and when, sends the message through a provider, and records what happened.
A single email call is easy. The work is in the parts around it. This page lists those parts, what each one has to do, and when it makes sense to build them yourself instead of using a hosted service.
What notification infrastructure is
Your application emits an event. The infrastructure turns that event into messages: it looks up the recipient, applies their preferences, picks the channels, renders a template, waits or batches if the workflow says so, hands the message to a delivery provider, and keeps a record of the result.
The product code keeps one job, which is saying that something happened and to whom. Everything after that line belongs to the infrastructure. The parts below are that pipeline, in the order a message passes through it.
The parts, and what each one has to do
| Part | What it has to do | In Notifly |
|---|---|---|
| Channel providers and routing | Send email, SMS, push and chat through providers such as SendGrid, Twilio, FCM or Slack, and route each step to the right one. | Five channels and 70+ provider integrations behind one API. You connect your own provider credentials and pay those providers directly. See Channels and providers and the integrations. |
| Workflow engine | Hold the sequence of steps for one notification, with delay, digest and conditions, and run it asynchronously so the caller does not wait. | Each notification is a workflow of channel steps, started by one API call and run by delivery workers on Redis-backed queues. See Workflows, step conditions and digest notifications. |
| Subscribers and preferences | Know who a recipient is, how to reach them, and which channels and workflows they have switched off. | A subscriber record per recipient, with per-channel preferences the workflow checks at delivery time, and topics for fan-out. See Subscribers. |
| In-app inbox | Store a feed per user, track read and archived state, and push new items to the open page. | A real-time feed delivered over websockets, with an embeddable Inbox component for React. See the React notification inbox and the in-app inbox docs. |
| Templates and translations | Render the same notification in each recipient's language, with the same content in preview and in delivery. | {{t.key}} placeholders resolve by subscriber locale at render time, and the preview uses the same renderer as delivery. Translations are on the Team plan and above. |
| Delivery logs and retries | Show what happened to each message, and survive a provider or worker failing mid-send. | The pipeline runs queues and retries, and a searchable activity feed records each step. Retention is 24 hours on Free, 7 days on Pro and 90 days on Team. |
| Rate limits and idempotency | Stop a retry or a loop from sending the same message twice, and protect the system from a burst of triggers. | Send an Idempotency-Key header and a replay within 24 hours returns the original response. Each environment has a token-bucket rate limit, reported in RateLimit-* headers. See REST API. |
What the application sends
With the infrastructure in place, the product's side shrinks to one request: the workflow to run, the recipient and a payload. The Idempotency-Key header makes a retried request safe.
curl -X POST https://api.notifly.io/v1/events/trigger \
-H "Authorization: ApiKey $NOTIFLY_SECRET_KEY" \
-H "Idempotency-Key: 0d1f6c1e-8f2a-4b0c-9d3e-5a6b7c8d9e0f" \
-H "Content-Type: application/json" \
-d '{"name":"<workflow-id>","to":{"subscriberId":"<subscriber-id>"},"payload":{"body":"Your build finished"}}'Everything else, including channels, timing, preferences and delivery, is set in the workflow and the recipient's subscriber record. Getting started goes from a workspace to a first triggered workflow.
Build it or use a hosted service?
Most teams start by building: one provider SDK, one template, a function called from a request handler. That is the right size for a single email. The cost shows up later, as channels and rules accumulate:
- Each channel adds a provider integration. Credentials, payload formats, bounces, token expiry and provider outages differ per channel.
- Preferences and timing become product features. Per-channel opt-outs, digests and delays need a data model and send-time logic, and every new notification has to respect them.
- Failures need a place to be seen. Without delivery logs and retries, a message that never arrived is a support ticket with nothing to look at.
- It needs an owner. Queues, workers and websockets have to be run, patched and watched by someone.
Build your own when you send one kind of message on one channel, when the data cannot leave your own systems, or when you need behaviour no service offers. Use a hosted service when you send across several channels, when users set their own preferences, or when you would rather ship product features than run a delivery pipeline. Compare Notifly with other notification platforms.
Start small
- Pick one notification. A welcome email or a build-finished alert is enough to see the whole path.
- Model it as a workflow. One email step, then add an in-app or chat step when you need it.
- Trigger it from your backend. Use the request above, with an
Idempotency-Key. - Check the activity feed. Confirm each step ran before you add a second notification.
Plans and what they include are on the pricing page.
Frequently asked questions
What is notification infrastructure?
The systems between an event in your product and a message reaching a person: recipient and preference data, a workflow engine, delivery providers for each channel, an in-app inbox, templates, delivery logs and the limits that keep it safe to retry.
How is notification infrastructure different from an email API?
An email API sends one message through one channel. Notification infrastructure sits above providers and decides which channels a recipient gets, when, in which language and with what batching, then records the outcome. It can use an email provider such as SendGrid as one of its channels.
What does notification infrastructure include?
Channel providers and routing, a workflow engine with delays and digests, subscriber and preference management, an in-app inbox, templates and translations, delivery logs with retries, and rate limits with idempotency. Each is covered in the table above.
When should I build it myself?
When you send one kind of message on one channel, when notification data must stay in your own systems, or when you need behaviour a service does not offer. The cost grows with channels, user preferences and the need to see why a message did not arrive.
Which channels does Notifly cover?
Email, SMS, push, chat and in-app, through 70+ provider integrations on every plan, including Free. You connect your own provider credentials, so delivery is billed by those providers.
Do I have to run any servers for Notifly?
No. The API, delivery workers, websockets and datastores run as a hosted service operated by Devino. Your application sends requests to api.notifly.io.
How do I avoid sending the same notification twice?
Send an Idempotency-Key header on the trigger request. A replay within 24 hours returns the original response instead of triggering again, and a different body under the same key is rejected.
One workflow for in-app, email, SMS, push and chat.
The free plan includes 10,000 events per month, no card needed.