10 Healthcare APIs Every HealthTech Developer Building for the NHS Should Know

Search "healthcare APIs list" and you'll get the same article fifteen times: a roundup of US-centric, FHIR-flavoured endpoints that read like a vendor brochure. Useful if you're building in California. Close to useless if your product has to clear NHS onboarding and exchange real patient data inside an English Trust.

The NHS API estate is its own world. There are over ninety APIs in the national catalogue, spanning FHIR R4, HL7 V3, MESH, and a few SOAP relics that refuse to die. For a developer or a founder sizing up a build, the question isn't "what healthcare APIs exist." It's "which ones will I actually have to integrate with, what do they really do, and which standard does each one speak." That's the list worth having.

This piece is for the developer, CTO, or digital lead scoping an NHS integration who wants the real map before committing engineering time. No definitions of FHIR. No history lesson. Just the APIs that matter and what each one is for.

Why a generic healthcare APIs list won't help you here

The gap between a generic healthcare APIs list and the NHS reality is the difference between knowing FHIR exists and knowing that NHS England has a working date of March 2027 to retire the EPS HL7 V3 API, which means anything you build against it today is already on borrowed time.

The NHS catalogue isn't a menu of equivalent options. APIs sit at different maturity levels, run on different networks (open internet versus HSCN), use different authentication models (CIS2, application-restricted, TLS mutual auth), and carry different service guarantees, from platinum 24/365 down to bronze business-hours-only. Two APIs that both say "FHIR R4" in the catalogue can demand completely different onboarding paths.

So the value of a list here isn't breadth. It's knowing which handful you'll genuinely depend on, and what each one costs you in integration effort.

PDS FHIR API: the one you'll touch first

Almost every NHS integration starts with identity. The Personal Demographics Service FHIR API lets you search for a patient, retrieve a record by NHS number, and update demographic details like name, address, registered GP, and nominated pharmacy. It's the FHIR R4 successor to the older HL7 V3 PDS interface, and it runs over the open internet rather than being locked to NHS premises.

If your product does anything with a patient record, you almost certainly need to trace and verify the NHS number against PDS first. Get this wrong and every downstream record you hold is built on an unverified identity. It's also where you'll meet your first "dirty data" problem: searches that return multiple matches or no clean match at all. NHS England even publishes test data packs specifically for the multiple-match scenarios, which tells you how routine that headache is.

The Spine and identity layer

PDS doesn't sit alone. It's part of the Spine, the national set of services that includes the Summary Care Record and the underlying identity and access machinery. For developers, the practical implication is authentication: many national APIs authenticate the end user through CIS2, NHS England's identity service, rather than just the calling application.

That distinction matters when you scope a build. An application-restricted API authenticates your software but not the clinician using it. A CIS2-authenticated API needs the actual user identified and authorised. The two imply very different things for your front end, your audit trail, and your DSPT posture. Knowing which model an API uses before you start is the difference between a clean onboarding and a rebuild.

GP Connect: getting at the GP record

GP Connect is how you reach data held in GP clinical systems. It comes in several flavours, and the distinction is worth getting right early. Access Record: Structured returns coded, machine-readable data. Access Record: HTML returns a rendered view for a human to read. There's Appointment Management for booking into GP systems, and a separate patient-facing family of GP Connect APIs for citizen apps.

The mistake teams make is treating GP Connect as one thing. It isn't. Picking Structured when you needed HTML, or building against the clinician-facing set when your product is patient-facing, means reworking your integration and your information governance case. Decide which record you actually need, and in what form, before you write a line of code.

e-RS: referrals without the paper

The e-Referral Service FHIR API handles paperless referrals between primary and secondary care, the national system that replaced the paper referral letter. If your product touches referral management, triage, or care coordination, this is the surface you integrate with to create and retrieve referrals.

It's a FHIR R4, internet-facing API on the modern API platform, which makes it one of the more comfortable national services to build against. The complexity isn't usually technical. It's understanding the referral lifecycle and where your product legitimately fits into a clinician's workflow without breaking the booking process that's already running.

EPS: prescriptions end to end

The Electronic Prescription Service is the national pipe for sending prescriptions from prescribers to dispensers. There are now two FHIR APIs here, EPS Prescribing and EPS Dispensing, and this is the live migration to watch.

The older EPS HL7 V3 API still works, but NHS England has signalled a working retirement date of March 2027, and all new functionality is landing only on the FHIR APIs. They've said dispensing suppliers will be contacted first. The practical lesson for any healthcare APIs list in 2026: if you're building anything prescriptions-related, build against the FHIR Prescribing or Dispensing API, not the HL7 V3 one. Anything you stand up on V3 now is technical debt with a known expiry date.

MESH: the workhorse nobody talks about

MESH, the Message Exchange for Social Care and Health, almost never makes the glossy healthcare APIs lists, and yet it moves an enormous volume of real NHS data every day. It's asynchronous, store-and-forward messaging: you put a payload in, it gets delivered to the recipient's mailbox, they collect it. Think of it as the reliable freight network underneath the flashier real-time APIs.

It's a silver service, operational 24/365 but supported only in business hours, and it underpins everything from screening data flows to demographics batch processing. If your integration involves bulk file movement or system-to-system exchange that doesn't need an instant response, MESH is very often the right answer, and far less brittle than trying to force everything through synchronous REST calls.

NHS App and Booking APIs: the patient-facing layer

If your product reaches patients directly, the NHS App API and the NHS Booking FHIR API are the surfaces that connect you to the national patient-facing layer. The NHS App API is a RESTful FHIR specification, openly documented, that lets approved services integrate with the App experience.

The thing to understand here is that patient-facing integration carries a heavier governance and assurance load than back-office system-to-system work. The technical spec is the easy part. The clinical safety case (think DCB 0129 and 0160) and the assurance to be allowed near citizen-facing channels is where the real timeline lives.

FHIR UK Core: the standard underneath the standard

This one isn't an API you call. It's the profile set that shapes nearly every FHIR API above. FHIR UK Core is the UK-specific constraint layer on base FHIR R4, defining how resources like Patient, Encounter, and Medication are actually structured for NHS use.

It belongs on this list because building to vanilla FHIR R4 and assuming it'll satisfy NHS endpoints is a classic and expensive mistake. The base standard is a starting point. UK Core is what the national services actually validate against. Read it before you model your resources, not after a validation failure tells you to.

How these fit together in a real integration

Walk through a single realistic flow and the list stops being abstract. A new patient-facing app needs to: verify identity against PDS, authenticate the clinician or citizen through the Spine identity layer (CIS2), pull the GP record via GP Connect, surface referrals through e-RS, handle prescriptions on the EPS FHIR APIs, move any bulk data over MESH, and shape every resource to FHIR UK Core. Each of those is a separate onboarding, a separate auth model, and a separate line in your assurance documentation.

That's the real reason these integrations consume so much engineering time. It's rarely one API. It's seven national services, each with its own network, authentication, service level, and governance path, stitched into something that has to behave as one coherent product. The integration layer, not any single API, is where NHS HealthTech builds quietly succeed or stall.

This is the problem WeHub's platform was built to absorb, by handling the orchestration, authentication, and transformation across these services so your team builds product rather than plumbing. But the point of this list stands on its own: know the seven or eight services you'll actually depend on, and you've already done the hard part of scoping.

The bottom line

A healthcare APIs list is only useful if it maps to the systems you'll actually integrate with. For NHS HealthTech, that shortlist is remarkably stable: PDS for identity, the Spine layer for auth, GP Connect for the record, e-RS for referrals, EPS for prescriptions, MESH for bulk movement, the patient-facing APIs if you reach citizens, and UK Core shaping all of it.

If you're scoping a build this quarter, start by writing down which of these your product genuinely needs and which standard and auth model each one uses. That single page tells you more about your real integration timeline than any architecture diagram, and it's an afternoon's work.