Webhooks and APIs Explained for Practice Managers: What "Connects to Automation" Actually Means

A vendor demo says the platform "has a robust API" and the sentence usually lands as reassurance: good, that's the technical box ticked, we can move on to talking about the AI. It's the wrong place to stop. Having an API answers one question. Whether your practice, specifically, can get an AI agent connected to it, without months of accreditation paperwork, answers a completely different one, and the two get conflated constantly in sales conversations.

This guide covers both halves in plain English: what a webhook and an API actually are (no engineering background required), and the accreditation reality that determines whether "it has an API" means "we can start next week" or "we need NHS Digital's sign-off first."

The Plain-English Version

An API (Application Programming Interface) is a documented way for one piece of software to ask another piece of software for something, or tell it to do something. Your practice's booking system has an API if there's a formal, published way for another program to ask it "what appointments are free on Tuesday?" or tell it "book this patient into this slot." It's a doorway the vendor built on purpose, with rules for how to knock.

A webhook is the reverse direction. Instead of your AI agent repeatedly asking "has anything changed yet?", a webhook lets the other system push a notification the moment something happens: a new patient registered, a form was completed, an appointment was cancelled. The plainest way to picture it: an API is like calling a shop to ask if an item is in stock. A webhook is like the shop calling you the second it arrives. Both get you the same information eventually; a webhook gets it to you the instant it exists, which matters enormously for anything time-sensitive, a cancellation that should trigger an immediate rebooking offer, a message flagged urgent that should reach a human within minutes, not at the next scheduled check-in.

For most practical AI automation in a medical practice, you want both: an API to pull information and trigger actions on demand, and webhooks to react instantly when something changes without your system having to constantly ask.

The 90-Second Test That Predicts Your Project's Shape

There's a simple check any non-technical practice manager can run before spending a penny on discovery: for every core tool your practice runs on, the booking system, the EHR, the billing platform, ask one question. Does it offer an API, an MCP server (a newer, AI-agent-specific standard), or a documented integration path, increasingly published as a file called SKILL.md or AGENTS.md?

If yes, in our experience the odds are well above 90% that the workflows built on that tool can be cleanly integrated with AI agents. The agent walks through the front door the vendor built on purpose, which makes the work predictable, faster to scope, and far less likely to break when the vendor ships an update. If the answer is no, integration is still possible, but it changes shape: the agent has to operate the software the way a human does, through the screen, using browser automation that clicks buttons and reads pages. That works, but it's inherently more brittle. It breaks when the vendor moves a button or redesigns a page, and it carries a real ongoing maintenance cost. It's the difference between using a door and climbing through a window every time, and it's the single most useful thing a non-technical decision-maker can establish before scoping a project.

Why Vendors Blur the Distinction in Sales Conversations

It's worth naming directly why "has an API" gets used so loosely in sales conversations: it's a genuinely reassuring phrase to a non-technical buyer, and clarifying it in detail, "yes, but access requires a months-long accreditation process," is a much harder sentence for a salesperson to say in a first call. This isn't necessarily dishonesty; often the salesperson themselves doesn't know the accreditation requirement exists, because it's handled by a different team or a different part of the business entirely. The practical response is the same either way: push past the first "yes, we have an API" answer and ask the specific follow-up questions above, in writing, before the project timeline and budget are finalised around an assumption that turns out to be wrong.

The Part the 90-Second Test Doesn't Cover: Who's Allowed Through the Door

Here's where the picture gets more complicated for UK practices specifically, and it's the reason "does it have an API" is necessary but not sufficient. EMIS and SystmOne, the two dominant UK GP clinical systems, both genuinely have APIs. That's not in question. What's less advertised is that access to those APIs is controlled through formal accreditation, not open to any developer who wants to build against them.

Connecting to SystmOne's GP module as a third party requires completing NHS Digital's IM1 Pairing Integration Process, which includes a Clinical and Information Governance prerequisites form and a Supplier Conformance Assessment List (SCAL) submitted for NHS Digital review before development can even begin. EMIS runs a comparable structure through its own Partner Programme APIs and the NHS IM1 interface mechanism. GP Connect, the national standardised layer sitting across both systems, exists specifically to reduce this friction for approved, accredited integrations, but "approved and accredited" is still the operative phrase.

This matters practically because it changes the timeline conversation. A vendor or in-house developer who says "EMIS has an API, we can connect to it in a sprint" is either already accredited (worth confirming directly, ask for evidence) or hasn't accounted for an accreditation process that can run for months before a single line of integration code gets written against live patient data. This is a genuinely different project shape from integrating with, say, a shared inbox platform or a booking tool that publishes an open API with no comparable gatekeeping.

Reading a Vendor's API Documentation Without Being a Developer

A non-technical practice manager doesn't need to read code to get useful signal from a vendor's API documentation page, if one exists at all. A few things worth checking directly, or asking a technical partner to check on your behalf, before assuming "has an API" settles the question:

• Is there a public, dated changelog? A maintained changelog suggests the API is actively supported and versioned responsibly. Its absence suggests the API might be an afterthought that could change without notice.
• Does the documentation mention rate limits? Every real API has them, a cap on how many requests can be made in a given period. If a vendor's documentation doesn't mention this at all, that's often a sign the documentation is marketing copy rather than something an engineer can actually build against.
• Is there a sandbox or test environment? A vendor that provides a safe testing environment before you touch live data is signalling that they expect real integrations to happen, and have thought about what that requires. Its absence often means integrations have been rare or informal.
• Does the API documentation require a login or a sales call to view at all? Genuinely open, developer-friendly APIs publish their documentation without a gate. An API that requires a sales conversation just to see what's technically possible is often a sign that access, and pricing for that access, is handled case by case rather than through a standard, predictable process.

None of these checks require technical expertise, and running them before a sales call changes the conversation from "convince me you have an API" to "walk me through this specific limitation I found in your documentation," which tends to get a much more honest answer.

Why This Question Should Come Before the AI Vendor Conversation

Practices often bring in an AI vendor first and only discover the integration reality partway through discovery calls, once the vendor's own engineers start asking about API access. Reversing that order, running the systems audit described above before any AI sales conversation begins, changes the dynamic entirely. Instead of a vendor telling you what's possible based on what they assume your systems support, you walk into that conversation already knowing which of your platforms are a clean integration and which will require either an accreditation process or browser automation. That puts you in a position to evaluate a vendor's proposal against reality, rather than taking their word for how straightforward the project will be.

What "No API" Actually Means for a Project

When a tool genuinely has no API and no accreditation path exists because there's nothing to accredit against, the fallback is browser automation: a headless or visible browser that logs in and clicks through the interface the way a staff member would. This is a real, working approach, and sometimes the only option for a legacy internal tool with no vendor support left, built by a contractor who's no longer reachable and left no documentation. It's also inherently more fragile than API-based integration: it breaks silently when the vendor changes a button label or moves a form field, and someone has to notice and fix it, which is an ongoing cost most practices underestimate when comparing quotes between an API-based build and a browser-automation-based one.

The Competitor Pulse Check

Webhooks in Practice: A Concrete Example

To make the abstraction concrete: imagine a patient cancels an appointment through an online booking portal. Without a webhook, an AI agent trying to keep a waiting list up to date would have to repeatedly ask the booking system "has anything changed?" every few minutes, wasting requests and introducing a delay between the cancellation and the agent noticing it, a pattern called polling. With a webhook configured, the booking system pushes a notification the instant the cancellation happens, and the agent can immediately check the waiting list and offer the slot to the next patient, often before the cancelling patient has even closed the confirmation screen. That gap, between polling every few minutes and reacting instantly, is the entire practical value of a webhook, and it's the difference between a waiting-list feature that feels responsive and one that quietly loses slots to timing delays.

Frequently Asked Questions

What's the difference between a webhook and an API in simple terms?

An API is you asking another system for information or telling it to do something. A webhook is the reverse: the other system tells you the moment something changes, without you having to ask. Most practical automation uses both together.

Does EMIS or SystmOne have an API a practice can just connect to?

Both have APIs, but access requires formal accreditation, through NHS Digital's IM1 process and a Supplier Conformance Assessment List for SystmOne, and a comparable partner programme process for EMIS. This isn't something a developer can connect to on day one without going through that approval first.

How can a non-technical practice manager check if a tool can support AI automation?

Ask the vendor one direct question: does the platform offer a documented API, an MCP server, or a published integration guide? If yes, integration is very likely to go smoothly. If no, ask specifically what the fallback approach would be and what its ongoing maintenance looks like.

What is GP Connect and does it solve the accreditation problem?

GP Connect is the national standardised API layer sitting across EMIS and SystmOne, built to reduce integration friction across UK GP systems. It doesn't remove the need for accreditation, it standardises what accredited integrations look like once you're approved.

What happens if the tool we use has no API at all?

Integration is still possible through browser-based automation that operates the software the way a human would, but it's more brittle, breaks when the interface changes, and carries a higher ongoing maintenance cost than an API-based integration. Budget and timeline expectations should reflect that difference.

Is a webhook more expensive or complex to set up than an API connection?

Not inherently. Most modern platforms that offer an API also offer webhooks as a built-in configuration option, often just a URL to paste into a settings page rather than a separate purchase. The complexity comes from what happens on the receiving end, whatever system or agent processes the webhook notification, not from the webhook mechanism itself.

What's a practical first step for a practice manager who isn't sure what their current systems support?

List every core platform the practice runs on, then request written confirmation from each vendor of whether an API, MCP server, or documented integration path exists, and whether third-party access requires any accreditation process. Having that single document in hand before any AI automation conversation turns a vague scoping call into a specific, well-informed one.

What's Next

Knowing whether your core systems have a genuine, accessible API, and whether that access requires accreditation, is the single most useful thing to establish before scoping any AI automation project. Our agentic AI for medical practice admin hub covers how this fits into the wider architecture, and our guide to encrypted email for UK practices covers a similar accreditation question on the compliance side. Once the API question is settled, our guide to AI-drafted patient replies and human approval and our email security gateway guide cover the layers that typically get built on top of that API access. If you're not sure whether your practice's systems are integration-ready, get in touch and we'll run the check with you before you commit to a build.