Notifications and integrations
Your team sees every appointment in the dashboard. This section is for everything else: getting an email when an appointment is booked, or letting your own system know without anyone copying anything by hand.
Configure it under Configuration → Notifications and integrations.
What you can subscribe to
| Notification | When it fires |
|---|---|
| Appointment booked | Someone books: the patient over WhatsApp, or your team from the dashboard |
| Appointment rescheduled | An existing appointment moves to another date, time or doctor |
| Appointment cancelled | It's cancelled, from anywhere |
| Intake form completed | A patient finishes the intake questionnaire |
Subscribe to all of them or pick individually. If you pick all, anything we add later reaches you automatically.
By email
The simple option, and the right one for most clinics.
Each notification arrives as a self-contained email: patient, phone, date and time in your clinic's timezone, doctor and procedure. You don't have to open the dashboard to know what happened.
Two details built for an actual front desk:
- Emails about the same appointment thread together. The booking, the reschedule and the cancellation stay in one conversation in your inbox instead of three loose emails you have to reconcile.
- They carry a calendar attachment (
.ics). Opening it puts the appointment into Google Calendar, Outlook or your phone. If that appointment is later rescheduled, the new email updates the existing entry instead of duplicating it.
You can add several addresses — one for reception, another for the consulting room. Each is its own subscription and picks what it wants.
To your own system (HTTPS)
If your clinic runs an EHR, a billing system or any in-house software, notifications can go straight there.
We send a POST with a JSON body. Two things your software vendor will want to know:
- The address must be
https://. We don't accepthttp://: these payloads carry the patient's name and phone, and they don't travel unencrypted. - Every delivery is signed. We generate a per-connection secret and send the signature in the
X-Signatureheader (HMAC-SHA256 over the exact body), so your system can verify the notification came from us and not from someone who discovered the URL.
Authentication runs in two directions
These are two different things and it's worth not conflating them:
| What it proves | How | |
|---|---|---|
Signature (X-Signature) | The notification came from us | Your system verifies the HMAC |
| Outbound credential | We're allowed to call your system | We send whatever header you configure |
If your endpoint is open and you only need to confirm the sender, the signature is enough. This is the GitHub/Stripe model: the endpoint asks for no credentials but rejects anything without a valid signature.
To verify it you need the secret — it's on the connection itself under View signing secret, with buttons to copy and regenerate it. Regenerating invalidates the old one immediately, so update your system at the same moment.
If your endpoint requires authentication — normal for EHRs and billing systems — configure the credential header on the same screen: the header name your system expects (Authorization, X-Api-Key, …) and its value.
We store the value encrypted and never show it again: you can replace or remove it, never read it. Seeing •••••••• (unchanged) later means a credential is stored and you aren't touching it.
Without this, an endpoint that requires authentication will answer 401 to every delivery and the notification is given up on after six attempts.
Test before you trust it
Every connection has a test send button. It delivers a dummy notification — the exact same shape as a real one, but marked ping — and tells you immediately whether it landed or what failed.
Use it when setting up, and again whenever your vendor changes something. It's the difference between knowing it works and assuming.
When a delivery fails
We retry on our own: after 1, 2, 4, 8 and 16 minutes. If it still hasn't landed after six attempts, we give up.
View recent deliveries shows each connection's latest sends with the time, the result and the status code your system returned. Failed ones get a Retry button to send them again by hand.
Notifications are deleted after 24 hours, because they carry patient data and this isn't meant to be a second copy of your records. That's why "recent deliveries" is short: it's a control panel, not an archive.
What this is not
- It doesn't replace the dashboard. If a notification never arrives, the appointment is still booked and visible in Pingclínica. You never lose an appointment because an email or a webhook failed.
- There are no WhatsApp notifications. WhatsApp only lets you message someone within 24 hours of their last message, and your team doesn't message the bot. A notification that works only sometimes is worse than none, so we don't offer it.