Clinic Membership now has a developer API, currently in beta, so your own developer or agency can connect the clinic's systems to your patients, bookings and invoices. If you have been looking for aesthetic clinic software with an API in the UK, here is what it does, how you switch it on, and how you stay in control of who can reach your data.
It usually starts with a simple question from your web developer: "Can we connect it to our own system?" Maybe you want new members to appear in your mailing tool, your website to show a welcome message after someone joins, or your bookkeeper's spreadsheet to fill itself in. Until now, the honest answer was usually an export and some copying and pasting.
With the API, the answer is yes, on your terms.
What the Clinic Membership API can do
The API lets an approved integration read and sync information from your clinic account. In plain terms, your developer can:
- Sync patients and bookings between Clinic Membership and another system you use.
- Read invoices so reports or bookkeeping tools can pick them up.
- Build custom workflows, such as reacting when a new member joins.
You decide exactly what each connection can see. Nothing is shared until you switch access on, and each set of credentials only reaches the areas you tick.
Because the API is in beta, it is worth treating it as something to test carefully before you rely on it for anything critical. The settings page asks you to review the terms before connecting production systems, and that is good advice.
Switching on the API in Clinic Membership
API access is off by default. Turning it on takes a few minutes and happens in one place, under Settings, then API:
- Read the API access and data processing section, then accept the API Data Processing Agreement by choosing Accept & continue.
- Switch on Enable API access.
- Add IP restrictions if you want them. This is optional, and useful for production credentials so only your developer's servers can connect.
- Click Save settings.
The API agreement is separate from the agreement that covers patient payments. Our Help Centre guide to GDPR and the Data Processing Agreement explains how the two fit together. Accepting it is the clinic's decision, made by you, before any data moves.
Scoped credentials in Clinic Membership
Once access is on, you create credentials for each integration. This is where you keep control.
Click Create credential and choose the permissions, or scopes, that integration needs. A tool that only needs to read invoices does not need to see patient details, so you simply leave those unticked. If you work with more than one developer or agency, give each their own credential so you can see who is doing what and switch one off without touching the others.
When the credential is created, a client secret is shown. Copy it straight away and pass it to your developer securely, because it is only displayed once. If it is lost, create a fresh credential rather than trying to recover the old one.
On the same tab, API activity shows what your integrations have been doing, so you are not left guessing whether a connection is busy, quiet or misbehaving.
Webhooks in Clinic Membership
An API answers when it is asked. Webhooks work the other way round: Clinic Membership tells your system the moment something happens.
To add one, you give a URL that your developer provides and choose the event types you care about. A useful example is the member.activated event. When a patient's membership goes live, your system receives the patient ID, email and application ID. With permission to read members, your developer can then look up that member's status and the treatments on their package, and use it to send a welcome, update a mailing list or tag them on your website.
There are also events for when a live membership has a failed payment or ends, so your own systems can stay in step rather than drifting out of date.
The developer side of Clinic Membership
You do not need to understand the technical detail yourself, but it helps to know where your developer will look. In your admin area, View API documentation opens the API docs, which list each request with an example response. That is the reference they will build from.
A typical first project looks like this: your developer creates a test credential with read access to members, adds a webhook for new members, and checks the results in API activity before anything touches a live mailing list or website.
When you might not need the Clinic Membership API
Not every clinic needs a live connection. If you are moving from another system and just want your patient list in place once, the import patients guide covers a one-off CSV import with no developer required.
It is also worth asking whether the job is really an integration at all. Many clinics add tools over the years for things their main software now does. Our post on bringing patient records into one place looks at that side of things.
For clinical notes and consent, Documenti is our sister EMR and works alongside Clinic Membership, so treatment records and the business side of the clinic sit together, as our post on the power of an EMR explains.
Your first Clinic Membership API project
If your developer has been asking, here is a sensible order:
- Agree the job in one sentence, such as "add new members to our mailing list".
- Accept the API agreement and switch on access under Settings, then API.
- Create one credential with only the scopes that job needs.
- Share the client secret securely, once, with your developer.
- Add a webhook if the job needs to react to events.
- Test, watch API activity, then go live.
The full walkthrough is in the developer API overview. Start small, keep scopes tight, and switch off any credential you no longer use.
