NotifHQOrder Shipped
The order has left. The tracking link is the entire point of the message.
Customer and machine communication infrastructure
One API for everything you have to tell somebody.
Your software. Your equipment. One place that governs both.
Send transactional notifications, take readings from the machines you run, honour every preference and quiet hour, render approved templates and prove exactly what happened — on one set of rules, for the order that shipped and the freezer that failed alike.
API · SDK · Webhooks · Managed delivery · Alerting · Preferences widget
await notifhq.notify("commerce.order.shipped", { recipient: "cus_1284", order_id: "ORD-9218", tracking_url: "https://…", });
What happens next
✓Validate
✓Resolve contract
✓Resolve preference
✓Resolve policy
✓Render
✓Deliver
Evidence
14:02:11Requested
14:02:11Validated
14:02:11Policy allowed
14:02:12Template rendered
14:02:12Sent
You should not have to build this again
Sending the message is the easy part.
The first notification takes an afternoon. Then comes everything around it.
Send
1Templates
2Preferences
3Reliability
4Visibility
5Governance
6Correctness
NotifHQ packages these behind one communication layer.
What you get instead
One communication layer, declared once.
Everything above is the same job done again in every product that sends anything. NotifHQ does it once, as a contract rather than a codebase: you declare what a message is, and we own the templates, the preferences, the consent, the retries, the holding back, the evidence and the deleting — behind one API.
Yours
You declare
One kind of message, what it has to carry, who may receive it and on which channels. 62 are declared already.
NotifHQ owns
We own
Writing the message, checking preferences and consent, respecting quiet hours, retrying, holding back, tracking where it got to and keeping the evidence — 12 capabilities, each with its stages written down.
Yours
You get back
A timeline that answers 'did they get it?' without a provider's logs, and 71 reason codes so every refusal explains itself.
Nothing here is a framework you assemble. It is a contract you publish.
How it works
Four steps, and the fourth is reading the answer.
There is no SDK ceremony and no queue to run. You declare what a message is once, install or write its contract, call one endpoint, and read back what happened to it.
Your event
Declare the notification type
A name, the details it has to carry, who may receive it and on which channels. 62 are written already, so most teams start by picking one rather than writing one.
Install a pack, or publish your own contract
36 packs install 205 types with 205 published contracts. A contract checks what you sent before a single word is written.
Call POST /v1/notify
One call. Behind it: sorting sensitive data, applying your rules, checking preferences and consent, picking the template, choosing the route, handing it over and keeping the evidence — none of which appears in your code.
Read the timeline
Delivery state, engagement and every policy decision come back as events, with 71 reason codes so a refusal explains itself instead of failing silently.
Evidence you can show
Nothing in this list is a future step. Every count on this page is read from the registries at build time.
More than a send endpoint
Your application owns the event. NotifHQ owns the communication.
Your application describes what happened. NotifHQ decides how that communication is produced, whether it is permitted, how it is rendered, where it goes and what is recorded.
Your product emits4
- commerce.order.shipped
- billing.payment.failed
- auth.identity.otp
- security.login.new_device
NotifHQ owns12
SendingData handlingTemplatesPreferences and consentDeliverySearchInbound emailTeam InboxDocumentsReportingComplianceAlerting
Reaches people on3
- In-app inbox
- Webhook
3 channels, each with its own delivery states, evidence and preference rules.
Typed notifications
Stop sending arbitrary blobs.
Define a communication once. We then know what it has to carry, which channels it may use, whether someone can opt out of it, how repeats are collapsed, and how long it stays worth sending.
Order Shipped
commerce.order.shipped
The order has left. The tracking link is the entire point of the message.
- Must carry
- order_id, tracking_url
- May carry
- carrier_label, estimated_delivery, item_count
- Can be opted out of
- Yes
- Repeats
- collapsed once per change of state
- Worth sending for
- 7 days
Allowed on
EmailIn-app inbox
2 more the contract permits and we do not carry yet
A message arrives, and is measured against it
order_id
asked for, and present
tracking_url
asked for, and present
internal_cost
not asked for — dropped before anything stores it
customer_name
asked for, required, missing
62 kinds of message are written down today, across 20 parts of a business.
The rule everything else follows
Asked for is not sent. Sent is not delivered. Delivered is not read.
Most tools collapse all of that into one green tick. We keep the steps apart — in the API, in the numbers you report on, and in the history of every single message — because the moment they merge you can no longer answer the only question that matters when a customer says they never got it.
Asked for
You asked for it. Nothing has been decided, written or sent.
FailedCancelled
Checked
Checked against what your contract says this message has to carry.
Failed
Tidied
Tidied up, trimmed to what is needed, and labelled.
Held backFailed
Allowed
Your rules allowed it, and whatever they required is on the record.
Held backRan out of time
Queued
Waiting its turn with the part that does the sending.
Ran out of timeCancelledFailed
Written
One specific version of your template produced this exact message.
Failed
Handed over
Handed to whoever actually carries it — your mail provider, or the endpoint you nominated.
Failed
Sent
The provider accepted it. It has left us. It has not arrived.
Failed
Delivered
The destination accepted it. Nobody has looked at it yet.
9 steps between asking for a message and it arriving, and 4 ways it can stop short. Whichever way it stops, the reason is recorded and you can go and read it.
An “open” is a hidden image being fetched, and mail apps fetch, cache or block those on their own. So we call it an open observation and name the number for what it actually measures.
Evidence, not assertion
“I never got the email.”
Answer it from stored state, in seconds, without opening a transport's logs and hoping they are still in retention. Every state transition writes an append-only, hashed evidence row carrying two separate times: when the world produced the signal, and when we recorded it.
Notification timeline
ntf_01J8ZQK5X7B3N9WM4TCPRVDFGH
- 14:02:11 Requested
- 14:02:11 Checked against the contract
- 14:02:11 Preference permitted
- 14:02:11 Policy allowed evidence
- 14:02:12 Template rendered
- 14:02:12 Transport accepted evidence
- 14:02:15 Delivered evidence
- 14:06:42 Click observed observed
81 event families emit evidence before anything reacts to it.
Do not start from a blank screen
Install communication patterns, not a folder of HTML files.
A pack installs the message types, what each must carry, the contracts, the templates, the routing, the opt-out categories and the reporting together — so a team starts with a shared vocabulary instead of assembling one.
Banking
one install
14
Message types, named and defined
14
What each message must carry
14
Rules per message — channels, consent, how long it stays valid
23
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
2
Opt-out groups a recipient can control
9
Things worth reporting on
3
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
9
Labels used across the reports
2
Tags, for finding this again
One-Time PasscodeVerify Contact ChannelPassword ResetLow BalanceCard BlockedCard Transaction FlaggedDirect Debit ChangedOverdraft UsedPayment FailedPayment ReceivedPayment SentStatement AvailableSuspicious Activity DetectedSign-in From a New Device
Cold Chain
one install
1
Message types, named and defined
1
What each message must carry
1
Rules per message — channels, consent, how long it stays valid
1
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
1
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
2
Physical conditions to watch for
Cold Chain Excursion
Construction
one install
9
Message types, named and defined
9
What each message must carry
9
Rules per message — channels, consent, how long it stays valid
14
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
2
Opt-out groups a recipient can control
3
Things worth reporting on
5
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
8
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedDocument RejectedInvoice ApprovedInvoice Needs ReviewService IncidentIncident ResolvedScheduled Maintenance
eCommerce
one install
13
Message types, named and defined
13
What each message must carry
13
Rules per message — channels, consent, how long it stays valid
15
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
8
Things worth reporting on
4
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
7
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedOrder CancelledOrder ConfirmedOrder DeliveredOrder ShippedRefund Issued
Education
one install
3
Message types, named and defined
3
What each message must carry
3
Rules per message — channels, consent, how long it stays valid
3
Ready-made drafts, waiting for your approval
2
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
2
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile Changed
Events
one install
4
Message types, named and defined
4
What each message must carry
4
Rules per message — channels, consent, how long it stays valid
4
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
2
Things worth reporting on
3
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
5
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedEvent Ticket Issued
Fintech / Payments
one install
19
Message types, named and defined
19
What each message must carry
19
Rules per message — channels, consent, how long it stays valid
29
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
2
Opt-out groups a recipient can control
13
Things worth reporting on
3
Groupings, so reporting adds up
4
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
9
Labels used across the reports
2
Tags, for finding this again
One-Time PasscodeVerify Contact ChannelPassword ResetLow BalanceCard BlockedCard Transaction FlaggedDirect Debit ChangedOverdraft UsedPayment FailedPayment ReceivedPayment SentStatement AvailableInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedSuspicious Activity DetectedSign-in From a New Device
Healthcare
one install
13
Message types, named and defined
13
What each message must carry
13
Rules per message — channels, consent, how long it stays valid
21
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
6
Things worth reporting on
2
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
7
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedAppointment BookedAppointment CancelledAppointment MissedAppointment ReminderAppointment RescheduledPrescription ReadyRepeat Prescription DueReferral MadeResult AvailableResult Needs Discussion
Hospitality
one install
4
Message types, named and defined
4
What each message must carry
4
Rules per message — channels, consent, how long it stays valid
4
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
3
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
6
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedReservation Confirmed
Insurance
one install
9
Message types, named and defined
9
What each message must carry
9
Rules per message — channels, consent, how long it stays valid
16
Ready-made drafts, waiting for your approval
5
Where each kind goes by default
2
Opt-out groups a recipient can control
5
Things worth reporting on
2
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
9
Labels used across the reports
2
Tags, for finding this again
Document RejectedInvoice ApprovedInvoice Needs ReviewClaim Needs InformationClaim ReceivedClaim SettledPolicy IssuedPolicy LapsedRenewal Due
Laboratory
one install
1
Message types, named and defined
1
What each message must carry
1
Rules per message — channels, consent, how long it stays valid
1
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
1
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
2
Physical conditions to watch for
Instrument Out of Range
Logistics
one install
6
Message types, named and defined
6
What each message must carry
6
Rules per message — channels, consent, how long it stays valid
8
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
3
Things worth reporting on
2
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
7
Labels used across the reports
2
Tags, for finding this again
Order CancelledOrder ConfirmedOrder DeliveredOrder ShippedRefund IssuedDelivery Exception
Manufacturing
one install
1
Message types, named and defined
1
What each message must carry
1
Rules per message — channels, consent, how long it stays valid
1
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
1
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
2
Physical conditions to watch for
Machine Fault
Marketplace
one install
10
Message types, named and defined
10
What each message must carry
10
Rules per message — channels, consent, how long it stays valid
11
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
8
Things worth reporting on
4
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
7
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedBooking ConfirmedPayout Failed
Media / Publishing
one install
10
Message types, named and defined
10
What each message must carry
10
Rules per message — channels, consent, how long it stays valid
11
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
2
Opt-out groups a recipient can control
8
Things worth reporting on
4
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
8
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedWe Miss YouWelcome
Physical Security
one install
1
Message types, named and defined
1
What each message must carry
1
Rules per message — channels, consent, how long it stays valid
1
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
1
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
2
Physical conditions to watch for
Access Point Forced
Professional Services
one install
11
Message types, named and defined
11
What each message must carry
11
Rules per message — channels, consent, how long it stays valid
15
Ready-made drafts, waiting for your approval
5
Where each kind goes by default
2
Opt-out groups a recipient can control
7
Things worth reporting on
4
Groupings, so reporting adds up
3
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
9
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedDocument RejectedInvoice ApprovedInvoice Needs Review
Property
one install
3
Message types, named and defined
3
What each message must carry
3
Rules per message — channels, consent, how long it stays valid
3
Ready-made drafts, waiting for your approval
2
Where each kind goes by default
1
Opt-out groups a recipient can control
1
Things worth reporting on
2
Groupings, so reporting adds up
1
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
4
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile Changed
SaaS
one install
13
Message types, named and defined
13
What each message must carry
13
Rules per message — channels, consent, how long it stays valid
17
Ready-made drafts, waiting for your approval
4
Where each kind goes by default
1
Opt-out groups a recipient can control
10
Things worth reporting on
4
Groupings, so reporting adds up
4
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
8
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedOne-Time PasscodeVerify Contact ChannelPassword ResetInvoice IssuedPayment ReceivedPayment FailedSubscription CancelledSubscription RenewedSuspicious Activity DetectedSign-in From a New Device
Sports
one install
4
Message types, named and defined
4
What each message must carry
4
Rules per message — channels, consent, how long it stays valid
4
Ready-made drafts, waiting for your approval
3
Where each kind goes by default
1
Opt-out groups a recipient can control
2
Things worth reporting on
3
Groupings, so reporting adds up
2
Reserved name spaces, so two teams cannot clash
1
Embeddable screens, ready to drop in
5
Labels used across the reports
2
Tags, for finding this again
Team InvitationAccess RemovedProfile ChangedEvent Ticket Issued
Payment Failed
A charge did not succeed and the recipient's service is at risk.
One-Time Passcode
A short-lived passcode proving control of a channel. The single most latency-sensitive message the platform carries.
Sign-in From a New Device
Tells a recipient their account was accessed from somewhere new, and gives them a way to act.
36 packs: 20 sector, 13 functional and 3 compliance.
Respect preferences automatically
Your code should not branch before every send.
Preferences, consent, hold-backs, quiet hours and sending limits are decided as part of sending. You call the same endpoint every time.
emailin appwebhook
Account and orders
always sent
Service updates
opt-out honoured
Replies to you
always sent
Legal notices
always sent
Product news
consent required
always sent
3 of 5
You asked for it, or the law requires it. There is no switch.
consent required
1 of 5
Nothing goes out until the person has said yes.
opt-out honoured
1 of 5
Goes out until the person says stop, then never again.
Quiet hours defer
They do not drop. Unless the message expires first — in which case it is marked expired, with evidence.
Held back is a result, not a gap
Never an error, and never a message that quietly vanishes. Every one carries a reason you can read.
Erasure is absolute
No contract, purpose or category overrides it.
71 reasons on the list, so “why didn’t this go out?” is answerable in a support conversation without anybody reading code.
Replies come back
A shared inbox on the same contracts that sent the message.
A notification you cannot reply to is a broadcast. Replies land on the record of the send that prompted them, and a team works them there.
- 4 queues
- Unassigned · Open · Waiting · Resolved
- 3 panes
- Queues · Tickets · Conversation
- 4 conversations
- Re: Order Shipped · Re: Payment Failed
- 2 messages in the thread shown
- each one on the same record as the send that started it
One recipient record
The person replying is the person your preference centre and your do-not-contact list already know.
Worked by a team
Assignment, status and history, on the same record as the message that started it.
Governed identically
What arrives is sorted, kept and deleted on exactly the rules that govern what leaves.
Machines as well as people
A patient monitor, a CNC controller, a camera on a gate, a cold store.
Most communication platforms assume the thing worth telling somebody about happened inside a web application. A great deal of it happens on a ward, a shop floor, a yard, a laboratory, or in the back of a trailer — and the people who need to hear about it have the same phones, the same quiet hours and the same right to an explanation as your customers.
Device
SensorMachineControllerRobotAutonomous vehicleVehicle3D printerIndustrial equipmentAccess controlCameraApplianceHardwarePatient monitorTherapy deviceImplantDiagnostic systemMedical equipment
Legal entity
CompanyPublic bodyCharity
Software agent
Autonomous agentBot
Human
Person
Watched by a pack you can install today
23 declared classes in total. The rest are classes you can declare and report observations against now.
Declare the things you track and report against them. Nothing here asks you to replace a sensor gateway, a building management system or a fleet platform: they already speak HTTP, and this is what happens after they do.
Machines as well as people
The freezer cannot tell you it is failing. This tells the person who can act.
A condition becomes true about something you track — a cold store above its range, a spindle faulted, a barrier forced — and the work is not sending a message. It is deciding whether this is the four-hundredth time this hour, who hears it, what happens when nobody answers, and what you can show an auditor afterwards. Report every reading; deciding what is worth waking somebody for is our job, not yours.
A reading from your sensors
Report it, however often it happens
Every reading, through one endpoint. A cold-store door stands open through every delivery and a camera on a working yard sees hundreds of people a day — you do not have to know which of those matters before you send it.
What is worth waking somebody for
5 ways to hold one back — debounce, occurrence threshold, repeat after, aggregate, flap detection — so a door opening is not a temperature problem, one unresolved fault is not a message per reading, and an unstable sensor is reported once as unstable rather than fifty times as a failing process.
Severity decides who is woken
4 severities: critical, high, medium, low. A refrigeration failure and a mileage threshold come off the same trailer, and only one of them should reach anybody at three in the morning.
Nobody answers, so it climbs
Tiers you declare, on a timer, each one saying in advance whether it may be contacted out of hours. When every tier has been tried and nothing came back, that is its own event — because an alert nobody ever answered is the thing you most need telling.
And it is answerable afterwards
4 states kept apart: raised, acknowledged, cleared, closed. Cleared means the source said it ended; closed means a person ended it while the source said nothing. An auditor asking about an excursion needs to know which.
Somebody answered, and it is on the record
4 industry packs install 8 conditions, each with the quiet rules that kind of equipment actually needs, across 23 declared classes of thing.
Installed, not configured
A probe that went quiet. A press that faulted. A gate forced in the middle of the night.
Each of these arrives with the quiet rules that kind of equipment actually needs, worked out by somebody who has been woken up by it. Install the pack and the condition, its severity and its quiet rules come with it.
Cold Chain
Temperature outside safe rangeAppliancecritical
Has to hold for 15 minutes before it counts; then at most one message every 30 minutes.
Probe stopped reportingSensorhigh
Has to hold for 30 minutes before it counts; then at most one message every 6 hours.
Manufacturing
Machine stopped or faultedMachinehigh
At most one message every 15 minutes.
Signal is unstableSensormedium
8 flips inside 10 minutes is reported once, as unstable.
Physical Security
Opened without authorisationAccess controlcritical
At most one message every 5 minutes.
Detections in a restricted areaCameralow
Needs 3 inside 5 minutes; batched every 15 minutes.
Laboratory
Outside qualified rangeAppliancecritical
Has to hold for 5 minutes before it counts; then at most one message every hour.
Calibration overdueHardwaremedium
At most one message every 24 hours.
Beyond these, every declared class is yours to track: report observations against a patient monitor, a diagnostic system or an autonomous vehicle and the same quiet rules, severity and chasing apply. A pack is a head start, not the boundary.
Answered, or ended
“It came back to temperature” and “somebody stopped looking at it” are not the same answer.
Most alerting tools have one way to finish: resolved. So a freezer that recovered and a freezer somebody muted at two in the morning leave the same trace, and three months later nobody can tell you which happened. Acknowledging is not fixing either — it stops the chasing and nothing else — and a tool that treats it as resolution is how a dashboard shows green while equipment is still failing.
raisedentry
The condition became true and nobody has taken it. The entry state, and the only one from which escalation runs.
→ acknowledged · cleared · closed
acknowledgedopen
A person or an agent has said they have it. The condition may still be true — acknowledging is not fixing — so this stops the chasing and nothing else. Conflating it with resolution is how a board shows green while a freezer is still warming.
→ cleared · closed
clearedthe source said so
The source reported that the condition is no longer true. Observed, not asserted: the freezer came back to temperature and said so.
closeda person said so
A person ended the alert without the source clearing it — a false positive, a known fault, equipment taken out of service. Asserted, not observed, and never merged with 'cleared'.
4 states, and the last 2 are kept apart on purpose: one is what the equipment reported, the other is what a person decided. Nothing returns to raised — acknowledging stops the chasing and nothing else.
Which one happened is a question an auditor will ask, so it is a state the platform keeps rather than a note somebody remembered to write.
One roof
The order that shipped and the freezer that failed are the same kind of problem.
Both are a fact that became true, a decision about who should hear it, a message somebody either received or did not, and a question somebody asks three months later. Running those as two systems means two sets of preferences, two quiet-hours policies, two audit trails and two answers to what happened — and the second system is always the one nobody governed.
What your software does
An order ships
An invoice falls due
A document arrives
A customer replies
What your equipment does
Sensor reports a readingMachine reports a readingController reports a readingRobot reports a reading
One place, one set of rules
resolve contractresolve preferenceresolve policyrenderdeliver
A message somebody receivesOn the channel they chose, in the words you published, or not at all with a reason.
A record you can show5 ways to hold one back and every decision kept, so a silence is as checkable as a send.
The same contracts, the same preferences, the same rules and the same evidence, whether it came from your software or from your equipment.
Where it is, and how you know
An alert that cannot say where it came from is a search party.
A cold store is over temperature. Which one, in which building, on which site, and who is the person nearest it right now? Somewhere is a place you declare. Somewhere else is a position something reported, with an accuracy and a source attached. Keeping those apart is the difference between routing an engineer to a depot and routing them to a trailer that left it two hours ago.
A thing, and a claim about where it is
A place is declared, and it nests
7 kinds — site, building, area, production line, zone, asset group, mobile — because a fault on a production line is not the same fact as a fault at the site containing it, and an escalation that cannot tell them apart wakes the wrong person. A place holds other places, so asking about a site answers for everything inside it.
A position is observed, and it is not the same thing
6 sources — satellite (gnss), satellite with real-time correction, cellular, wi-fi, beacon, declared — each reported with its own accuracy. A declared position is somebody's assertion; a satellite fix is a measurement; a beacon says only that a thing is near another thing. Collapsing the three into one coordinate loses the part that decides whether you can act on it.
A place that moves is still a place
A trailer, a container, a vessel: it contains equipment, it has a position that changes, and the equipment inside it does not move relative to it. That is one kind of place rather than a special case bolted onto the others, which is why a refrigeration excursion on the road reads the same way as one in a depot.
And it is on the alert, not looked up afterwards
The position travels with the thing that raised the alert, so the record an auditor reads later says where it happened — not where the asset register said it was supposed to be.
The person nearest it, told
Both are API objects, not attributes: POST /v1/locations declares a place, and GET /v1/subjects/{id}/positions is where a thing has been.
Process first, store less
What you send is trimmed before anything stores it.
The same step runs over everything that arrives — messages, inbound mail, attachments, ticket replies, webhook bodies. Anything your contract did not ask for is dropped before it is written down, so it never needs classifying and never needs protecting.
What you sent
order_id
ORD-9218
declared
tracking_url
https://track.example/ORD…
declared
internal_note
customer is a VIP
undeclared
card_number
[16 digits redacted]
blocked
Stored
order_id
ORD-9218
indexed
tracking_url
https://track.example/ORD…
excluded
Two fields stored. One dropped before persistence. One blocked and quarantined, never sent.
Detection gives the same answer every time, and it is the answer that counts. A card number is caught by doing the arithmetic, not by looking similar — an order reference that looks like a card is not one, and an embedding never gets a say in a security decision.
Measured, not claimed
Every policy decision, in under 1 millisecond.
Consent, hold-backs, quiet hours, where the person is, what industry you are in, and every compliance pack you have installed — 30 policies can bear on a single send, and the ones that apply to your workspace are weighed into one answer. Not a claim somebody typed: a real measurement runs on every build and fails it if the number slips.
Deciding whether this message may be sent
1ms 99 in 100
Every rule that could stop this message — consent, hold-backs, quiet hours, where the person is, your industry, and every compliance pack you have installed — weighed into one answer.
The thing that would break it. One lookup inside one rule would end it. That is why a real measurement runs on every build and refuses the build if it goes over.
Re-measured over 50,000 runs on every build, against the heaviest set-up — every compliance pack installed. Over budget, the build fails.
The whole request, start to finish
250ms 99 in 100
Everything around that decision: checking your key, finding the message type and the person, reading their preferences, writing the message and handing it to the sender.
The thing that would break it. One check can never be sped up: whether this person has asked you to stop. A cached answer there would send one more message to somebody who opted out, so it is read fresh every time.
Published, not promised. This is what it costs today.
Measured over 50,000 runs against the heaviest set-up — every compliance pack installed — rather than the lightest.
Drop-in customer experiences
Ship the interface, not just the send.
Preferences, consent and data requests your users control, embedded in your product and enforced by the same thing that does the sending. Each renders in a shadow root, so your CSS cannot break it and its styles cannot leak into your page.
The workspace API key never reaches the browser. Widgets authenticate with a short-lived, recipient-scoped token minted server-side — and the widget refuses a token that looks like an API key.
API first
Your integration should look this small.
One call from you. Everything below is ours, and none of it appears in your code or your on-call rota.
Your code
POST /v1/notifications
one call
Ours
1
Take the request
1 event
2
Check it is well formed
3
Find the contract
4
Tidy and label
3 events
5
Work out who it is for
6
Check what they agreed to
7
Apply your rules
2 events
8
Write the message
1 event
9
Pick how it travels
1 event
10
Hand it over
5 events
11
Record what happened
12
Count it
13
Tell your systems
13 stages behind one call. They emit 13 events between them, and at 10 of them a message can stop for a reason you can read. None of it is in your code.
Errors you can branch on
Every failure names a registered reason code and its decision. A recipient who opted out is their choice, not your bug, and the SDK tells you which.
Retries that are safe
A policy denial is never retried — it would produce the identical denial forever and bury the outcome.
Signed webhooks
Timing-safe checking with a time limit, so a captured request cannot be replayed forever.
137 endpoints and 174 operations, generated from the same document the SDK is built from.
Compliance packs
Controls in the pipeline, not badges on a page.
Compliance packs are sets of controls that run in the same pipeline as your sends — sorting sensitive data, spotting it, keeping less of it, hiding it, deleting it on time and answering a person who asks what you hold. The control happens before anything sensitive reaches a log, a search index or a report.
Executable controls installed by each compliance pack
GDPR
27 controls
3
Kinds of sensitive data it knows to look for
3
Checks that run on every message
3
Rules for keeping less than you were sent
5
Rules applied to every send
5
How long each kind of record is kept
4
Evidence it records for every send
2
Ways to get your records out
2
Routes for a person asking what you hold
HIPAA
42 controls
1
Kinds of sensitive data it knows to look for
16
Health terms it recognises
2
Checks that run on every message
3
Rules for keeping less than you were sent
5
Rules applied to every send
3
Refusals built into the pipeline
5
Emergency-access steps, recorded when used
4
How long each kind of record is kept
3
Evidence it records for every send
PCI Safe
41 controls
1
Kinds of sensitive data it knows to look for
17
Fields it refuses to store at all
5
Checks that run on every message
2
What it does when it finds something
7
Places it inspects before anything is written
5
Rules applied to every send
2
How long each kind of record is kept
2
Evidence it records for every send
110 executable controls across 3 packs, counted from the packs themselves. Installing a pack installs these; it does not certify anything.
A compliance pack is a set of technical controls. It is not a certification, a signed statement of compliance or a legal status, and we will not describe it as one. Genuine standing under health-privacy law also needs agreements no software can sign for you.
What you get
The whole of it, one capability at a time.
Each capability is switched on, billed and controlled on its own, so you run the parts you need and pay for those. The core ones come with every workspace; the rest are bought and switched on when you want them.
Core6 capabilities
Installed with every workspace. Not separately billed.
Data handling
One pass over everything that arrives, so only what your contract asked for is ever written down.
Delivery
Queues a written message, keeps it inside your sending limits, picks a provider, sends, and records the receipt. Retries what is worth retrying, holds back what is not, and every attempt is on the record.
Preferences and consent
Quiet hours defer; they do not drop — unless the contract's time limit runs out first, in which case it expires, with the evidence to show why.
Reporting
Turns what actually happened into numbers behind a reporting API, so delivery, engagement and template performance are questions you ask rather than logs you read.
Sending
The outbound spine. Take a request, decide, write it, deliver it, keep the evidence.
Templates
Drafting is a step inside this, never a way around it. A draft is built from what that kind of message already says it must carry, so it references exactly the parameters a real send will carry and nothing it will not — and it still traverses variable validation, preview, review and a recorded approval like any other draft.
Add-ons6 capabilities
Installed and billed per workspace, each governed on its own.
Alerting
A condition becomes true about a subject; decide whether anybody hears about it, who, and what happens when nobody answers.
Compliance
Not a separate system. It is the data handling above, plus deleting on time, answering data requests and exporting.
Documents
Identifies a document by its own contents on upload, reads it if it carries text, sorts it against the classes you declared, and routes it to a person when it cannot be sure.
Inbound email
Takes mail that arrives, parses it, works out who sent it, and threads it to the notification it answers — so a reply opens a ticket against the send rather than landing in a second system.
Search
Result authorization happens after the query and before the response. An index returning rows the caller may not see is a data breach with extra steps.
Team Inbox
Team Inbox with notification context. The operator sees communication evidence beside the conversation, and it stops there: this is not a helpdesk, and it does not try to become one.
Every capability here is one you can switch on today, governed on its own terms and billed on its own line.
Built to compound
The capabilities share one communication model.
Templates share one definition of what a message carries. Packs share one vocabulary. The widgets read the preferences the sending obeys. Each capability is more useful because the others exist — which is a harder thing to reproduce than a send endpoint.
One communication modeldeclared once, read by all 4
1
One dictionary
62 kinds of message, each with what it carries, where it can go and the rules that apply.
2
One preference graph
The widget writes exactly what the sending reads. There is no second copy to drift.
3
One evidence chain
81 event families feeding the timeline, analytics and exports from the same rows.
4
One set of rules
71 reason codes shared by every decision, so an explanation means the same thing everywhere.
One layer, several jobs
Useful to more than the team that installs it.
Developers
One API, typed requests, an SDK, signed webhooks and far fewer delivery surprises in production.
- One endpoint across 3 channels
- Typed requests and an SDK, so a bad send fails at your keyboard
- Signed callbacks you can verify before you act on them
Product
Reusable communication patterns, an embeddable preferences centre and engagement measured honestly.
- 36 ready-made packs instead of a blank screen
- A preferences centre you drop into your own account page
- Engagement counted from the same rows the sending wrote
Support
A timeline that answers “did they get it?” without a provider's logs.
- One timeline that answers “did they get it?”
- 71 plain reasons a message was held back
- No provider login needed to answer a customer
Compliance
Sorting sensitive data, keeping only what is needed, deleting on time and keeping the evidence — set up once, applied to every send.
- 3 compliance packs that run in the pipeline
- Sorting, keeping less and deleting on time, set up once
- Evidence kept for every send, not reconstructed later
Designed for teams building
Sector packs for the products people actually run.
Each sector pack installs the notification types, contracts and templates that sector needs, drawn from the same dictionary.
Fintech / Payments
19
Banking
14
eCommerce
13
Healthcare
13
SaaS
13
Professional Services
11
Marketplace
10
Media / Publishing
10
Construction
9
Insurance
9
Logistics
6
Events
4
Hospitality
4
Sports
4
Education
3
Property
3
Cold Chain Pack
1
Laboratory Pack
1
Manufacturing Pack
1
Physical Security Pack
1
We do not show customer logos. When there are references worth naming, they will appear here with permission and not before.
Against the alternatives
Three ways to solve this. Here is what each one costs you.
Most teams reach one of these three. The columns describe what each KIND of answer is designed to do — not a scorecard of any particular vendor, because a feature table about someone else's product is out of date the week it is written.
| Build it yourself Your team, your queue, your on-call | An email service provider A delivery API and a template editor | NotifHQ A governed communication layer | |
|---|---|---|---|
| What you integrate against | Your own abstraction, rewritten each time a channel or a rule is added. | A send endpoint per provider, plus whatever you build around it. | One API: 174 operations across 137 paths, with a generated SDK and signed webhooks. |
| What a message is | Whatever the calling code passes. Shape drift is found in production. | A template and the data it happens to mention. | A declared type with a published contract. 205 of them check what you sent before a word is written, so a missing variable fails at publish rather than at send. |
| Preferences and consent | A table, a settings screen, and a branch before every send that somebody has to remember. | Unsubscribe for marketing mail, typically per list. | Worked out by us, per category and channel, with quiet hours and consent evidence. Your code does not branch. |
| Answering “did they get it?” | Parse provider logs and hope the retention window is long enough. | Provider-side event streams, for as long as that provider keeps them. | An evidence timeline you own, with 81 event families emitting today and 71 reason codes so a refusal explains itself. |
| When it refuses | An exception, and a retry loop somebody wrote at 2am. | A provider error code, mapped by you to something your team understands. | A registered reason code and its class. A policy denial is never retried, because it would produce the identical denial forever. |
| Replies | A second system, holding half the history. | Usually out of scope; inbound is a different product. | A shared inbox on the same contracts that sent the message, threaded to the send that prompted it. |
| Time to the first governed send | Sending is an afternoon. The year after it is the part nobody estimates. | Minutes to a send; the governance is still yours to build. | Install a pack and call one endpoint. 205 notification types arrive already contracted. |
Only the NotifHQ column makes claims we hold ourselves to, and every figure in it is read from this repository's registries at build time. The other two describe the shape of the category; a specific product in either may well do more, and if you are comparing against one in particular, ask us and we will answer about that one honestly.
Pricing
Priced on what is governed, not just what is sent.
Volume is a capacity dimension inside a plan, never the whole of it. Billing is counted from the record of what actually happened: a message your rules stopped was never delivered, and is not billed as though it was.
Growth
£199 /mo
20,000 notifications · 250 governed subjects included
- API
- SDK
- Templates
- Template gallery
- Preferences widget
- Basic analytics
- Webhooks
- 1 sending domain
Most chosen
Scale
£499 /mo
50,000 notifications · 1,000 governed subjects included
- Everything in Growth
- Advanced analytics
- Extended retention
- All standard sector packs
- Search
- Multiple sending domains
- Additional widgets
Business
£1,499 /mo
100,000 notifications · 5,000 governed subjects included
- Everything in Scale
- Team Inbox
- Approval workflows
- Advanced policies
- Audit
- SSO
- Extended analytics
- Advanced search
High Volume
from £2,999 /mo
1,000,000 notifications · 50,000 governed subjects included
- Everything in Business
- Premium controls
- Custom packs
- White-label widgets
- SLA
- Advanced compliance
- Higher retention
A capability your plan does not include is absent rather than locked — it does not appear in your dashboard or your API reference.
What it replaces
The cost is the part nobody estimates.
Sending is an afternoon. The year after it is templates, preference screens, consent records, retry logic, holding the wrong ones back, a delivery log somebody has to read, and an auditor asking for evidence. Every number below is what arrives already built.
notification types
205
Installed by 36 packs, each with a published contract. Not examples to adapt — contracts that check what you sent before a word is written.
contracts
205
What it carries, where it can go, and the preference and consent rules — written down and versioned, so a missing variable fails at publish rather than at send.
operations
174
One API across 137 paths, with a generated SDK and signed webhooks, instead of a provider integration per channel.
event families
81
Emitting evidence today. Delivery states, engagement and policy decisions arrive as events rather than as a log you parse.
Every number here is read out of the list that owns it when this page is built, so none of them is an estimate and none of them is a guess.
Beyond the plan
Add one capability, not a bigger plan.
Each of these is a capability with its own contract, bought against the plan you already have rather than by moving up a tier. A card says what the add-on sells, and where a name could reasonably be read wider than the thing behind it, what it does not.
Inbound / Team Inbox
Replies come back. Inbound mail is parsed, attributed to the person it came from and threaded to the notification it answers, and a team works it as tickets with assignment and status on the same evidence chain as the outbound send.
Document Intake
A document is identified by its own contents on upload, read if it carries text, sorted against the classes you declared, and routed to a person when it cannot be sure. That is the whole of it.
Not includedOptical character recognition, or reading fields out of a document. A PDF or a scan is stored and reviewable; no amount, date or supplier is extracted from it. Where classification cannot answer, it says so and routes the document to a person rather than guessing.
Search
One query across notifications, tickets, documents and recipients, authorised after the query and before the response so an index can never return a row the caller may not see.
Compliance Packs
Executable controls in the send path: classification, detection, keeping less, redaction, retention windows and subject-access workflows, applied before sensitive data reaches a log, an index or an analytics table.
White-label Widgets
Your name and your styling on the widgets your recipients use — preferences, consent, data requests — with no NotifHQ branding on any of them.
Extra Domains
Additional verified sending domains on one workspace, each with its own signing keys, its own reputation and its own verification record.
Advanced Retention
Longer retention windows on the classes that hold your evidence, so a record survives as long as the rule that needs it rather than as long as the default.
Alerting
A workspace declares the things it tracks and the conditions worth knowing about, and reports observations over HTTP. We decide what becomes a message: the quiet rules run first, an alert is raised or folded into another or withheld with a reason, acknowledging it stops the chasing, and a timer escalates it. Every observation is stored whether or not it raised anything, so the silences are as auditable as the alerts.
Not includedReaching equipment directly over a shop-floor protocol, or commanding it. Telemetry arrives over HTTP, which is how a sensor gateway or fleet platform already speaks. MQTT, OPC-UA, Modbus, LoRaWAN and serial are not carried, and nothing here sends a command to a machine.
Secure by design
Communication infrastructure should reduce your attack surface.
Centralising communication takes delivery credentials out of your application surfaces.
Can reach a delivery provider1 of 5
notifhq-mail-transport
MAIL
No path to a provider at all4 of 5
notifhq-api
DBCOMMSRATE_LIMITBASE_URLAI
notifhq-comms-engine
DBEMAIL
notifhq-console
DBSESSIONSAI
notifhq-contact
COMMSRATE_LIMIT
A credential taken from anything below the line sends nothing: there is no code under it that can call a vendor.
Scoped credentials
A key is bound to one workspace and one environment. A test key cannot cause a real delivery.
Short-lived widget tokens
Recipient-scoped, minted on your server. Your key never reaches a browser.
Signed webhooks
Verify before you act, with replay protection.
Audited changes
Every administrative change records what it looked like before and after.
Before you ask
The questions that decide it.
What happens when a send is refused?
It answers with a registered reason code and its class — 71 of them — and the refusal is recorded as evidence. A policy denial is never retried, because it would produce the identical denial forever and bury the outcome.
Where does our data live?
In the United States. That is where this deployment stores data, so if your data has to live somewhere else, tell us before you start rather than after: it is a database we would have to stand up, not a setting we would have to change. We tell you where your data is rather than promising it cannot leave, because those are different undertakings and only one of them is ours to give: this database is placed by a best-effort hint, not held by a binding jurisdiction. Ask us for a jurisdiction-backed region and we will tell you what exists today. What you send is trimmed before anything stores it, so a field your contract did not ask for is dropped at the door rather than written down and cleaned up later.
Do you send on our behalf, or as you?
As you. Each sending domain gets its own DKIM key and every message carries the workspace's own legal signature. A domain is verified against the address it actually sends from.
Is a compliance pack a certification?
No, and we will not describe it as one. A pack is a set of executable controls that run in the same pipeline as your sends. Genuine standing under health-privacy law also needs agreements no software can sign for you.
What if we already have an email provider?
Keep it. Providers sit behind a transport worker and nothing else in the estate may reach one, so swapping or adding a provider changes one binding rather than your integration.
How big is this, really?
174 operations across 137 paths, 12 capabilities, 81 kinds of event emitting evidence, and 62 notification types in the shared dictionary. Every number on this page is read out of the list that owns it when the page is built, so none of them is a figure somebody typed.
If the answer you need is not here, the contact form goes to a person, not a queue.
Every communication governed, delivered and evidenced.
Start with one notification. Add templates, preferences, widgets and evidence as you need them.
✕
Talk to a person
Tell us what you are building.
One form, and a person reads every one. Pick what you need and the fields change; nothing here depends on a script running.
✕
Message received
A person reads every one of these. We will reply to the address you gave us.
✕
That did not go through
Please check the highlighted fields. Something went wrong on our side. Please email info@notifhq.com and we will pick it up.