SMS API for private clinics and physio bookings

At the end of August 2026 NHS England counted 7.4 million referral to treatment pathways where someone was still waiting for consultant-led care, and the longest single list was trauma and orthopaedics, with 843,419 of them. Some of those people will book a private physio or a private consultant while they wait (the statistics don't say how many). For the clinic taking the bookings, the question is a smaller one: how does the booking system keep patients informed without someone on reception typing every text? This post is about wiring an SMS API for private clinics into that booking flow, and about what the texts should leave out.

What the waiting list figures say

The figures come from NHS England's monthly referral to treatment (RTT) statistics, published on 8 October 2026 for August. They cover consultant-led elective care in England. In 65.2% of the 7.4 million pathways the patient had waited up to 18 weeks, which the press notice says means "not meeting the 92% standard". The median wait was 12.2 weeks and 113,339 pathways had passed a year. Some patients are on more than one pathway, so NHS England puts the number of people at around 6.2 million.

Trauma and orthopaedics, the specialty for bones, joints and injuries to them, had 843,419 pathways open, and only 61.1% had waited up to 18 weeks, below the national figure. Physiotherapy in community clinics mostly sits outside these numbers, because RTT counts consultant-led pathways and, since February 2024, community service pathways aren't reported in the RTT data at all. So read the chart as demand for hospital orthopaedic care in general; it doesn't count physio patients.

How an SMS API for private clinics fits the diary

A private clinic's booking software already knows everything a reminder needs: who, when, where and with whom. The SMS API's job is to turn changes in the diary into texts, and five events cover most of it.

The reminder is the one that needs some thought. If the booking software sends it at the moment of booking with a schedule_at time, the API holds the text until then (CaptiFi Connect takes times up to a year ahead), and you store the message id it returns against the appointment. When the appointment moves, cancel that id with POST /messages/{id}/cancel, which works while the text is still scheduled or queued and refunds its credits, then schedule a new one.

The other way is a job in your own system that runs every few minutes and sends reminders for anything due tomorrow. It's easier to reason about when appointments move a lot, because the job checks the booking at the moment it sends, so a reminder can't go out for a slot that changed last week. Either approach works. Pick one, though, because running both is how patients end up with two reminders.

Timing is a choice too. A reminder exactly 24 hours ahead lands at 07:30 for an 07:30 appointment, which is early, and at 19:45 for an evening class. A fixed time the day before, say 10:00, avoids both, and Monday appointments can be reminded on the Saturday if the clinic is shut on Sunday with nobody there to answer an R. On CaptiFi Connect, campaign quiet hours (21:00 to 09:00 London time by default) don't hold texts sent one at a time like these, so the schedule you set is the schedule that runs. Work in London time and convert to UTC when you send, or the clocks going back in October will move every reminder by an hour.

Put the appointment id in client_ref on every send. It's your own reference, up to 64 characters, and it comes back on every message webhook, so a failed delivery can be tied to the booking without a phone number appearing in your logs.

Sending each text once

Booking systems retry. The diary's webhook fires twice, or a call times out and the code has another go. RFC 9110 doesn't count POST as idempotent and says a client "SHOULD NOT automatically retry a request with a non-idempotent method" unless it knows the repeat is safe, so without help each retry is another text on the patient's phone.

The fix is an Idempotency-Key header built from whatever makes a text unique: the appointment id, the kind of message and a version that goes up when the appointment changes, such as appt-5521-reminder-v2. A retry with the same key and body gets the first answer back and sends nothing. When the booking moves, the version changes and the new reminder gets a new key. Our post on sending a text exactly once goes through the retry loop in detail.

Build all of it against a test key first. CaptiFi Connect's test keys start cc_test_, send nothing, cost nothing and still fire webhooks, so you can move and cancel appointments in a copy of the diary and see exactly what a patient would have received. The quickstart has the first call.

What the clinic's texts leave out

One physio reminder looks harmless. The ICO's guidance on special category data is less relaxed about a run of them: "you might reasonably infer a person's health status from their list of appointments at an osteopath clinic or from an invoice for a series of physiotherapy sessions". A single "your appointment is on Thursday" says very little. Six of them from a clinic with "sports injury" in its name say a fair bit more, and the phone they land on may be shared with a partner or a teenager.

So the template carries the date, the time, the place and how to change it. It doesn't carry the body part, the treatment, the session number or the clinician's specialty. Our post on health information in a text has NHS England's guidance and a table of wording that says too much next to wording that says enough. For a clinic the reminder comes out roughly like this:

Ashgrove Clinic: reminder of your appointment on Thu 12 Nov at 14:15 at 8 Mill Lane. Reply C to confirm or R to rearrange.

The sender name is the other half. It sits on the lock screen above the message, so pick one that names the clinic and leaves the service out.

Replies: matching C and R to the right booking

Replies arrive as a message.received webhook carrying the inbound text's body and the from number. A reply has no booking id on it (the patient typed it), so your handler has to work out which booking it belongs to. The rule that suits most clinics is to look up the patient's next upcoming appointment by mobile number and act only when there's exactly one. "C" marks it confirmed; "R" flags it for reception to come back with times.

Three cases are better left to a person. A parent has booked two children on the same number, so one "C" could mean either. The reply isn't C or R at all ("running 10 mins late, sorry"). Or there's no upcoming appointment, which usually means someone has replied to an old text. All three should land in the two-way inbox for reception to read, with the booking left as it was. STOP is handled for you: the number goes on the opt-out list and an opt_out.created event arrives, which your booking system should record against the patient.

Answer the webhook with a 2xx straight away and do the work afterwards. Each delivery is signed with HMAC SHA-256, so check the signature against the raw body before you trust what's in it; the webhooks guide has the check in Node, Python and PHP.

Naming the clinician

Plenty of clinic texts say who the patient is seeing ("with Priya"), which is fine and often helps. A professional title is another matter. The HCPC says the professions it regulates have "designated titles that are protected by law", and for physiotherapists those titles are physiotherapist and physical therapist. Under article 39 of the Health Professions Order 2001, someone who uses one of those titles "to which he is not entitled", with intent to deceive, commits an offence. If a template says "your physiotherapist", check that every name the booking system can drop in beside it belongs to someone on the HCPC Register, locums included. Sports therapists and massage therapists booked through the same diary need wording of their own. (Templates that use first names only avoid the question.)

Reminders, recalls and marketing

The ICO's direct marketing guidance lists messages to "confirm or remind them about appointments" as service messages, which covers the confirmation, the reminder and the reschedule. A message that "actively promotes or encourages people to make use of a particular service, special offer, or upgrade" is likely to be direct marketing, and a "you haven't booked your next session" nudge or a spring offer on sports massage sits on that side of the line. Marketing texts need consent or the soft opt-in, plus an opt-out in each one, and our guide to UK SMS marketing rules covers both. Keep the two kinds in separate templates, and record a marketing opt-out in the booking system in a way that still lets the appointment texts go.

Common questions

Can my clinic booking software send text reminders?

Most booking software can call an SMS API through a webhook or an integration. If yours can't, a scheduled job that reads tomorrow's appointments and posts each one to the API does the same thing. Store the message id against the appointment so cancelling the booking can cancel the reminder too.

Do patients have to consent to appointment reminder texts?

PECR's consent rules are about marketing, and the ICO treats appointment confirmations and reminders as service messages. You still need a lawful basis under UK GDPR for using the number, and details that reveal someone's health are special category data. Tell patients when they book that you'll text them about their appointments.

What should a physio appointment reminder say?

The clinic's name, the day, the time, the address and how to confirm or change it. Leave out the injury, the treatment and the session number, because the text can be read on a locked screen by whoever picks up the phone.

How do I stop a reminder going for a cancelled appointment?

Cancel the scheduled text when the booking is cancelled. With CaptiFi Connect that's POST /messages/{id}/cancel, which works while the text is scheduled or queued and refunds its credits. If your reminders come from a job that runs each day instead, have it check the booking is still live at the moment it sends.