DrChrono API: a guide for product teams (2026)

Updated October 2026

The DrChrono API is a REST API with OAuth 2.0, documented in public at app.drchrono.com/api-docs. A new app can only connect to users in its own DrChrono account until DrChrono accepts you as a business partner. If you sell software to many DrChrono practices, the partner step is the first thing to plan for, ahead of any code.

This guide is for product and engineering teams deciding whether and how to build on DrChrono. It covers access, auth, limits, webhooks, what you can write back, FHIR, fees and the failures we see most often. Every DrChrono fact here comes from DrChrono's own public pages, read on 28 October 2026, and the sources are listed at the end. If you want a team to build it with you, see our DrChrono integration services.

Key takeaways

• DrChrono's main API is a proprietary REST API (version v4, "Hunt Valley"). The schema we read lists 168 paths and 323 operations across scheduling, patients, clinical, labs, billing, tasks and messages.
• New API apps start in private mode. Private apps can only connect to users in the same account or practice group. Public mode, which lets you connect to other practices, is reserved for business partners.
• Access tokens last 48 hours. Refresh tokens get you a new one without asking the user again.
• The default rate limit is 500 calls per hour per application, reset at the top of each hour. Over the limit you get HTTP 429.
• Webhooks exist for appointments, patients, clinical note lock and unlock, lab orders, billing line items, tasks and a few others. Failed deliveries are retried three times, at 1, 3 and 7 hours.
• Clinical notes are read-only as a whole. You write note content through clinical note field values.
• DrChrono's certified FHIR API is a patient-access service run with Dynamic Health IT's ConnectEHR, built from C-CDAs. It is not a general developer platform for writing data.
• DrChrono may charge fees for API use. The docs do not publish prices. Ask api@drchrono.com.

DrChrono API facts at a glance (October 2026)

Does DrChrono have an API?

Yes. DrChrono publishes a REST API reference at app.drchrono.com/api-docs. The page is rendered from an OpenAPI schema that anyone can download from https://app.drchrono.com/openapi-schema. On 28 October 2026 that schema was labelled "v4 - Hunt Valley" and listed 168 paths and 323 operations, 159 of which create, change or delete data.

DrChrono's license terms name two kinds of API. "FHIR APIs" are the HL7 standard APIs. "Proprietary APIs" are DrChrono's own interfaces. Almost everything a product team builds on, such as booking, patient sync, notes, labs and billing, uses the proprietary REST API. The FHIR side is narrower, and we cover it below.

DrChrono's own getting-started steps are short: read the docs, log in and go to Account > API, and join the developer forum, a Google Group at groups.google.com/g/drchrono-api.

Private vs public apps: the access question that decides your plan

When you create an API application in DrChrono, it starts in private mode. DrChrono's support article says a private application "can only connect to a user from the same account or practice group". Private mode has no other API or webhook limits.

Public mode lets an app connect to DrChrono users outside its home account. DrChrono says public mode "is currently reserved for business partners" and is meant for "an organization or developer with multiple DrChrono clients". You apply through the partner form at partners.drchrono.com/become-a-partner, and the partnership team contacts you.

What this means for your plan:

• One practice building for itself. A private app in that practice's own account is enough. The practice creates it, and its users authorize it.
• A vendor selling to many practices. You need public mode. Start the partner conversation early, because it sits on your critical path. DrChrono does not publish how long partner review takes or what it costs. Ask before you commit dates to customers.
• Credentials belong to a practice group. In a 2017 developer forum reply, a DrChrono engineer explained that each practice group has its own API key, so a second practice group needs its own credentials. Treat that as an older forum answer and confirm it for public apps.

To see the API page in DrChrono, a user needs the Settings staff permission. That detail comes from integration setup guides that other vendors publish for their customers, not from DrChrono, so confirm it in your test account.

How DrChrono API authentication works

DrChrono uses the OAuth 2.0 authorization code flow, the same base flow that SMART on FHIR builds on (see our guide to SMART on FHIR OAuth for clinical apps). There are three steps.

1. Send the user to DrChrono. Usually a "Connect to DrChrono" button that links to:

https://app.drchrono.com/o/authorize/?redirect_uri=REDIRECT_URI_ENCODED&response_type=code&client_id=CLIENT_ID_ENCODED&scope=SCOPES_ENCODED

2. The provider approves. DrChrono shows your app name and the scopes you asked for. On "Authorize", the user returns to your redirect URI with a code. On "Cancel", you get error=access_denied.
3. Exchange the code. POST the code, grant_type=authorization_code, your redirect URI, client ID and client secret to https://app.drchrono.com/o/token/. You get an access_token, a refresh_token and expires_in.

Two details from the docs cause trouble in practice. The authorization code "expires extremely quickly" and works only once, so exchange it on the server before you render the next page. And access tokens last 48 hours, so store the refresh token and refresh in the background with grant_type=refresh_token.

Scopes

Scopes look like BASE_SCOPE:read or BASE_SCOPE:write. The docs name user, calendar, patients, patients:summary, billing, clinical and labs. The schema adds finer ones such as messages, tasks, settings and billing:patient-payment, for 22 in total.

If you leave out the scope parameter, DrChrono asks the user for every scope. The docs advise asking only for what you need. Their own example: a birthday email app needs patients:summary:read, while an online booking app needs at least patients:summary:read patients:summary:write calendar:read calendar:write clinical:read clinical:write.

Scopes are not the whole permission check

A scope only says what your app may ask for. DrChrono also checks the permissions of the user who authorized you, which a primary user grants inside the DrChrono web app. The docs put it this way: the user must authorize the app for the scopes, "and the user must have the appropriate permissions set." So a valid token can still get a 403 when the person who connected your app lacks the right staff permission. Plan for a short permission checklist that each practice runs before go-live.

Is there a DrChrono sandbox?

DrChrono's license terms grant developers access to "a dedicated test environment of the EHR" for testing the API, and the webhook docs mention apps that are still in test mode. The public docs do not explain how to request that environment, what test data it holds or how it differs from production. Ask api@drchrono.com, or your partner contact, how you get a test account before you plan your test phase.

What the DrChrono API covers

The schema groups endpoints into Administrative, Billing, Clinical, Practice Management and Audit. In product terms:

Scheduling: availability, booking and conflicts

GET /api/availability returns open slots for a date or date range, filtered by office, doctor, exam room and visit length. To book, POST /api/appointments needs doctor, exam_room, office, patient and scheduled_time. If the time overlaps an existing appointment, DrChrono returns 409 with "Scheduled time overlaps with an existing appointment". Your booking flow should treat a 409 as "slot taken, offer another time".

Appointment status is a fixed list (for example Confirmed, Arrived, Checked In, In Room, In Session, Complete, Cancelled, No Show, Rescheduled) plus any custom statuses the practice defines. Membership plan charges create placeholder appointments each billing cycle, and they come back by default. Pass exclude_membership=true so they do not show up as real visits in your product.

Patients and duplicates

Creating a patient needs at least gender and doctor. POST /api/patients runs a duplicate check, and an allow_duplicates flag overrides it. Do not set that flag by default. Search first by name, date of birth, chart ID or email, and only create a patient when the search finds no match.

For large historical loads, /api/patients_list and /api/clinical_notes_list work as async batches. You create a request, get a UUID back, and collect the results later. The docs suggest this for "large historical record loading".

DrChrono API rate limits

The docs say: "By default, applications are limited to 500 calls per hour." The limit resets at the top of each hour, and calls over it get HTTP 429. To raise it, contact api@drchrono.com or your account representative.

500 an hour is low for a multi-practice product, and pagination makes it tighter:

• Most lists return 250 records a page.
• /api/appointments returns at most 20 a page. A day with 400 appointments takes 20 calls.
• With verbose=true, pages drop to 50.

Some ways to stay inside the budget:

• Use webhooks for changes, and poll only to catch up.
• Use since filters so each sync pulls only what changed.
• Use the async _list endpoints for backfills.
• Queue calls per app and back off on 429 until the next hour starts.
• Ask DrChrono early for the limit you need, with a call estimate per practice.

The docs do not say whether the limit counts per app overall or per app per practice. The wording ("applications are limited") suggests per app. Confirm with DrChrono if you serve many practices from one public app.

Some third-party pages describe the limit as about 100 requests per minute. DrChrono's own docs say 500 per hour. Use DrChrono's number until DrChrono tells you otherwise.

DrChrono webhooks

Webhooks belong to an API application. You set the callback URL, a secret token and the events in the app's webhook section. Supported events, as listed in the docs:

• Appointments: create, modify, delete
• Patients: create, modify; allergy, problem, medication and flag create and modify
• Clinical notes: lock, unlock
• Lab orders: create, modify, delete
• Billing: line item create, modify, delete; line item transaction delete; cash payment delete
• Tasks: create, modify (including task note changes), delete
• VACCINE_ADMINISTERED, sent when a vaccine consent form is signed

How delivery works, per the docs:

• Verification. When you create a webhook or change its URL, DrChrono sends a GET with a msg parameter. You reply 200 with JSON {"secret_token": HMAC-SHA256(msg, your secret)}.
• Headers. X-drchrono-event (the event name or PING), X-drchrono-signature and X-drchrono-delivery (a delivery ID). The body has receiver and object, where object uses the same format as the REST API.
• Success. Only a 2xx response counts. A 302 counts as a failure.
• Retries. Three retries, at 1, 3 and 7 hours after the event. After that, you redeliver by hand from the deliveries page.

Read the signature header with care. The docs describe X-drchrono-signature as the "Secret token associated with this webhook" and suggest checking incoming requests against your token. They do not describe a signature computed over the request body. If your security review needs proof that the body was not changed, ask DrChrono how to get it. Either way, treat each webhook as a hint, and fetch the current record from the API before you act on it.

If your endpoint is down for a short while, the first retry comes an hour later, and after 7 hours a missed event stays missed until someone redelivers it. Run a scheduled since poll as a safety net.

What can you write back to DrChrono?

Going by the methods in the schema, most record types are writable, with some exceptions:

• Writable: appointments, patients, problems, medications, allergies, documents, lab orders and results, billing line items, patient payments, tasks, messages, consent forms, clinical note field values, and telehealth appointments.
• Read-only: clinical notes as a whole, insurances, procedures, doctors, users, care plans, implantable devices and fee schedules.

For AI scribes and documentation tools, the main limit is that you cannot POST a finished clinical note. You write values into the fields of the note template (/api/clinical_note_field_values), tied to an appointment. Template fields can be marked required, which means "a note should not be locked unless a value is provided for this field". Map your output to the practice's templates before you promise "notes land in the chart". Our post on connecting AI agents to an EHR covers the wider design choices.

You can also upload a PDF or other file to the chart with POST /api/documents when structured fields are not needed.

Embedding inside DrChrono with an iframe

DrChrono lets an approved app appear inside the patient chart or the clinical note page as an iframe. You set the iframe URL and height in API management, and DrChrono reviews the app "to ensure that it is functional and secure" before approving it. You register each doctor with POST /api/iframe_integration.

When the iframe loads, DrChrono adds doctor_id, patient_id, practice_id, iat and a jwt to the URL. The JWT is signed with HMAC SHA-256 using your client secret. The docs say to validate it and use only the values inside it. Do not trust the plain query parameters.

FHIR and DrChrono: what exists and who it is for

DrChrono is ONC certified (DrChrono EHR 11.0, certified 05/31/2022), and its criteria include 170.315(g)(10), the standardized FHIR API. Its certification page lists "Dynamic Health IT, Inc ConnectEHR + BulkFHIR (version FHIR4-B)" as the software behind it.

DrChrono's support articles describe how it works:

• The practice turns it on under Account > API > ConnectEHR Setup for FHIR. The articles frame this around the MIPS Promoting Interoperability measure.
• When a clinician signs and locks a note, DrChrono sends a C-CDA to ConnectEHR, and the patient gets an email with an activation key.
• The patient activates a FHIR R4 account and can connect third-party apps, including from the OnPatient portal.
• DrChrono says it provides this to practices "at no additional charge".

For a product team, this means DrChrono's FHIR API is a patient-access channel built from documents. Data shows up after a note is locked, and it reaches patients through ConnectEHR so they can read their records. If your product needs to book visits, write to the chart or react to events, use the REST API. That is a different setup from EHRs where FHIR is the main developer route, such as Epic and eClinicalWorks. If you build a patient-facing app that reads records, the FHIR route may fit. Ask DrChrono or Dynamic Health IT for the practice's FHIR endpoint and app registration steps, because DrChrono's support pages do not publish them.

Fees for the certified API are a separate question. DrChrono's certification page says customers "may incur an annual one-time setup/maintenance fee" and third-party developers "may incur a one-time setup fee plus monthly, recurring fees based on transaction volume". The FHIR FAQ says the service costs practices nothing extra. The two statements may describe different setups. Ask before you budget.

Bulk data and EHI export

For a one-time move of a whole practice, such as a migration, DrChrono has an EHI Export feature. Its FAQ says a full practice export can take up to 14 business days and arrives as a ZIP of CSV files, in sets of 50 patients. Large practices have seen exports over 200 GB, and DrChrono's ETL team can ship one on a hard drive for an extra cost. This is a practice-run export, separate from the API, and it suits migrations better than ongoing sync.

How much does the DrChrono API cost?

DrChrono does not publish an API price list. Here is what its public pages say:

• The API license terms say DrChrono "may charge a fee for Developer's use of the Services and/or for support", payable within 30 days of invoice. For details, contact api@drchrono.com.
• Fees may be waived or treated differently for patient access use, at DrChrono's discretion.
• The docs sort endpoints into "Level 1" and "Level 2" API calls. For example, patients and appointments are Level 1, and clinical notes, labs, insurances and line items are Level 2. The docs do not say what the levels mean for price or limits. Ask.
• The certification page describes setup and monthly volume-based fees for third-party developers using the certified API.

Budget for DrChrono's fees, your own build, and the time partner approval takes. Get the first two in writing before you price your product for DrChrono customers.

Agreements, BAAs and terms worth reading

The API license terms apply as soon as you use the API. Points a product team should read with its lawyer:

• Business associates. The terms say "Neither Party is the business associate of the other." If you handle PHI, you need your own business associate agreement with each practice, along with their written authorization.
• No scraping. The terms ban screen scraping and data scraping of the service.
• No card data. You may not send or store data covered by PCI standards through the service.
• Limits can change. DrChrono may limit API calls or change the API without notice.
• Marketing. You may list DrChrono as a supported EHR. Other public statements need written approval.
• Ending the agreement. Either side can end it with 90 days' notice. Existing customers then get a 90-day wind-down.

Versions and deprecation

The version map lists v2 (from 08/2015), v3 (from 06/2016) and v4 (from 09/2018). DrChrono's stability policy says changes within a version only add endpoints, fields or optional query parameters. A deprecated version stays supported for one year, and after that it can be switched off at any time. Build on v4. If you inherit v2 or v3 code, plan the move.

Common DrChrono API errors and fixes

DrChrono API integration checklist

1. Decide whether you need private mode (one practice) or public mode (many practices). If public, contact DrChrono partnerships now.
2. Ask DrChrono in writing about fees, the Level 1 and Level 2 pricing, your rate limit and test environment access.
3. List the scopes you need, and nothing more.
4. Write a permission checklist for each practice's admin.
5. Store refresh tokens securely and refresh before the 48 hours run out.
6. Set up webhooks for the events you need, and add a since poll to catch anything missed.
7. Budget calls per practice against 500 an hour, and remember the 20-per-page cap on appointments.
8. Handle 409 on booking and the patient duplicate check.
9. For notes, map your output to template fields.
10. Sign a BAA with each practice before you touch PHI.
11. Test in the DrChrono test environment, and keep test results separate from production evidence.

If you would like help with any of these steps, our team builds DrChrono integrations for product companies. Start with the DrChrono integration service page, which covers scope, the access review and how we work.

Sources

All read on 28 October 2026.

1. DrChrono API reference: https://app.drchrono.com/api-docs/ (rendered from https://app.drchrono.com/openapi-schema, "v4 - Hunt Valley")
2. DrChrono API License Terms and Conditions (part of the API reference above)
3. Why use DrChrono's API? (last modified 12/12/2025): https://support.drchrono.com/home/201883240-why-use-drchrono-s-api
4. Private vs Public API application (last modified 10/02/2024): https://support.drchrono.com/home/private-vs-public-api-application
5. Contacting DrChrono Partner Support (last modified 01/13/2025): https://support.drchrono.com/home/contact-drchrono-partner-support
6. Is DrChrono ONC Certified Health IT? (last modified 01/15/2025): https://support.drchrono.com/home/360028249532-is-drchrono-cehrt-certified
7. DrChrono ONC certification information: https://www.drchrono.com/meaningful-use-ehr/
8. Overview of ConnectEHR (last modified 02/06/2025): https://support.drchrono.com/help/19009575165979
9. FHIR API FAQ (last modified 02/06/2025): https://support.drchrono.com/help/19311277515291
10. Set Up ConnectEHR for FHIR (last modified 11/21/2025): https://support.drchrono.com/home/set-up-connectehr-for-fhir
11. What to Expect with FHIR APIs (last modified 02/06/2025): https://support.drchrono.com/home/19098823939739-what-to-expect-with-fhir-apis
12. Connect Patient Dynamic FHIR API to OnPatient (last modified 06/11/2025): https://support.drchrono.com/home/how-to-connect-patient-dynamic-fhir-api-to-onpatient
13. EHI Export: Overview and EHI Export FAQ (last modified 09/23/2025): https://support.drchrono.com/home/20260096536987-ehi-export-overview and https://support.drchrono.com/help/21368739016859
14. DrChrono API developer forum thread, 2017: https://groups.google.com/g/drchrono-api/c/9qFr-0Hji70
15. DrChrono partner form: https://partners.drchrono.com/become-a-partner

Planning an integration like this one? Our healthcare interoperability team builds and supports vendor API, FHIR and HL7 integrations for product companies. Talk to our team to scope yours.