Notifications and integrations

Your team sees every appointment in the dashboard. This section is for everything else: getting a WhatsApp message or 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

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.

By WhatsApp

For the clinic that doesn't live in email. Add a number — the front desk's, your own — and a WhatsApp message arrives for every notification you picked:

Novedad de agenda en Clínica Demo.

Se canceló una cita.

👤 Paciente: María Pérez 📅 Fecha: lunes 12 de octubre, 10:30 👨‍⚕️ Profesional: Dra. Pazmiño 📞 Teléfono: 593991112233

Worth knowing before you turn it on:

• The number doesn't have to belong to a patient. It's someone on your team. Type it however you like (0991112233, +593 99 111 2233); we normalize it.
• You can add several numbers, same as with email: each is its own subscription and picks what it wants.
• If someone replies to that message, the bot doesn't answer. We know that number belongs to your team, not to a patient, so it never gets the "you need to be registered" reply. It isn't a channel for reaching us either: anything replied there goes nowhere.
• The intake questionnaire never travels over WhatsApp. The notification tells you a patient completed it, but the answers aren't in the message: they're health data and a WhatsApp message ends up on a personal phone. The answers live in the dashboard, and in the email if you have that channel on.
• It needs your WhatsApp number already connected. If your clinic isn't set up with WhatsApp yet, the screen won't let you create the subscription — there'd be nowhere to send it from.

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 accept http://: 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-Signature header (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:

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, a WhatsApp message or a webhook failed.
• WhatsApp notifications are for your team, not the patient. When your team books, moves or cancels an appointment from the dashboard, the patient does not get an automatic WhatsApp message — for now that's still a phone call, as always. The notifications in this section go to your clinic's own numbers.
• It isn't a two-way channel. If someone on your team replies to a notification, that message reaches nobody. To talk to a patient, use the clinic's WhatsApp the way you normally do.