DrChrono API: What an Owner Can Connect

An API is a documented door that another program uses to read or write data in your DrChrono account, with your permission. DrChrono documents one, with permission-based sign-in and webhooks, so a developer or vendor can connect ad tracking, reporting or other software to it, while online scheduling, reminders and intake forms are already built in.

Quick answer

Check the built-in features first: DrChrono's own pages describe online scheduling, reminders and intake forms. The API matters when you want data to leave DrChrono, for example appointment outcomes going to an ad account or a report. Someone on your team with the Settings permission creates the connection, and a developer or vendor reading patient data through it needs a business associate agreement with you. DrChrono's API terms say it may charge for API use and name no price, so ask before you plan around it.

What does DrChrono actually document?

DrChrono calls its APIs RESTful, which means a developer's program asks for or sends data over ordinary web addresses (DrChrono support, checked 2026-10-12). Sign-in uses OAuth 2.0, the same kind of permission screen you see when an app asks to access your Google account (DrChrono API reference, checked 2026-10-12).

Two limits matter to you. Access is split into scopes, which are the categories of data an app asks for, and into user permissions you grant inside DrChrono, and an app needs both. An application is also capped at 500 calls an hour by default, and a higher cap has to be requested from DrChrono (same reference).

DrChrono's API terms also cover FHIR APIs, FHIR being a standard format for exchanging health data published by HL7 International. Its federal health IT certification page lists a standardized API for patient and population services and names a FHIR product from Dynamic Health IT among the software it relies on (DrChrono certification page, checked 2026-10-12). A support article says apps built on FHIR can be launched from an App Directory tab inside a patient chart, and that a new one is requested through a questionnaire (DrChrono support, checked 2026-10-12). The main API reference lists no FHIR addresses, so ask DrChrono which FHIR access and fees apply before a vendor plans around it.

Which of your goals need the API at all?

Start from what you want done. The built-in column uses only what DrChrono's own pages say; where they say nothing, the cell says so.

DrChrono describes its Marketplace as the place where integration partners are seen by DrChrono clients, and invites integrators to become partners (DrChrono partners page, checked 2026-10-12). The page states no partner fees and no approval process. For the booking side, my notes on DrChrono online scheduling go further.

Who switches the connection on, and what can DrChrono change?

DrChrono's support article says the API page needs the Settings permission. A user with it goes to Account, then API, chooses New Application, and fills in a name and a redirect address, the web address where DrChrono sends the user back after approving (DrChrono support, checked 2026-10-12). Name the application for the service it provides, so you can tell later which connection is which.

The terms give DrChrono wide room: it may suspend the API immediately to prevent damage or misuse or for maintenance, giving notice first only where reasonable, and it may limit the number of calls without notice (DrChrono API terms, checked 2026-10-12). A clinic process should never fail silently when a connection stops, so ask who is told, and how fast.

What is a webhook, and what can it announce?

A webhook is a doorbell. Instead of a program asking DrChrono every few minutes whether anything changed, DrChrono sends a message the moment a chosen event happens. You set one up on the same API page, with a callback address that you control and a secret token DrChrono sends along so the receiver can tell the message is genuine (DrChrono API reference, checked 2026-10-12).

The documented events include an appointment being created, modified or deleted, a patient being created or modified, a clinical note being locked or unlocked, lab orders, tasks, and a patient payment being deleted. If the receiving program does not answer with a success code, DrChrono retries three times, at 1, 3 and 7 hours after the event, and after that someone must resend by hand. A feed needs a quiet daily check, not only a doorbell.

Can a developer see my patients?

Yes, if the scopes you approve include them, and that makes the developer or vendor a handler of protected health information (PHI, health data tied to a patient). Under HIPAA, a practice may disclose PHI to a business associate, a person or company doing work for it that involves patient data, once it has satisfactory assurances in a contract or other written arrangement, called a business associate agreement or BAA, that the data will be safeguarded (HHS, checked 2026-10-12). HHS's examples include health app developers and IT vendors whose work for a practice involves its patients' data.

DrChrono's API terms add that a developer receiving PHI must obtain the client's written authorization and sign a HIPAA business associate agreement with that client before obtaining any PHI. They also say that neither DrChrono nor the developer is the other's business associate (DrChrono API terms, checked 2026-10-12). The contract that matters is the one between you and the developer. The BAA itself is a US idea. A Canadian practice under PIPEDA answers for any personal information it gives a developer to process, and has to secure an equivalent level of protection through the contract or by other means (PIPEDA, Schedule 1, clause 4.1.3, checked 2026-10-12). Four provinces, Ontario, New Brunswick, Nova Scotia and Newfoundland and Labrador, also run separate health information statutes (Office of the Privacy Commissioner of Canada, checked 2026-10-12).

How does an ad click travel to a booked visit and back?

For a medical practice in the US, I built and debugged a link from DrChrono to Google Ads: each booking carries the ad click id, and booked or completed visits return to Google Ads as offline conversions. Four things have to hold, in owner terms.

Click id saved

when the visit is booked

Status read

from the API or a webhook

Outcome checked

attended, not just booked

Sent to Google

click id, value, time

Click id saved

when the visit is booked

Status read

from the API or a webhook

Outcome checked

attended, not just booked

Sent to Google

click id, value, time

The reference lists appointment statuses: Arrived, Checked In, Checked In Online, In Room, In Session, Complete, Confirmed, Not Confirmed, Rescheduled, Cancelled and No Show, plus custom statuses a practice defines. Asking for appointments requires a date filter, and deleted or archived ones appear only when requested (DrChrono API reference, checked 2026-10-12). Which of those words counts as a real visit is your decision, and the field mapping is covered here.

Only a click id, a value and a time go to Google; names, diagnoses and notes stay inside DrChrono. Google's file import also needs a conversion name spelled exactly as in the ad account and a time zone for the conversion time; Google now labels that file route legacy and points advertisers to its Data Manager (Google Ads Help, checked 2026-10-12). The click id has to be captured before the booking exists, because DrChrono has no way to supply it afterward.

Illustrative: the numbers in this example are invented for an imaginary physical therapy practice, and no client supplied any of them. It spends $3,000 on ads in a month and the ad account counts 30 booked appointments. By the practice's own status list, 24 were attended, 4 were no-shows and 2 were cancelled.

Run your own numbers the same way: spend divided by bookings, then spend divided by attended visits. A booking-only report hides the gap between those two lines.

What should you ask a developer before hiring one?

• Which scopes will the application request, and why does each one need to be there?
• Where are the sign-in tokens stored, and who can read them? A connection's access token expires after 48 hours and renews with a refresh token that does not expire unless it is revoked or the user authorizes the app again, so that refresh token is the thing to protect (DrChrono support, checked 2026-10-12).
• Which fields leave DrChrono, and where is a copy kept?
• Is there a log of every send, and can I read it?
• Who gets a message when the connection breaks or a retry runs out?
• Will you sign a business associate agreement with the practice before touching PHI?
• Will the work avoid screen scraping, which DrChrono's API terms prohibit?

If the answers are vague, a tool with a fixed scope and a signed agreement is safer than a clever custom build.