NotifHQ

Customer communication infrastructure

One API for every customer communication.

Send it. Receive it. Find it. Prove it.

Send transactional notifications, honour customer preferences, render approved templates and prove exactly what happened — without building the infrastructure around it.

API · SDK · Webhooks · Managed delivery · Preferences widget

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.

Templates

HTML and plain text. Variables. Locales. Versions. Approvals. Previewing.

Preferences

Topics. Channels. Opt-outs. Consent with a lawful basis. Quiet hours.

Reliability

Queues. Retries. Idempotency. Suppression. Delivery states that mean different things.

Visibility

Logs. Timelines. Webhooks. Answering “did they get it?” without reading a provider's logs.

Governance

Classification. Minimisation. Redaction. Retention. Evidence an auditor will accept.

Correctness

Knowing that a template variable exists before the message goes out, not after.

NotifHQ packages these behind one communication layer.

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 emits

  • commerce.order.shipped
  • billing.payment.failed
  • auth.identity.otp
  • security.login.new_device

NotifHQ owns

NotificationPreprocessingTemplatePreferenceDeliveryAnalytics

Reaches people on

  • Email
  • In-app inbox
  • Webhook

3 channels available now; 6 declared across the roadmap.

Typed notifications

Stop sending arbitrary blobs.

Define a communication once. NotifHQ then knows its required payload, its permitted channels, whether a preference may override it, how it de-duplicates and how long it stays worth sending.

Schema

Undeclared fields are dropped before anything stores them. A missing required field fails before a policy is even evaluated.

Channels

A contract names what it may use. A channel outside that set is refused, not silently substituted.

Preference policy

Most contracts respect an opt-out. A few may not — and those are declared, not decided at the call site.

Time to live

A late message is worse than none for time-bound content, so a contract states when it stops being worth sending.

58 notification types are described in the dictionary today, across 18 business domains.

The rule everything else follows

Requested is not sent. Sent is not delivered. Delivered is not engaged.

Most tools collapse these into one green tick. NotifHQ keeps them apart in the API, the events, the metrics and the timeline — because the moment they merge you can no longer answer the only question that matters when something goes wrong.

Requested

You asked. Nothing has been decided, rendered or sent.

Sent

A transport accepted it. It has left our control. It has not arrived.

Delivered

A destination accepted it. A person may still never look at it.

Engaged

Something was observed — and we say how strong that observation is.

An email open is a tracking-pixel fetch a mail client may make, prefetch, cache or block. We call it an open observation, and the metric is named for what it is.

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 Requestedvia API · correlation ORD-9218
  • 14:02:11 Payload validatedcontract 1.3.0 · 2 undeclared fields dropped
  • 14:02:11 Preference permittedtransactional · quiet hours not active
  • 14:02:11 Policy allowed evidenceTRANSACTIONAL_ALLOWED
  • 14:02:12 Template renderedchecksum 9f2c…a41b
  • 14:02:12 Transport accepted evidencechannel email · provider managed
  • 14:02:15 Delivered evidencereceipt observed 14:02:15, recorded 14:02:16
  • 14:06:42 Click observed observedregistered link · tracking_url

73 event families are declared, each emitting 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 notification types, schemas, contracts, templates, routing defaults, preference categories and analytics definitions together — so a team starts with a shared vocabulary instead of assembling one.

commerce.order.shipped

Order Shipped

The order has left. The tracking link is the entire point of the message.

email

billing.payment.failed

Payment Failed

A charge did not succeed and the recipient's service is at risk.

emailin_apppreference locked

auth.identity.otp

One-Time Passcode

A short-lived passcode proving control of a channel. The single most latency-sensitive message the platform carries.

smsemailpreference locked

security.login.new_device

Sign-in From a New Device

Tells a recipient their account was accessed from somewhere new, and gives them a way to act.

emailpushpreference locked

eCommerce

one install 13 notification types 13 contracts

32 packs: 16 sector, 13 functional and 3 compliance.

AI where it helps, guardrails where they matter

AI drafts the copy. The contract keeps it safe.

Drafting is a stage inside the template rail, never a bypass around it. Generated content enters as a draft and traverses variable validation, preview, review and a recorded human approval like anything else.

Known variables only

A draft referencing a variable the schema does not declare fails mechanical validation.

Approval is of a checksum

Publication is refused when the content changed after approval. An approval of some version is not an approval of this one.

Provenance is kept

A drafted template is marked as drafted for its whole life. Approval does not launder where it came from.

Respect preferences automatically

Your code should not branch before every send.

Preferences, consent, suppressions, quiet hours and rate limits are evaluated as part of the communication lifecycle. You call the same endpoint; the decision is made once, recorded, and explainable afterwards.

Quiet hours defer

They do not drop. Unless the contract's time to live expires first — in which case the notification is expired, with evidence.

Suppression is evidence

Not an error and never a silent drop. Every suppression carries a registered reason and a decision.

Erasure is absolute

No contract, purpose or category overrides it.

54 registered reason codes, so “why was this suppressed?” is answerable in a support conversation without reading code.

Process first, store less

The payload is minimised before anything stores it.

One rail runs over every payload class — notifications, inbound mail, attachments, ticket messages, webhook bodies. A field your contract does not declare is dropped before persistence, so it never needs classifying and never needs protecting.

Detection is deterministic and authoritative. A card number is caught by a checksum, not by resemblance — 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, suppression, quiet hours, jurisdiction, sector and every installed compliance pack — 27 policies can bear on a single send, and the ones that apply to a given workspace are evaluated to one decision. Not a claim somebody typed: a benchmark runs the real decision plane on every build and fails over the budget, so this page cannot state a number the product no longer meets.

Why it is that fast

The policy plane takes a context and returns a decision. No database, no network, no ports — pure computation over rules held in memory. That is the reason for the number, and the reason it has to stay that way.

What would break it

One database read inside one rule. The day a rule needs to look something up the budget is gone, and no ordinary test would notice — so the benchmark runs on every build and fails over 1ms.

What it does not cover

The whole request is slower than the decision inside it: reading a contract, a recipient and their preferences takes real reads against real storage. We publish the decision number because it is the one we control absolutely.

Measured over 50,000 runs against the heaviest configuration — every compliance pack installed — rather than the lightest. The full request is slower than the decision inside it, and we publish the decision because it is the part we control absolutely.

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 rail that delivers. Each renders in a shadow root, so your CSS cannot break it and its styles cannot leak into your page.

Preferences Center

The recipient's own view of what they receive and how. The single most-requested surface, and the one that turns an opt-out into a downgrade.

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.

Behind the call: contract resolution, schema validation, classification, policy evaluation, preference and consent resolution, template selection, routing, dispatch, evidence capture and webhook fan-out. None of it appears in the signature.

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

Constant-time verification with a timestamp tolerance, so a captured payload cannot be replayed indefinitely.

106 endpoints and 134 operations, generated from the same document the SDK is built from.

Compliance packs

On the roadmap · phase 2

Controls in the pipeline, not badges on a page.

Compliance packs are sets of executable controls — classification, detection, minimisation, redaction, retention and subject-access workflows — that run in the same pipeline as your sends. The control happens before sensitive data reaches logs, search or analytics, not after.

GDPR Pack

PII classification, purpose limitation, consent records, preference evidence, retention, DSAR export and deletion, field minimisation, redacted analytics and search, audit evidence.

HIPAA Pack

PHI vocabulary and schemas, minimum-necessary controls, strict search and log redaction, purpose-of-use, restricted access, break-glass with audit, retention and evidence.

PCI Safe Pack

PAN detection with Luhn validation, CVV and context detection, a forbidden-field dictionary, block and quarantine, redaction, template and payload inspection, violation evidence.

A compliance pack is a set of technical controls. It is not a certification, an attestation 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 is built, and what is next

Shipped work and planned work, told apart.

A page cannot let you tell shipped from planned unless it says so. These are the rails, with their real status from the registry that drives the build.

Rails, their tier and their build status
RailTierStatus
Analytics Rail Core Available
Delivery Rail Core Available
Notification Rail Core Available
Preference Rail Core Available
Preprocessing Rail Core Available
Template Rail Core Available
Inbound Email Rail Add-on Phase 1.5
Search Rail Add-on Phase 1.5
Team Inbox Rail Add-on Phase 1.5
Compliance Rail Add-on Phase 2
Document Rail Add-on Phase 2
Invoice Intake Rail Add-on Phase 2
Push Rail Add-on Phase 2
Advanced Routing Rail Add-on Phase 2
SMS Rail Add-on Phase 2
Telegram Rail Add-on Phase 3
Wallet Rail Add-on Phase 3
Workflow / Journey Rail Add-on Phase 3

Built to compound

The capabilities share one communication model.

Templates share schemas. Packs share vocabulary. Widgets read the same preferences the rail enforces. Evidence, analytics and search all read the same canonical objects. Each capability is more useful because the others exist — which is a harder thing to reproduce than a send endpoint.

One dictionary

58 notification types with declared payloads, channels and policies.

One preference graph

The widget writes what the delivery rail reads. There is no second copy to drift.

One evidence chain

73 event families feeding the timeline, analytics and exports from the same rows.

One policy plane

54 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 payloads, an SDK, signed webhooks and fewer delivery edge cases to discover in production.

Product

Reusable communication patterns, an embeddable preferences centre and engagement measured honestly.

Support

A timeline that answers “did they get it?” without a provider's logs.

Compliance

Classification, minimisation, retention and evidence configured once and applied on every send.

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.

BankingConstructioneCommerceEducationEventsFintech / PaymentsHealthcareHospitalityInsuranceLogisticsMarketplaceMedia / PublishingProfessional ServicesPropertySaaSSports

We do not show customer logos. When there are references worth naming, they will appear here with permission and not before.

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 metered from the evidence plane: a notification that policy denied produced no delivery and is not billed as one.

Growth
£199 /mo
20,000 notifications included
  • Email
  • API
  • SDK
  • Templates
  • Template gallery
  • AI drafting
  • Preferences widget
  • Basic analytics
  • Webhooks
  • 1 sending domain
Get started
Business
£1,499 /mo
100,000 notifications included
  • Everything in Scale
  • Team Inbox
  • Approval workflows
  • Advanced policies
  • Audit
  • SSO
  • Extended analytics
  • Advanced search
Get started
High Volume
from £2,999 /mo
1,000,000 notifications included
  • Everything in Business
  • Premium controls
  • Custom packs
  • White-label widgets
  • SLA
  • Advanced compliance
  • Higher retention
Get started

A rail your plan does not include is absent rather than locked — it does not appear in your dashboard or your API reference.

Add-ons

SMS

sms rail

Inbound / Team Inbox

team_inbox rail

Invoice Intake

invoice_intake rail

Document extraction

document_intake rail

Search

search rail

Compliance Packs

compliance rail

White-label Widgets

Extra Domains

Advanced Retention

Secure by design

Communication infrastructure should reduce your attack surface.

Centralising communication means your application surfaces stop each holding delivery credentials, template implementations and logging pipelines of their own.

Scoped credentials

A key is bound to one workspace and one environment. A development key cannot cause a production delivery, and that is enforced before routing.

Short-lived widget tokens

Recipient-scoped and minted server-side. The workspace key never reaches a browser.

Signed webhooks

Verify before you act, with replay protection.

Minimisation first

Undeclared fields are dropped before persistence. A field never stored never needs protecting.

Audited changes

Every administrative mutation writes a before-hash and an after-hash.

Structural isolation

Workspace and environment boundaries live at the storage key and the policy plane, not in a filter a handler could forget.

Every communication governed, delivered and evidenced.

Start with one notification. Add templates, preferences, widgets and evidence as you need them.