Written by Technical Team | Last updated 30.09.2025 | 24 minute read
NHS organisations across England are under constant pressure to communicate clearly, quickly, and securely with millions of people. Whether it’s an appointment reminder, a vaccine invitation, a long-term condition review, or a targeted public health campaign, success increasingly depends on reaching the right person on the right channel at the right moment. NHS Notify was built for exactly that purpose. It provides a single, governed platform for sending NHS App inbox messages, emails, SMS texts and letters—individually or at population scale—while drawing on core NHS services such as the Personal Demographics Service (PDS) and the Organisation Data Service (ODS) to improve accuracy and trust.
This article takes a practical, in-depth look at what NHS Notify can and cannot do. It explains the channels, message formatting, sender identity controls, routing plans and personalisation features; explores delivery windows and operational considerations; and sets out the constraints and trade-offs teams need to understand before integrating the platform into clinical systems, operational workflows, and population health programmes.
At its core, NHS Notify is a centralised messaging service for the NHS. Its purpose is to help NHS organisations send high-volume or one-to-one messages via four channels: NHS App inbox, email, text message (SMS) and printed letters. Rather than requiring local systems to maintain and reconcile patient contact details, NHS Notify can work from NHS numbers and use the Personal Demographics Service to resolve delivery pathways, while actively preventing messages to people who must not be contacted. For many use cases—particularly those where people already use the NHS App—this “NHS number first” approach reduces friction and simplifies data governance.
The platform supports both bulk and transactional messaging. Operational teams can create templates, define routing plans, and trigger cohorts of messages in a planned campaign. Product and integration teams can call an API for automatic, event-driven communications—such as instantly acknowledging a referral, confirming an appointment booking, or notifying people when test results are ready. For organisations that already use MESH (Message Exchange for Social care and Health) to move files securely, NHS Notify can also process batch CSV submissions to trigger messages at scale.
Crucially, NHS Notify emphasises identity and trust. Receivers need to recognise that an incoming message is genuinely from the NHS and from the right part of the NHS. Sender names are therefore controlled: NHS App messages use your organisation’s ODS code to display the sender; email “from” addresses are issued on a trusted domain; and text message sender IDs are governed and reviewed. This helps reduce phishing risk and builds confidence that messages are legitimate and safe to act upon.
NHS Notify’s feature set is deliberately pragmatic. It focuses on making it easy to send secure, respectful and effective communications, and on giving delivery teams enough control to design reliable, multi-channel journeys. Four capabilities stand out in day-to-day use: templates and formatting, personalisation (including PDS-powered fields), routing plans for channel order and fallbacks, and cohorting to reach specific groups of people.
Templates are the baseline. Every message starts with a template designed for a specific channel. NHS App and email templates support a subset of Markdown to produce accessible, readable content without the complexity of HTML. Text messages are kept intentionally simple—short, plain-text snippets with optional URLs. Letters are uploaded as PDFs that meet a clear specification so they print, fold and post correctly in standard C5 windowed envelopes. This templated approach scales for large campaigns and enforces consistency and brand hygiene across the service.
Personalisation matters just as much. People expect messages to be relevant and correct; clinicians and administrators need to avoid ambiguity and reduce inbound queries. NHS Notify supports personalisation through two mechanisms. First, it can populate a small number of fields directly from PDS when you send using an NHS number—most notably the person’s full name, first name, last name, NHS number and the date variable. Secondly, it allows custom personalisation values that you pass in an API request (or as CSV columns for MESH). Template placeholders use double brackets—((likeThis))—and are replaced at send time to render the final output.
Routing plans are where strategy lives. Rather than sending everything on a single channel, you define the order of channels per audience, when to fall back, and when to stop. A common pattern is “NHS App inbox first” (free, secure, privacy-preserving), then email for those who do not read via the app, then SMS as a final digital nudge, with letters reserved for specific cohorts or statutory notifications. Routing plans also let you pick different templates for sub-audiences—say, separate versions for people with hearing or visual impairments, for different languages, or for first-dose versus second-dose vaccine reminders.
Finally, cohorting makes population outreach manageable. Instead of juggling spreadsheets and manual merges, teams can define a cohort once and reuse it; or they can adopt Cohorting as a Service to create specific, filterable groups for a campaign. Combined with routing plans, this gives operational teams a controlled way to run digital-first programmes with appropriate safety nets.
Where templates are important:
Where routing plans are important:
NHS App inbox messages are the most “NHS-native” digital channel. They deliver to a person’s secure NHS App inbox and, if the person allows notifications, the app issues banner and badge notifications on the device. For privacy reasons, banner notifications do not contain message content; they simply signal that a new message awaits in the app. Push notifications are sent only between 06:00 and 22:00; messages sent overnight still arrive in the inbox, but the push is deferred to the morning window. App messages are free and support clear formatting—headings, bullet points, numbered lists, line breaks, paragraphs, bold text, and links—making them ideal for instructions, preparation steps, and call-to-action flows.
Email is the workhorse for many programmes. NHS Notify issues messages from a trusted notifications domain and lets you choose a sender name and a reply-to address during onboarding. While emails can incorporate headings, bullet points, numbered lists, horizontal rules, line breaks and links, bold text is not supported in email templates. Emails are dispatched on working days during standard hours. Because NHS Notify deliberately does not track opens or click-throughs (to avoid unnecessary processing of behavioural data), delivery analytics focus on whether messages were accepted by mail providers and whether they were successfully delivered or bounced.
SMS remains powerful for time-critical nudges. It’s short, familiar and works even without smartphones or data connectivity. In NHS Notify, text messages are plain-text only; you can include URLs, but not rich formatting or line-breaked paragraphs in the rendered output. The sender name is limited to 11 alphanumeric characters and must pass review—typically involving the National Cyber Security Centre—to prevent spoofing and to minimise phishing risks. SMS are sent on working days within the configured hours, with the delivery provider retrying for a limited window if the handset is temporarily unreachable.
Letters complete the channel mix. They are generated from PDFs that meet a strict layout specification (A4 portrait) and posted in C5 windowed envelopes. Dispatch typically takes up to two working days, with most letters delivered three business days after dispatch under standard postage. Certain clinical and statutory letters can carry the Royal Mail NHS barcode when sent First or Second Class, enabling postal prioritisation during periods of pressure. Letters can include images and richer formatting, and they remain an important medium for people who cannot, or prefer not to, receive digital messages.
People need to recognise and trust the sender quickly. NHS Notify therefore builds sender identity into each channel. For NHS App messages, the sender name shown to the person is derived from your ODS code during onboarding. If you send on behalf of other NHS organisations or services—for example, a commissioning support unit running a central campaign—you can override the ODS code via the API or MESH so the recipient sees the correct sender. This is vital for clarity and consent journeys, especially where local brand recognition influences behaviour.
For email, you configure both a human-readable sender name and a reply-to address. The “from” email address is generated from the sender name and uses a trusted notifications domain; spaces in the sender name convert to full stops in the address. The reply-to must be a real mailbox—even if you do not intend to respond—because receiving systems and spam filters treat messages with functional reply-to addresses as more credible. If you want people to reply, use a reply-to address that signals it clearly; if you don’t, a corresponding “no-reply” pattern is common, though best practice is still to provide clear alternative contact routes in the message body.
For SMS, the sender name is constrained to prevent abuse and collisions with existing registered names. New sender IDs undergo review; this process can take time, so plan for it during onboarding and avoid last-minute campaign deadlines that depend on a brand-new ID. Note that sender IDs cannot contain spaces or special characters; teams often rely on camel case or meaningful abbreviations to stay within the limit.
Letter return addresses are not customisable on the envelope itself; these are set by NHS Notify’s suppliers. If you want replies by post, include your organisation’s postal address within the letter content and make the call to action explicit. It’s good practice to include other contact routes too (telephone, online forms, accessibility options) within the body of the letter.
Clear content saves time, builds trust and reduces avoidable inbound queries. NHS Notify’s formatting model is intentionally simple: Markdown for NHS App and email templates; plain text for SMS; and styled PDFs for letters. Within those constraints, you can still create content that is accessible, readable and task-focused.
NHS App messages support headings, subheadings, bullet points and numbered lists to structure instructions; line breaks and paragraphs to improve readability; bold text (with **double asterisks**) to emphasise critical information; and links in Markdown syntax. Because push notifications never reveal message content, consider leading with a descriptive heading in the message body so that the person immediately sees the purpose when they open it in the app. Keep paragraphs short and ensure links are clearly labelled so screen readers and voice assistants can interpret them.
Emails support many of the same structures—headings, lists, horizontal rules, paragraphs and links—though they do not support bold text in templates. Use horizontal lines to separate sections, such as appointment details and preparation instructions. Avoid embedding trackers or one-pixel beacons; NHS Notify does not support open or click tracking for principled privacy reasons, and your content should not imply otherwise. If you’re writing to people who may not expect a message from your service, using full URLs rather than anchor text can increase trust because recipients can see exactly where the link leads.
Text messages must do more with less. Prioritise a single action, write in everyday language, and include a short, trustworthy URL when a link is necessary. Because texts cannot present headings or formatting, the first few words matter: front-load the sender and the action—e.g., “NHS appointment confirmation: …” or “NHS prescription update: …”—so people scanning their lock screen can tell what it is.
Personalisation should help, not hinder. PDS-supplied fields reduce the need to pass common identifiers and ensure names match NHS records. Keep custom personalisation fields tightly scoped to the task—appointment date and time, clinic name, practice name, or an activation code. Avoid using fields that collide with built-in ones (for example, variants of “emailAddress”, detailed address line fields, or “date” as a custom key), as these are reserved and will not work. When designing templates, provide example values for short, medium and long versions of each field so you can preview how the message wraps or whether a text might exceed an SMS character budget.
Delivery isn’t just about pressing send. Each channel has its own schedule and behaviour. NHS App messages can be sent at any time of day; the recipient will see the message in their in-app inbox immediately, but push notifications are restricted to a civil window between 06:00 and 22:00. That compromise respects people’s preferences and reduces out-of-hours disturbances without delaying access for those who proactively check the app.
Emails are dispatched during working hours on weekdays. Once handed off to the email provider, there is a retry window—typically up to seventy-two hours—during which the provider attempts redelivery if the receiving system is temporarily unavailable. The same retry principle applies to SMS: once queued, the mobile network attempts to deliver for a limited period while the handset might be offline or out of signal, then marks the message as undeliverable if it cannot be completed.
Letters operate in a different world: they are the slowest but often the most robust for people who are digitally excluded. There is an internal production time from request to dispatch—normally up to two working days—after which postal delivery times apply. Standard postage is cost-effective but slower; First and Second Class options exist, and clinically significant categories of letters can carry the NHS barcode for prioritisation. Teams should treat letters as a separate workflow, with timelines that reflect printing, dispatch and postal realities.
Across all channels, it’s essential to understand what a status means. “Sent” typically means the platform accepted your request and handed it to a downstream provider; “delivered” means the provider received confirmation from the receiving system (mail server, network, or app service) that the message arrived. For app messages, “delivered” reflects inbox placement rather than a human reading the content. Because NHS Notify intentionally does not track opens or link clicks, you cannot infer behaviour beyond delivery; if your pathway depends on a user action, design a clear call to action and point to a page where you can measure completion (for example, a booking link that lands on a form with analytics you control).
NHS communications must meet high standards for privacy and security. NHS Notify’s design choices reflect that. Using NHS numbers and PDS for targeting reduces the need to copy contact details across systems. The platform automatically prevents messaging people who must not be contacted—because of preferences, sensitive flags, or deceased status. Sender identity controls and domain governance reduce spoofing risks. Transport security is a given for the API and for the MESH channel.
The absence of open and click tracking for emails is intentional. While marketing systems in the private sector often measure opens and clicks, doing so implicitly collects behavioural data that many people have not consented to. NHS Notify’s position is to avoid that practice altogether, which not only reduces risk under data protection law but also aligns with public expectations for respectful handling of their information.
Operationally, you should still minimise the personal data you include in messages. Avoid adding detailed clinical information to channels that could be read on a lock screen or shared devices. Put sensitive details behind secure log-ins—such as the NHS App—so people can authenticate before viewing. And if messages invite a reply, make sure you have a proper route and a trained team to handle those replies safely; for email, that means a reply-to mailbox that’s monitored; for letters, a return postal address in the body; and for SMS, an alternative channel since SMS replies are not part of Notify’s model.
There are two primary ways to integrate NHS Notify into your systems: a RESTful API and a MESH-based CSV pipeline. The API is the right choice for real-time, event-driven messaging—think “send confirmation immediately after a successful booking” or “notify when a test result status changes.” It lets your system call specific endpoints with a template ID, recipient information (often just an NHS number for app messages) and a JSON object of personalisation values. The response includes identifiers you can store to reconcile logs and to query delivery status later.
MESH is a strong fit for bulk campaigns orchestrated by operational teams. You generate a CSV with the required columns—NHS number, a reference for your own tracking, and any custom personalisation columns prefixed accordingly—and drop it into your MESH mailbox. NHS Notify processes the file, applies your routing plan, and dispatches messages accordingly. This is particularly useful for scheduled population outreach where the cohort is known in advance.
Whichever path you choose, treat error handling and observability as first-class concerns. Validate that personalisation fields in your payloads exactly match the template placeholders (including case) and that you never use reserved field names for custom data. Capture and store Notify’s message IDs and your own reference so you can diagnose issues, respond to queries, and produce evidence if needed. Agree internal SLAs for delivery monitoring—e.g., how long you wait before falling back to another channel for time-critical messages.
The NHS serves everyone, which means your messaging has to work for people with different languages, abilities and contexts. NHS Notify supports inclusive practice in a few ways. On the digital side, templates built with headings, lists and clear link text are more accessible to screen readers and easier to understand for people with cognitive load. The NHS App inbox model also reduces the risk of sensitive content appearing on lock screens or being forwarded from a shared email account.
On the print side, letters can be generated in accessible formats and in other languages. You can supply alternative versions of a letter template to meet local language needs and to provide large-print or dyslexia-friendly layouts. Because letters take longer, plan parallel digital routes where possible so that people who can use the NHS App or email receive the information quickly and those who need paper still receive clear, considered content.
It is also good practice to adopt inclusive content guidelines: avoid jargon; use plain English; break tasks into short steps; and signpost alternative routes like telephone contact for those who prefer speaking to someone. If you run campaigns that affect people with specific access needs, collaborate with local patient groups to test message drafts and ensure your choices of channel and format really meet the need.
Although cost structures can vary, one principle is stable: digital channels tend to be cheaper than paper, and NHS App messages are free at point of send. That is a strong argument for adopting an “App-first” routing plan wherever it makes sense. By trying the app first, then falling back to email or SMS only where needed, you can drive down per-message cost for population programmes without compromising reach. Letters should be reserved for statutory notifications, accessibility needs, or when you have a specific reason to prefer paper.
Efficiency isn’t just about unit costs, though. When people receive a trusted message in a channel they use, they’re less likely to ring the service for clarification, miss appointments, or misunderstand instructions. That reduces waste throughout the pathway—missed slots, no-shows, and duplication of effort. Over time, the compound benefit of clear, timely communication can be substantial, especially in high-volume services like screening and immunisation.
For programme managers, a useful pattern is to run short pilots that compare routes. For example, send a small cohort via “App-first then email”, and a matched cohort via “App-first then SMS”, and measure completion or attendance at the end of the journey (not opens). Even without email tracking, you can often infer which routing plan leads to higher completion with fewer follow-ups by looking at the final outcome metrics you control.
NHS Notify operates continuously, but human support is concentrated during the working day. That means you should design your processes so routine campaigns and bulk runs start during support hours and you have staff available to handle anomalies—such as a misconfigured template or an unexpected spike in bounces. For overnight sends that rely on push notifications, assume the pushes will queue until the morning window and plan follow-ups accordingly.
Message volume planning matters too. If you’re moving a high-volume service onto Notify for the first time—say, seasonal vaccination invites—coordinate with your onboarding manager. There may be practical considerations around ramp-up, such as testing SMS sender name approvals ahead of time or validating that templates render as expected in multiple languages and device contexts. Keep in mind that letters take the longest; if a letter is your only channel for a statutory notification, send early enough to meet your legal timeframe.
On the monitoring side, decide what “good” looks like. For digital channels, your best indicators are delivery rates, bounce codes (where relevant) and the completion of downstream tasks (bookings, confirmations, forms submitted). For letters, the feedback loop is slower; you might rely on returns management or follow-up campaigns. Importantly, be cautious about re-trying too aggressively; routing plans should avoid spamming people by stopping once a channel succeeds, and you should give each channel time to complete its normal delivery window before falling back.
Every platform has constraints. Knowing these early helps you design resilient communications and avoid surprises later.
Despite these limitations, most are there to protect patients and staff and to keep the system safe, predictable and respectful. With a little planning, teams can mitigate them while still achieving high delivery and completion rates.
The art of NHS Notify lies in your routing plan. Good routing plans reflect your audience, the urgency of the message, and the sensitivity of the content. For example, a long-term condition review invitation could be “App inbox first, email second, SMS third, stop when delivered,” sent during working hours with a friendly reminder a week later. A time-critical alert may use “App first, SMS second” because people notice texts quickly, with a follow-up phone call for the small fraction who still do not respond.
When you build routing plans, separate strategy from configuration. Strategy defines the logic: channel order, stopping rules, and cohort-specific variations. Configuration maps that to templates and schedules. Keep a central register of active routing plans so campaign teams don’t unknowingly duplicate or contradict one another. And agree up front what qualifies as “success” for a message—for instance, delivery on any channel, a booking completed, or a form submitted—so the plan can stop appropriately.
It’s also worth segmenting by risk and sensitivity. Messages that relate to safeguarding, mental health, or confidential services should default to the NHS App wherever possible because the message content never appears on a lock screen and sits behind authentication. For appointment reminders, where content is less sensitive, email or SMS may be acceptable fallbacks. Letters work well for complex instructions and for households where the NHS App is not used regularly, but they should not be your only channel for time-sensitive actions.
Successful adoption of NHS Notify starts during onboarding. You will need your ODS code, proposed sender names, and details for reply-to addresses (for email) and a candidate SMS sender ID. Clarify which services in your organisation will send their own messages and which will be sent on their behalf, and plan for ODS overrides where necessary so the right sender is shown. If you rely heavily on SMS, begin the sender name review process early to avoid bottlenecks.
Next, assemble a small cross-functional team: content designers, operational leads, and a developer or vendor who will handle integration. Agree a set of templates for typical journeys—first invitation, reminder, cancellation or rescheduling, preparation instructions, and follow-up. For each template, decide the personalisation fields you will support and create example values covering short, medium and long lengths. Store templates and routing plans in a shared repository with version control and a basic change approval process, especially for clinically significant messages.
For integration, choose API, MESH or both. Build a proof of concept that sends to a test cohort and validates delivery through to the end of the user journey. Capture message IDs and references in your system of record. Implement basic retry logic for transient errors and clear error handling for validation failures—such as mismatched personalisation fields. Above all, avoid including sensitive clinical detail in messages; instead, link to secure destinations or prompt the person to open the message in the NHS App.
NHS Notify gives NHS organisations a coherent, governed way to communicate at scale without inventing a new solution for every service. Its channel mix—NHS App inbox, email, SMS and letters—covers the spectrum of needs from instant nudges to formal notifications. Templates and personalisation keep content clear and relevant; routing plans let teams balance cost, speed and inclusivity; and reliance on ODS and PDS improves accuracy and trust. The platform’s constraints—no email tracking, strict sender identity controls, limited formatting on certain channels, and slower postal timelines—are purposeful and manageable with sensible design.
The most successful teams treat Notify as a service design tool as much as a technical integration. They treat sender identity as a trust signal, write accessible and respectful content, plan channel fallbacks carefully, and measure success by outcomes instead of clicks. They also plan for inclusivity, making sure that people who can’t or don’t use digital channels are still reached effectively.
In short, NHS Notify is not just a messaging utility; it’s a framework for consistent, high-quality NHS communications. By understanding its features, capabilities and limitations—and by designing with people’s real-world contexts in mind—NHS organisations can deliver clearer messages, reduce avoidable demand, and help more people take the right action at the right time.
Is your team looking for help with NHS Notify API integration? Click the button below.
Get in touch