Outbound Webhooks
A webhook tells your systems something happened in Ready Practice, the moment it happens, without anyone having to ask. When a client books, your CRM hears about it. When a note is written, your data warehouse can pick it up. Nothing polls, and nothing waits for a nightly job.
This is the opposite direction from the Atlas API: the API is you asking us a question, a webhook is us telling you something changed.
What you get told about
Ready Practice sends an event when any of these happen:
- An appointment is created — a booking on any surface, including staff-created ones
- An appointment is cancelled
- A client is created — a new person joins your organization, however they arrived
- A clinical note is written
- A lab result arrives
- An error is logged — mostly useful if you run your own monitoring
Each event carries what happened and enough identifiers to look the rest up. It does not carry a full patient record, deliberately — see the note on health data below.
Setting it up
You provide a URL that accepts a POST, and choose which of the events above you want. Your endpoint should answer quickly and do the real work afterwards: treat the request as a notification, not as the place to run a long job.
If your endpoint fails or times out, delivery is retried. That means your handler must tolerate receiving the same event more than once — record which event ids you have already processed and ignore repeats. An integration that books a follow-up on every delivery will book several the first time a retry happens.
Verifying the request really came from us
Every request is signed. The signature is an HMAC-SHA256 over the timestamp and the request body, sent alongside them, and your endpoint should check it before trusting anything in the payload.
Your webhook URL will eventually be discovered — they always are. If your handler acts on whatever is posted to it without checking the signature, anyone who finds the URL can make your systems believe a client was created or an appointment cancelled. Check the signature, and reject the request when it doesn't match.
Also compare the timestamp against your clock and reject anything too old. That stops a captured request being replayed at you later.
Health data
Events carry identifiers and the fact that something happened — not the contents of a chart. If your system needs clinical detail, look it up through the Atlas API with a key scoped for it, so the access is permission-checked and audited like any other.
The practical reason is that a webhook endpoint is usually the least protected thing in an integration. Keeping health data out of the push, and behind an authenticated pull, means a misconfigured endpoint leaks far less.
Next steps
To ask questions rather than be notified, use the Atlas API.
To get a webhook configured, talk to your account contact with your endpoint URL and the events you want. Have signature verification working before you point it at production traffic.