Connect Any Patient Scheduling Platform
Send bookings from any patient scheduling platform to Ours Privacy, including Zenoti, Zocdoc, Phreesia, Relatient, Epic MyChart, and UpScript, using a native source, webhooks, an automation layer, or the Ingest API.
Patients often book on a platform you do not own. When the booking happens on a third-party site, the booking is still the conversion, so if that platform never tells Ours Privacy the appointment happened, the Google Ads or Meta campaign that produced it gets no credit and no-shows never show up in your reports.
Use this page to send bookings from any scheduling platform into Ours Privacy, whether or not that platform has a dedicated source. There is no supported-platform list you have to appear on. If the platform can send a notification, expose an API, or write to a table you already query, its bookings can reach Ours Privacy and be attributed to the campaign that drove them.
The Four Connection Paths
Every scheduling platform connects one of four ways. Work down the list and stop at the first one your platform supports.
- Dedicated source. The platform has a prebuilt source you configure in the dashboard. No engineering work.
- The platform's own webhook. The platform posts booking notifications to a webhook source URL. This covers most platforms.
- An automation layer. A HIPAA-compliant automation platform such as Keragon watches the platform and forwards bookings, for platforms with no outbound webhook.
- The Ingest API. Your backend, a scheduled warehouse job, or a script sends the bookings. This always works if you can read the data at all.
Platforms With a Documented Setup
These have step-by-step pages you can follow today. The mechanism differs and it matters, so it is called out per platform.
Patient scheduling and intake:
- Healthie: dedicated source. The platform sends scheduling and practice activity to Ours Privacy server-side, so it does not depend on the patient's browser.
- NexHealth: two paths that combine well. A webhook carries appointment outcomes such as booked, attended, and no-show, and the Web SDK or Tag Manager covers the booking funnel in between.
- Yosi: Web SDK or Tag Manager, covering scheduling and patient intake.
- Loyal Health: Web SDK or Tag Manager across Loyal-powered journeys.
General-purpose booking tools, commonly used for consults and provider calendars rather than clinical scheduling. All three are dedicated webhook sources:
Why the distinction matters: browser-based tracking captures what happens on pages the platform serves to the patient. If a booking is created, rescheduled, or marked a no-show entirely inside the platform's backend, only a server-side path will see it. When attendance and no-shows are what you need to measure, plan on a webhook, the Ingest API, or an EHR connection.
Platforms Customers Ask About Most
These platforms do not have a dedicated source today. Each one still connects, and the path is listed with its honest limitation so you know what to expect before you start.
| Platform | How it connects | What to know |
|---|---|---|
| Zenoti | Platform webhook to a webhook source | Often the system of record for both bookings and payments, so it can send booking and revenue outcomes. A common pattern routes bookings through a CRM first, in which case connect whichever system holds the confirmed appointment. |
| Zocdoc | Platform webhook or reporting export to the Ingest API | Ad click parameters passed into the booking flow can come back out with the booking, which makes campaign attribution straightforward. Confirm which fields your Zocdoc agreement exposes. |
| Phreesia | Platform webhook, or reconciliation on a shared identifier | Phreesia does not offer a native integration for marketing measurement. Webhooks or post-appointment reconciliation on an identifier such as email are the supported routes, and both work here: matching on email is exactly how off-site bookings stitch to the original web session. |
| Relatient | Platform webhook to a webhook source | Self-scheduling activity is webhook-based, so this is a direct configuration rather than a custom build. |
| Epic open scheduling | FHIR or HL7 interface, or an automation layer | Requires interface access granted through your Epic environment. Plan for your Epic team's involvement and a longer timeline than a webhook. See Choose an EHR or PMS Connection Path. |
| Epic MyChart | Warehouse or reporting feed, or an automation layer | MyChart bookings happen outside your website, and MyChart does not generally push booking notifications outbound for marketing use. The practical route is the appointment record once it lands in a reportable system: see Send EHR Data From Your Data Warehouse. Expect batch timing, not real time. |
| UpScript | Platform webhook or the Ingest API | Telemedicine consults often book on a separate domain. Treat that booking flow as its own conversion source, and see Cross-Domain Bookings below. |
| LeadingReach | Ingest API or an automation layer | Typically carries referral and lead flow while care is handled in the EHR, so connect it for lead capture and connect the EHR for attendance and revenue. |
| Google Forms | Automation layer or Apps Script to the Ingest API | Google Forms bookings have no outbound webhook. A short Apps Script on submit, or an automation platform, sends the submission. Reasonable for tour and consult requests; treat submissions as lead_captured rather than confirmed bookings. |
Other platforms by vertical
We are asked about these regularly. None has a dedicated source, and the mechanism depends on what your specific account exposes, so treat the middle column as where to look first rather than a guarantee. Your account representative can confirm before you commit to a timeline.
| Platform | Usual starting point | Vertical |
|---|---|---|
| Solutionreach | Platform webhook or automation layer | Patient engagement and recall |
| Weave | Platform webhook or automation layer | Dental and small practice communications |
| Luma Health | Platform webhook or automation layer | Health system patient access |
| Klara | EHR interface behind Klara, or an automation layer | Patient messaging and intake |
| Mindbody | Platform webhook or API | Wellness, spa, and fitness |
| Boulevard | Platform webhook or API | Medspa and aesthetics |
| SimplePractice | Automation layer or the Ingest API | Behavioral health and solo practice |
| Jane | Automation layer or the Ingest API | Allied health and physiotherapy |
| Tebra | API or warehouse feed | Independent practice management |
| DrChrono | API or automation layer | Ambulatory and specialty |
| Acuity Scheduling | Platform webhook | General-purpose booking, common for consults |
| Squarespace Scheduling | Platform webhook | General-purpose booking |
Why this table is vaguer than the one above: the platforms above appear in real customer conversations where we confirmed the mechanism. These are ones we can connect through the same four paths but have not verified account by account. We would rather tell you where to start than name a mechanism we have not confirmed for your setup.
Note: A platform absent from this table is not a platform we cannot connect. The four paths above are platform-agnostic. Send the platform name and the outcomes you want to measure to your account representative.
How an Off-Site Booking Gets Credited
This is the part that makes third-party bookings worth connecting. It is how you attribute a booking to the Google Ads or Meta campaign that drove it, and how that booking becomes an offline conversion your ad platform can optimize on, even though it happened on someone else's website.
- A patient clicks your ad and lands on your site. Ours Privacy captures the click identifiers on that landing page, including
gclid,fbclid, andmsclkid, and stores them with the visitor. At this point the visitor is anonymous. - The patient leaves to book elsewhere. They book on the scheduling platform, which your website never sees.
- The booking arrives from the scheduling platform through any of the four paths, carrying an identifier such as an email address or your own patient or lead ID.
- Ours Privacy matches it to the earlier session. A deterministic match on email or your external ID links the booking to the same visitor who clicked the ad. See Visitor Identity and Matching.
- The booking inherits the original ad click. Because the click identifiers are already on that visitor, the booking becomes attributable to the exact campaign that drove it, even though it happened off-site and later.
- The conversion can go back to the ad platform as an offline conversion, so Meta, Google, and Microsoft can optimize toward appointments rather than form fills. Control what is forwarded with Allow Listing Events and Data Mapping.
To make this work, send a stable identifier with the booking. Email is the most common and is usually available from a scheduling platform. Send identity as visitor properties rather than embedding it in event properties.
Important: Send the time the booking actually occurred, not the time your job ran, so back-dated bookings land on the correct day in your reports.
Map Platform States to Standard Events
Scheduling platforms disagree about what "booked" means. Some fire an event when a patient starts a booking, some only when staff confirms it, and some use "arrived" for attendance. Map them explicitly so your funnel counts what you intend.
| What the platform reports | Standard event | Notes |
|---|---|---|
| Booking started, "Schedule" clicked, request submitted, form submitted | lead_captured | Intent, not a booking. Keeps your booked count clean. |
| Appointment created or confirmed on the schedule | appointment_booked | The conversion most campaigns optimize on. Assign the appointment_id here. |
| Patient confirmed or acknowledged a reminder | appointment_confirmed | Optional funnel step between booked and completed. |
| Arrived, checked in, seen, visit closed, intake finished | appointment_completed | Attendance. For telehealth, send when the visit or intake finishes. |
| No-show, missed | appointment_no_show | Powers leakage analysis. |
| Cancelled and not replaced | appointment_cancelled | If the appointment moved instead, send appointment_rescheduled. |
| Moved to a new time or provider | appointment_rescheduled | Reuse the original appointment_id rather than cancelling and rebooking. |
| Payment taken at checkout | purchase | The GA4-aligned conversion ad platforms optimize on. |
| Revenue posted in the ledger | revenue_recognized | Often arrives later and in pieces. |
Deduplicate on appointment_id. Assign one ID at booking and reuse it through confirmation, attendance, and revenue. Platforms commonly resend the same state, and a stable appointment_id keeps one appointment from counting as several. For revenue that settles in pieces, also set a stable $distinct_id.
See Standard Healthcare Events for the recommended properties on each event, including service_line, provider_id, booking_channel, and location_id.
Cross-Domain Bookings
When the booking flow lives on a different domain than your marketing site, such as a telemedicine consult on a vendor domain, the browser treats it as a separate visitor.
Two options, and they combine well:
- Server-side is the reliable answer. Send the booking from the platform through any of the four paths with an email or patient ID. Identity matching connects it to the original session, so the domain boundary stops mattering.
- Client-side adds funnel visibility. If you can add the Web SDK or Tag Manager to the booking pages, you also see the steps in between, including starts that never finish.
Use both when you can. The client-side events show where patients drop off; the server-side booking confirms the appointment exists.
Prepare to Connect a New Platform
Bring these details to your account representative:
- The platform name, and whether it offers outbound webhooks, an API, or neither.
- Whether the booking data already lands in a warehouse or data lake you can query.
- The booking, attendance, and revenue outcomes you want to measure.
- Which identifier the platform can send with a booking, such as email or a patient ID.
- Which of the platform's states you consider a real booking.
- Whether patients book on a domain you control.
Next Steps
- Webhooks: configure the webhook source most platforms use.
- Ingest API Integration: send bookings from your backend or a scheduled job.
- Keragon: use a HIPAA-compliant automation layer for platforms with no webhook.
- Standard Healthcare Events: event names and properties to send.
- Visitor Identity and Matching: how off-site bookings join the original web session.
- Send EHR Data From Your Data Warehouse: when bookings already land in your warehouse.
- Choose an EHR or PMS Connection Path: connect the clinical system behind the scheduling layer.
How is this guide?