Written by Technical Team | Last updated 30.09.2025 | 17 minute read
If your service lives anywhere near the UK public sector, there’s a good chance you’ll be asked a deceptively simple question: “Should we send our messages through NHS Notify or through GOV.UK Notify?” To a product manager it might sound like two flavours of the same thing, but to an engineer on the hook for reliability, security and clinical safety, the choice has real architectural consequences. This article unpacks the two platforms from a developer’s perspective, mapping out where each shines, where teams get tripped up, and how to design an integration that holds up under real-world load, governance scrutiny and user expectations.
Before we dive in, it’s worth noting that these platforms exist for different reasons. GOV.UK Notify is the cross-government workhorse for transactional messaging—email, SMS and letters—designed to be simple to adopt and scale. NHS Notify, by contrast, grew out of health-specific needs: messages that must respect the Personal Demographics Service (PDS), patient contact preferences and safety constraints, with the option to deliver securely into the NHS App as well as via traditional channels. Both services will send messages; they just approach identity, routing and guardrails very differently. Understanding those differences early will save you rework later.
GOV.UK Notify is the “common good” platform for government communications. Its remit is broad: central government departments, executive agencies, local authorities and arm’s-length bodies all use it to send high-volume transactional email and SMS, and to print and post letters. Its priorities are straightforward: a fast, reliable API; a friendly web console; and uncomplicated templates that service teams can manage without developers once they’re set up.
NHS Notify, on the other hand, starts from the patient. In healthcare, who you can contact and by which channel isn’t simply a matter of possessing an email or phone number; it’s mediated by PDS records, contact preferences, flags and safeguarding considerations. NHS Notify doesn’t just send messages—it orchestrates them. It can deliver to the NHS App inbox when that’s appropriate, fall back to SMS or email when it isn’t, and refuse to send when the record indicates contact should be restricted. If your messages could influence care, or if you must prove to governance that every send respected up-to-date patient data, NHS Notify embeds those checks into the messaging path in a way GOV.UK Notify intentionally does not.
At first glance, the two APIs look alike: REST endpoints, JSON payloads, template identifiers and personalisation fields. Under the hood they diverge in ways that affect how you model data and build failure handling. With GOV.UK Notify, you pass explicit recipient details—email addresses, mobile numbers or a postal address—and Notify brokers the send to the appropriate downstream provider. The state model is simple: a notification is created and progresses through states like sending, delivered, failed or bounced, with limited insight into the exact mechanics of delivery that took place. If you’ve used transactional email providers, the mental model will feel very familiar.
NHS Notify asks you to think differently about identity and routing. Instead of passing a mobile number, you typically pass the patient’s NHS number and personalisation payload. Behind the scenes, NHS Notify resolves who the person is, which channels are appropriate, and which are currently viable. It can address the NHS App inbox for logged-in users, or choose email or SMS if app delivery is not possible or not permitted. That indirection has two practical effects for developers. First, you model recipients as NHS numbers rather than contact details, which means your system design nudges you to avoid storing or handling raw contact information unnecessarily—a win for data minimisation. Second, you relinquish some control over channel choice, so you must be comfortable with an authoritative service applying policy on your behalf. When you need explicit control—such as a campaign that must only ever go by letter—you’ll rely on templates, routing rules or product-level configuration rather than ad-hoc per-request switches.
Both services are designed to be called synchronously at the front door with the heavy lifting happening asynchronously. For GOV.UK Notify, the common pattern is: your service calls the API with a template ID, recipient details and personalisation; Notify returns a notification ID; a background worker hands off to an email/SMS provider; and status updates flow back as webhooks or via polling, depending on what you enable. The scale characteristics are predictable and well understood: spikes in API call volume are smoothed by queues; delivery latencies are typically sub-minute for email and SMS, with letters bound by print and postal timelines. If you need end-to-end confirmation, you instrument your system to correlate Notify’s notification IDs with your business events and store the last-known status.
In NHS Notify, orchestration adds an extra hop. The service will often consult PDS in the process of deciding whether and how to send; it may also validate that your organisation is permitted to contact this person and that no flags preclude the message. That means the synchronous portion of your call might do more work than you expect compared to a simple “fire and forget” send. Your retry strategy must account for cases where a temporary PDS outage returns an error that is not the same as “message send failed”—and your idempotency model needs to ensure a re-submit doesn’t fan out duplicate messages across channels once the system recovers. In practice, you’ll want to design with idempotency keys (derived from patient, template and business event) so you can safely retry without multiplying sends when a call fails halfway through orchestration.
Another architectural difference is where templating logic lives. GOV.UK Notify assumes templates are “owned” in its console: you define them there and reference them by ID from your code. You can render previews via the API, but the source of truth is Notify’s template store. That’s a product choice to keep responsibility for copy, sign-off and formatting with service teams. NHS Notify likewise encourages template use, but adds the concept of routing strategy to the mix: a message definition plus a routing plan that can adapt per recipient. This lends itself to treating message definitions as artefacts with lifecycle and governance—particularly important for clinical content where a wrong word can have safety implications.
Finally, think about multichannel strategy. With GOV.UK Notify you choose the channel per request; combining channels—say, send an email and an SMS reminder six hours later if the email hasn’t been delivered—requires orchestration in your application, using webhooks and timers. NHS Notify’s routing lets the platform do more of this on your behalf. That’s not a blanket “better”; some teams prefer to keep that logic in code for transparency. But if you’re trying to prove you always respected the latest contact preference at the moment of send, pushing the logic closer to the source of truth reduces surface area and audit burden.
Security matters everywhere; in health it is inseparable from safety and trust. Both platforms encrypt data in transit and at rest, both expose access-controlled consoles, and both expect you to treat API keys like the crown jewels. The day-to-day security practice a developer experiences—rotating credentials, limiting scope, using IP allow-listing or mTLS where appropriate—will feel familiar. The deeper differentiators show up in governance pathways and the clinical safety model around patient communications.
Start with data minimisation. GOV.UK Notify expects you to supply recipient contact details for each send. In many government services that’s perfect: you control where contact details came from, you can show user consent, and the logic around who to contact is part of your service’s business rules. In healthcare, however, patient contactability changes over time for reasons the sending system might not know—temporary restrictions, safeguarding flags, or changes to the nominated contact method. NHS Notify’s design offloads that risk by basing sends on an NHS number and the current state of PDS. The less your system handles raw contact data, the less you have to secure, and the fewer copies of sensitive information exist. That’s not just an abstract benefit; it can materially lower the amount of assurance work you must do during information governance reviews.
Next, look at patient preference and consent. In the NHS, a person’s preferred channel for clinical communications is not a casual setting; it is part of their demographic record and can carry legal weight. If someone has expressed that messages should not be sent by SMS, simply possessing a mobile number doesn’t grant permission to use it. NHS Notify is built to respect these preferences by design. It will not “just send anyway” because you have data; it will select a permitted channel or refuse. With GOV.UK Notify, respecting preference is on you: you must ensure your service checks whatever systems hold the canonical preference before making the API call, and that those checks keep pace with changes.
Clinical safety standards add another layer. If your messaging can influence care—appointment notifications, medicine reminders, abnormal result alerts—your service will likely fall under NHS clinical risk management standards such as DCB0129 and DCB0160. That means maintaining a hazard log, documenting mitigations, and evidencing that your system’s design reduces risk. The platform choice can help here. Using NHS Notify allows you to argue that certain hazards (mis-addressing, sending against a restriction, ignoring preference) are mitigated at the service boundary by an orchestrator developed to NHS assurance levels. If you use GOV.UK Notify for similar messages, you’ll need to show equivalent mitigations in your own code and processes, and in the way you source and update contact details and preferences.
Finally, think about auditability and incident response. Suppose a patient complains that a message was sent by SMS when they had requested email only. With NHS Notify, you can point to a platform decision history tied to the NHS number and PDS state at send time. With GOV.UK Notify, the record shows only that an SMS was requested by your service; you must produce your own audit trail showing why you decided that was appropriate. Neither is “wrong”, but they lead to different obligations on your side. If your organisation expects frequent freedom-of-information requests, complaints handling or clinical incident reviews, building on a platform that centralises decision traces can reduce operational friction.
On paper both APIs are well documented and developer-friendly. In practice, your day-one experience depends on the path to credentials, the ergonomics of templating, and how easily you can build robust observability around sends. There are also material differences in how teams scale from a spike in usage to a sustained production cadence.
GOV.UK Notify feels intentionally lightweight. You can create a service, add team members in minutes, and begin sending real messages while still in a trial mode that guards against accidental blasts. The console is approachable, with templates that use a simple Markdown-like syntax. Client libraries exist for popular languages, and the examples tend to be direct: “call this endpoint, get back an ID, here’s how to check the status.” That makes it a favourite for squads who need to ship something quickly, or for services where messages are important but not safety-critical. The trade-off is that you own the upstream data quality and policy checks. If your user database has stale phone numbers, Notify will faithfully attempt to send to them; your task is to build the hygiene processes that keep that data fresh.
NHS Notify’s onboarding is more involved because its guarantees are stronger. You’ll typically go through an authentication pattern aligned to the NHS API platform, which often involves an application registration, an API key and a signed JWT or similar token flow. Once connected, the day-to-day API is not inherently more complex—send a message with a template and personalisation, receive a message ID—but because orchestration and PDS checks happen on your behalf, you’ll encounter richer error modes and decision outcomes. That’s good for safety, and it does mean your logging and dashboards should capture more than just “was it delivered”: you’ll want to record why a message was routed the way it was, or why a send was refused, because those facts are valuable in product conversations as well as audits.
SREs will care about how each service behaves under stress. Both platforms are built to handle bursts and queue up work, but developers sometimes underestimate downstream effects. With GOV.UK Notify, a burst of sends translates quickly into provider calls to email/SMS gateways, which usually cope well but can trigger rate limiting or greylisting in recipients’ mail servers if you don’t spread campaigns sensibly. With NHS Notify, bursts with heavy PDS lookup may contend on identity resolution and policy evaluation. The lesson in both cases is the same: adopt idempotent producer patterns, use exponential back-off for transient failures, and store correlation IDs so that your metrics can tell you whether bottlenecks live in your code, the API front door, or downstream providers.
From a product-management perspective, templates are where you can either empower non-developers or set them up to fail. GOV.UK Notify’s console is deliberately simple; it prevents creative formatting that would break accessibility and keeps content consistent. That works well across government. In health, messaging content may require clinical sign-off, and small wording changes can be safety-significant. Many NHS organisations therefore treat message definitions as governed artefacts with change control, review and test in lower environments before promotion. NHS Notify’s model aligns with that, especially when messages can route into the NHS App inbox where content patterns are part of a coherent in-app experience.
A common question is whether either platform supports inbound flows and event-driven design. The short answer is “yes, to a degree.” You can subscribe to delivery receipts and inbound SMS, and use those as triggers in your system. What neither platform does for you is deduplicate business events. If you emit the same “appointment confirmed” event twice, both will happily send two messages unless you implement idempotency at the business layer. When you work with NHS numbers and orchestrated routing, it’s especially important to define a stable idempotency key (patient + business event + template) so that retries after a temporary failure don’t produce additional sends.
Practical tips for a smooth developer experience:
For teams building health-adjacent software, the choice is rarely binary. Many organisations use both platforms: GOV.UK Notify for broad, non-clinical communications (service updates, satisfaction surveys, non-sensitive reminders) and NHS Notify for messages that must respect clinical context, PDS and the NHS App ecosystem. The sensible way to decide is to start from the risks and obligations, then weigh developer ergonomics and time-to-value.
If your message carries clinical nuance—anything that could alter behaviour around care, medicine or appointments—lean towards NHS Notify. You inherit routing and preference enforcement, and you reduce the amount of patient contact data your system needs to manage. That, in turn, can simplify your data protection impact assessment and your clinical safety case. It also sets you up to take advantage of NHS App delivery, which many patients expect and trust for health-related messages.
If your message is a conventional transactional communication with low sensitivity—resetting a password for a council portal, confirming that a permit application was received—GOV.UK Notify will get you to production faster with simpler onboarding and a friendly console. Because it doesn’t second-guess your routing choices, it’s also a good fit where your service has a carefully tuned contact strategy and you want to keep full control in code.
An overlooked design pattern is to use the two in concert through a messaging facade in your own system. The facade exposes a stable internal API—“send_message(person, template, context)”—and decides at runtime which platform to call. The decision can be based on message classification, user attributes or organisation policy. This keeps your business logic decoupled from platform specifics and makes it feasible to switch later without rewriting the application layer.
When planning a migration or a greenfield rollout, set expectations with stakeholders about what “delivered” means. Neither platform can guarantee that a human has read a message; they can only confirm that a provider accepted it, or that a device acknowledged receipt. If your success metric depends on comprehension (for example, “did the patient actually see their scan appointment?”), pair messaging with in-product nudges and reporting that measure outcomes, not just sends.
A concise decision framework you can adapt:
Message sensitivity and clinical impact
Identity and data stewardship
Channel strategy
Time to value
Operating model
Looking ahead, teams that start on GOV.UK Notify sometimes outgrow it for specific message classes when governance or clinical risk grows. The cleanest migration path is to keep your domain events and message intents platform-agnostic from day one. Don’t scatter Notify-specific IDs all over your business tables; map them at a boundary. Don’t hard-code template content into application code; keep references and personalisation fields abstracted behind your facade. That way, moving appointment reminders to NHS Notify later is mostly configuration and contract mapping, not a wholesale rewrite.
There’s also a cultural advantage in keeping a healthy separation of concerns. When you treat the messaging platform as an outboard service and focus your code on business events and outcomes, you reduce the temptation to cram logic into templates or to build brittle dependency on back-office consoles. Templates remain templates; business logic remains in code; platform configuration does its job at the edge. It’s easier to reason about, easier to test, and far easier to present to an architecture board or information governance panel.
In summary, both NHS Notify and GOV.UK Notify are excellent at what they set out to do, but they are optimised for different worlds. GOV.UK Notify is general-purpose, fast to adopt, and perfect for the millions of everyday transactional messages public services must send. NHS Notify is opinionated around patient identity, contact preference and routing, and it earns its keep whenever messages intersect with care. As a developer, your job isn’t to pick a winner; it’s to understand the guarantees you need, design for idempotency and observability, and build an integration that makes audits boring and incidents rare. If you do that, either platform will feel like a power-up rather than a constraint—exactly how shared platforms should feel.
Is your team looking for help with NHS Notify API integration? Click the button below.
Get in touch