Developers

A small API, documented honestly.

Eight endpoints. One header. Booking and reviews, and nothing else yet. We would rather you knew the exact shape of it before you start than discover it halfway through a build — so everything on this page is marked for what it actually is.

See what’s live API add-on · $99/month

8 live endpoints
Owner-issued keys
Every call logged

GET /api/appointments Live

curl -H "X-Api-Key: YOUR_API_KEY" \
  "https://{your-qlynic-host}/api/appointments
  ?from=2025-11-01&to=2025-11-30
  &doctorId=20&status=booked,confirmed"

# the same call is generated for you, with your own
# key already in it, under Settings → API Keys

Auth · one header, no OAuth dance cURL · Postman · JS fetch

Live

Callable today. A real path, a real method, and a copy-paste sample waiting in your dashboard with your own key already filled in. If it is marked live on this page, it answers.

Planned

Not built yet, and not pretending to be. Planned work is named and nothing more — no path, no request body, no sample — because there is nothing there to call. Build against the live list only.

The live surface

Two nouns. Eight calls.

Appointments and reviews. Every path below answers today — and these are the eight we document and support. There are sixteen actions in the controllers; the eight not listed are bulk delete and the review update/delete pairs, which work but are not part of the contract.

8/16 documented & supported The other eight exist and are undocumented. Four of them delete things. Do not build on those.

Base URL https://{your-qlynic-host} Your clinic’s own Qlynic host. The dashboard builds every sample against it automatically, so you never have to look it up.

/api/appointments

Live 6 calls

GET /api/appointments List appointments Filter by date range, doctor and status. ?from · to · doctorId · status
GET /api/doctors List the doctors Id, name, title, default duration and gap. This one is not written to the usage log.
POST /api/appointments Create an appointment It arrives with status booked. doctorId · startUtc · endUtc · patientName · patientEmail · patientPhone · reason
POST /api/appointments/{id}/status Change a status Cancel it, or move it along. An external client cannot set confirmed. Only the clinic confirms a visit.
POST /api/appointments/bulk Create many at once One request, an items array.
POST /api/appointments/status/bulk Cancel many at once An array of IDs and one status. appointmentIds · status

/api/reviews

Live 2 calls

GET /api/reviews List reviews All of them, or one doctor’s. ?doctorId
POST /api/reviews Add a review Rating and comment against a visit. The doctor comes from the appointment. appointmentId is mandatory. A review has to belong to a visit that actually happened. appointmentId · rating · comment · status

Every call returns JSON, but not one shape — some rejections come back as a bare string rather than an object, so parse defensively. Response schemas ship with the OpenAPI spec, which is Planned and listed further down. Working samples in cURL, Postman and JavaScript are generated for you, with your own key already in them, under Settings → API Keys.

Keys & control

Two switches, and what they really do.

Credentials are issued per client, not per company. Two switches ride on every key, they are set when you create it, and only the clinic owner can create one at all. Read the switches literally: today the patient switch withholds the free-text visit reason, and the status switch governs cancelling. Neither one hides a name, an email or a phone number, and neither one guards a delete.

Booking widget active

a3f9c21e… key prefix · first 8 characters

Patient identifying data off
Change appointment status off

The key you hand to whoever builds your website. Both switches off — which today means no visit reasons and no cancelling. It can still read patient contact details, so treat it as a real credential.

Ops automation active

7d10b8ea… key prefix · first 8 characters

Patient identifying data on
Change appointment status on

Your own script, reconciling the day. Both switches on — and every call it makes is filed under its name, not under “the API”.

Same clinic, same endpoints, two credentials that differ on exactly two things: the visit reason, and whether they may cancel. Turn one off and it stops answering immediately; regenerate it and the old secret dies on the spot, so plan the cutover.

Appointments and reviews, on the record.

logging

Every call, bar one

GET /api/appointments 200 booking-widget · 09:14:02 · 198.51.100.24
GET /api/appointments/1042 200 ops-automation · 09:14:55 · 203.0.113.9
GET /api/reviews 200 booking-widget · 09:16:20 · 198.51.100.24

Sample rows. Each one carries the method, the path and query, the status that came back, which key made the call, when, and from what address. Calls that fail are written the same way, with whatever status they got. Filter the log by client and by date in the dashboard.

Every key event

apikey.created API client “Booking widget” created · key a3f9c21e… · PHI:no · manage-status:no
apikey.viewed API key revealed · key a3f9c21e…

An owner can reveal a key again later, and that reveal is itself an event in the audit trail. Only the first eight characters are ever written down — the secret itself never reaches a log that anyone could read it back out of.

A key grants access to your clinic’s data. Treat it like a password: never put one in a public repository, a front-end bundle, or an email.

Not built yet

Five things that don’t exist.

Everything below is on the list, and none of it answers. There is no path to try and no sample to copy, because there is nothing at the other end yet — and a page that pretends otherwise costs you a weekend before you find out.

Planned

01 More resources Doctors, services and availability. Today the API can move an appointment around but cannot tell you who is working on Thursday, which is the first thing most booking pages need to know.
02 Webhooks So Qlynic tells you when a booking changes, instead of your script asking the same question every sixty seconds and finding out a minute late.
03 OpenAPI spec A machine-readable description of every endpoint, including the response shapes this page does not publish yet. Point a generator at it and your client writes itself.
04 Bulk export Your own data out in CSV or JSON, on demand, without paging through a list endpoint ten thousand rows at a time.
05 Published rate limits Ceilings written down rather than discovered. A runaway script should degrade politely, not take the clinic’s morning with it.

There are no dates on this page.

A date we might miss is worth less to you than a list you can trust. We would rather tell you what is true today and let you plan around it than put a quarter next to something and hope.

If one of the five above is the thing standing between you and building something, say so. That is genuinely how the order gets decided — there are not many of us, and we would rather work on the one somebody is waiting for.

Tell us which one

Get a key

You can be making calls this afternoon.

Three steps. The owner switches on the add-on, creates a client with the scopes you want it to have, and copies a sample that already has the key in it.

01 Switch on the API add-on Flat per clinic, whatever your doctor count. It sits beside the plan rather than inside it, and it comes off the same way it went on.
02 The owner creates a client Settings → API Keys. Name it, set the two switches, and the key appears. You can reveal it again later — and that reveal is written down.
03 Copy a working sample cURL, Postman or JavaScript, generated with your own key already in it. Paste it, send it, and you are talking to your clinic.

$99 per month
flat per clinic

What that is today: the eight endpoints on this page, keys scoped per client, and the usage log behind every call.

The five planned items further up are not part of it yet. When they land, they will be listed here as live — not before.

See pricing Email support

If you get stuck, you are emailing the people who wrote it.