When practice owners ask us whether they can pull something out of DrChrono — revenue numbers, appointment counts, patient lists — the answer is almost always yes. The more useful answer is: yes, and here's exactly how, and here's where it gets complicated.
This post is for operators who are evaluating what's possible before committing to a build. We'll skip the developer jargon as much as we can and focus on what matters operationally: what data you can access, what you can actually change through the API, and where the hard limits are.
What the DrChrono API Is
DrChrono exposes a REST API — a set of web addresses your systems can call to read and write data in your EHR. It uses OAuth 2.0 for authentication, meaning you authorize a connection once and get a token your application uses for subsequent calls. That token has scopes: read-only access is separate from write access, and you request only the permissions you need.
The API covers most of what your clinic runs on:
- Appointments — create, read, update, and cancel
- Patients — demographics, contact info, insurance, custom patient fields
- Billing — claim status, line items, copay information, billing profiles
- Clinical notes — SOAP notes, custom note templates
- Lab orders and results — ordered tests and returned values
- Scheduling — appointment profiles (slot types), exam rooms, provider schedules
That breadth is genuinely useful. Most of the dashboards and operational tools we've built for clinics — revenue trackers, flow boards, booking integrations — draw on a combination of those endpoints.
What You Can Do Well
Reading and displaying data
This is the API's strongest suit. You can pull your full appointment schedule for any date range, join it against patient records, and display it however your workflow demands. We do exactly this for the real-time patient flow board we build for clinic operators: the board polls /api/appointments every thirty to sixty seconds and shows the current state of every scheduled patient.
The same pattern underlies revenue dashboards. Pull billing records by date range, group by provider or appointment type, and you have a live view of what's been collected versus what's outstanding — without anyone doing manual exports.
Writing back to appointments and patients
The API isn't read-only. You can update appointment status (Arrived, Complete, and several others), change exam room assignments, add notes, and update patient fields. Write-back is what makes integrations feel seamless rather than bolted on: when a patient checks in through a kiosk your team built, that check-in posts back to DrChrono so the EHR is always the source of truth.
Write access requires you to request write scope during OAuth setup. Read-only tokens won't error visibly — they'll just return a 403 when you attempt a write. Check your token scopes before any production build.
Integrating with external booking flows
If you run a medspa or high-volume aesthetic practice, you probably have a booking widget that's separate from DrChrono's native scheduling. The API lets you create appointments in DrChrono programmatically, so bookings made through your website, a third-party tool, or a custom form land directly in the EHR without staff manually copying them over. You can also search for available appointment slots before presenting options to the patient — though the slot-availability logic is something you build around the scheduling data, not something the API hands you preformatted.
Where the Limits Are
No API is unlimited, and knowing the constraints before you build saves significant rework.
Rate limits
DrChrono enforces per-token rate limits. The specifics depend on your plan tier, but as a practical baseline: anything that hammers the API in tight loops will hit a 429 (rate limit exceeded) response. For polling-based tools like dashboards and flow boards, an interval of thirty seconds per call is comfortable. If you're doing a large batch operation — importing thousands of patient records, for example — you'll need to build in throttling and retry logic.
No native webhooks for most events
This is the constraint that surprises most practice owners. DrChrono does not push data to you when something changes. There's no "appointment status changed" event that fires to your server. You have to poll — call the API on an interval and compare the results to what you had before. For real-time tools, that means your "real time" is actually "every N seconds," and you design accordingly. Webhook support exists for a small subset of events (mainly around billing), but for appointment and patient data, polling is the model.
Some fields are read-only or write-constrained
The API surfaces most fields you'd expect, but not all of them are writable. Custom note fields, for example, can be read but writing structured data back into clinical notes has specific constraints depending on how those notes are configured. Billing claim submission also has a more limited API surface than reading — you can read claim status, but submitting claims programmatically requires working within a narrower set of endpoints. Before scoping a build around a specific field, verify the write path with a test token.
PHI and infrastructure requirements
The API handles patient health information, which means everything downstream of it — your server, your database, your caching layer — needs to live on HIPAA-eligible infrastructure with a Business Associate Agreement in place with your hosting provider. This isn't an API limitation per se, but it shapes the build: you can't call the DrChrono API from a browser-side script and log results to a free-tier database. The data has to stay in a controlled environment.
What to Build First
If you're new to integrating with DrChrono and want the fastest return, we'd point you toward two things:
- A morning dashboard — pull yesterday's billing records and today's schedule. That single view eliminates most of the manual morning prep for an owner or office manager. The data is all in appointments and billing; the build is mostly aggregation and display.
- Appointment status write-back from a custom flow — if you have any external booking or check-in step that currently requires staff to manually update DrChrono, automating the write-back is a high-leverage improvement. It's a single
PATCHcall per event, and it keeps your EHR accurate without the double-entry.
Both of these sit firmly within what the API does well, avoid the rate-limit and webhook constraints, and deliver visible value quickly. More complex builds — two-way sync with an external CRM, real-time lab result display, custom billing workflows — are all possible, but they benefit from having simpler integrations in place first.
How We Work with the API
The tools we've built and documented on our DrChrono apps page all run on this same API foundation. The revenue dashboard, the patient flow board, the booking attribution layer — each one is a different query pattern on the same set of endpoints, wrapped in infrastructure that handles auth, rate limiting, and PHI correctly.
If you're evaluating a build — or you started one and hit a wall on a specific endpoint — reach out. Walk us through what you're trying to accomplish operationally and we'll tell you honestly whether the API supports it cleanly, where the workarounds are, and what a production-grade version of it looks like.