Your Cliniko API Key Is Your Patient Database. Guard It Like One

If you are having anything connected to Cliniko, there is one question that matters more than price, timeline or design. Where does the API key live? Most clinic owners have never been told what that key is, which is unfortunate, because it is not a technical detail. It is the master key to your patient records, and the answer to that question decides whether your integration is safe or a breach waiting to be noticed.

What the key actually is

An API key is a long password that lets one piece of software talk to another on your behalf. When your website shows real appointment slots, it is using your Cliniko API key to ask Cliniko what is free.

What it can do: everything you can do. Read every patient record you hold, including names, contact details, appointment history and clinical notes. Create, change and cancel appointments. Add and edit patients. It is not a read-only pass and it is not limited to the booking page. It is your login, in a form software can use.

Why that matters: a stolen key does not look like a break-in. There is no forced door and no alert. Someone with your key is simply Cliniko's normal, well-behaved user, quietly reading everything you have. You would very likely never know.

The mistake: putting it in the browser

Here is the thing worth understanding, and it takes one paragraph.

Everything your website sends to a visitor's browser is readable by that visitor. All of it. The page, the styling, and every line of code that makes the page work. This is not a flaw, it is simply how the web works: the browser has to be given the instructions in order to follow them. Any visitor can view it, and on a laptop it is two clicks in a menu that has been in every browser for twenty years.

So if the key is in the code the browser receives, the key is public. Not hard to find. Not hidden behind expertise. Visible to anybody who looks, and findable in bulk by people who scan the web for exactly this.

This happens more than you would hope, because it is the quickest way to make a booking form work. The developer needs the page to fetch slots, the fastest route is to put the key straight into the page, and it works perfectly. The clinic sees a working booking form. Nobody sees the problem, because a leaked key looks like nothing at all.

How it should be done

The correct arrangement puts a server between the patient and Cliniko, and it is not exotic. It is the standard way this is built.

The key lives on that server, where visitors cannot see it. When a patient's browser needs available slots, it asks your server, not Cliniko. Your server holds the key, asks Cliniko, and passes back only the answer: these times are free. When the patient books, the same route in reverse. The browser never sees the key, never talks to Cliniko, and never could.

What that buys you beyond secrecy: your server decides what is allowed. It can be built so the only possible requests are "show me free slots" and "book this appointment". Even a determined person poking at it cannot ask it to list your patients, because it was never given the ability to answer that question. A key in the browser has no such limit: whoever holds it can ask Cliniko anything.

This is also why we build on the API with a server behind it rather than dropping in a widget. Not because widgets are unfashionable, but because the boring server in the middle is the part that makes it safe.

Why this is a bigger deal for a clinic

You do not hold ordinary customer data. You hold health data about identifiable people, which sits in the most protected category under UK data protection law. A leak here is not an embarrassing week. It is a reportable personal data breach with a regulator, a duty to tell affected patients in some circumstances, and a genuine professional problem.

And the responsibility does not transfer. You are the one holding the patient relationship. "Our web developer put it in the website" is an explanation, not a defence.

Three ways to be safe

Option one: do not connect anything. Use Cliniko's own hosted booking page and link to it. Where it genuinely wins: Cliniko holds the key, because it is their own system, and there is nothing for anyone to leak. If you are not buying traffic, this is a completely respectable answer and it is free. Where it falls down: patients leave your site to book, and it cannot answer a phone.

Option two: buy from a vendor and check their homework. Any reputable product keeps the key on their servers. Where it genuinely wins: it is their full-time job to secure it, and they will have been asked this by clinics before you. Where it falls down: you are trusting a third party with access to your records, so ask where the data is held, whether it stays in the UK or EU, and what happens to it when you leave. Trusting them can be entirely reasonable. Trusting them without asking is not.

Option three: have it built properly, with the key server-side. Where it genuinely wins: the key is on infrastructure you control, and the server can be built to permit only booking-related requests. Where it falls down: it costs more than a plug-in, and it only stays safe if whoever built it knew this. This is what we build, and the arrangement above is exactly how we built it for a live podiatry clinic.

The recommendation. There is no cheap-and-unsafe option worth taking here, because the downside is a health data breach rather than a bad month. Pick whichever of the three fits your budget, and make the key question a condition of the work rather than a curiosity.

Do this today, for nothing

Send one email to whoever built or maintains your website: "Is our Cliniko API key stored server-side only, and can you confirm it is not present in anything sent to the browser?"

A competent developer answers yes immediately, because they made that decision deliberately. If the answer is confused, or you are told it is fine because nobody would look, treat that as urgent. Cliniko lets you revoke a key and issue a new one, so a leak found today is a job for this afternoon rather than a disaster.

Send the email. If you get an answer you are not sure about, forward it to us and we will tell you plainly whether it is fine. That costs you nothing and no, it is not a sales call.