eClinicalWorks Scheduling API: How to Get a Provider's Day List (2026)

Updated October 2026

eClinicalWorks has no appointment API on its FHIR server: none of the calls in eCW's API list reads or writes Appointment, Schedule or Slot. To get a provider's full day list, including patients who are booked but not checked in, you need an HL7 SIU scheduling feed from the practice, the contracted healow Scheduling API for booking flows, or a third-party route.

This guide is for teams building on eClinicalWorks (eCW): AI scribes and agents that prepare for each visit, patient engagement tools, voice and booking agents, and analytics products. It covers why the FHIR route misses patients, what each scheduling route returns, the exact calls and messages involved, and the checks to run before go-live. If you want the work done for you, our eClinicalWorks integration services team builds these feeds end to end.

Does eClinicalWorks have an appointment API?

Not on its FHIR server. eCW's developer documentation shows 89 API calls for its certified FHIR R4 interface, and none of them is Appointment, Schedule or Slot, whether free or under contract. The page data also holds one hidden entry, an "Encounter (paid API)" read switched off by a feature flag, with no published price. Scheduling lives in a separate product, the healow Scheduling API, which runs on the older FHIR DSTU2 standard and needs its own registration and contract.

We checked this three ways in October 2026: the resource list in eCW's documentation at fhir.eclinicalworks.com, the live capability statement (/metadata) on both eCW FHIR hosts for two public test practices, and the healow developer portal. The capability statement reports "eCW FHIR Facade 1.6", FHIR 4.0.1 and 38 resources, with no scheduling resource among them. The same answer holds for patient apps, provider apps and backend (system) apps.

Why your eCW day list misses patients who have not checked in

Most teams build the day list from Encounter, because it is the only visit-shaped resource eCW's FHIR API offers. An Encounter is the visit itself, so a patient who is booked for 3 pm but has not arrived may not appear yet, and the list looks short until the afternoon fills in.

The Encounter search on eCW accepts six parameters: _id, date, location, page, patient and practitioner. There is no status parameter, so you cannot ask for planned or booked visits, and you get whatever eCW chooses to expose. Paging uses page, not the _count and next link pattern many FHIR servers use, so code written for Epic or Oracle Health can silently read only the first page.

# Free check: one provider, one day, every page
GET https://fhir4.eclinicalworks.com/fhir/r4/{practice_code}/Encounter?practitioner={practitioner_id}&date=2026-10-19
GET https://fhir4.eclinicalworks.com/fhir/r4/{practice_code}/Encounter?practitioner={practitioner_id}&date=2026-10-19&page=2
Authorization: Bearer {access_token}
Accept: application/fhir+json

Run that search for one provider and one day, page through every result, and compare it with the same provider's column on the eCW Resource Schedule. If every booked patient appears, your problem was paging or filtering, and you can stay on FHIR. If booked patients are missing, eCW's Encounter feed does not cover them in that practice, and you need one of the routes below. The behavior can differ by eCW version and practice setup, so test in the practice you will go live in, not only in the sandbox.

One more resource is worth testing. eCW describes its CarePlan read as "Upcoming appointments, Pending orders". We have not tested what it returns in a live practice, so treat it as a lead to check, not as a schedule feed.

Polling also has a ceiling. eCW allows 250 calls per minute per practice base URL, and that budget includes the token and authorize calls. A product that refreshes many providers every few minutes runs into it fast.

How eClinicalWorks scheduling works inside the practice

Bookings in eCW land on the Resource Schedule, a grid of provider columns and time slots built from templates. Each practice defines its own visit types (new patient, follow-up, procedure, telehealth), and each visit type carries a duration and rules about which provider and location can take it. Templates must be published before their slots can be booked.

This matters even if you only read the schedule. Your day list should carry the visit type and duration that eCW holds, not a guess, because an AI agent preparing a 40-minute new-patient visit needs different context from a 10-minute follow-up. If you also book, every write has to respect the same templates and visit-type rules, or the front desk ends up cancelling and rebooking by hand.

healow Scheduling API: endpoints, limits and terms

The healow Scheduling API is eCW's official scheduling interface for outside apps. It is built for booking flows: show open slots, book a visit, cancel or change it. It runs on FHIR DSTU2 under https://connect4.healow.com/apps/api/v1/fhir/{practice_code}/dstu2/, and every call carries a bearer token issued for the practice.

None of the six calls returns every appointment for one provider on one date with patient details. That makes the healow Scheduling API the right tool for a patient booking app or a voice agent that books, and the wrong tool for a clinician-facing day list.

How to register a healow Scheduling App

Sign in to the healow developer portal at connect4.healow.com and choose Register Scheduling App on the dashboard, next to Register Patient App and Register RPM Device. The form asks for the app name, a logo (PNG or JPEG, up to 20 KB), a short description, and whether the app will query Patient and Encounter resources. You then accept the Scheduling API Terms of Service.

What the Scheduling API terms say

Read the terms before you build, because four of them shape the architecture. We read them on the registration form in October 2026:

• Fees. Access is billed monthly in US dollars "according to the terms provided in Exhibit B". Exhibit B was blank on the page, so ask eCW for the price before you commit.
• Business associate agreement. A HIPAA business associate agreement is attached as Exhibit A.
• No caching or storing. The terms bar keeping "a cache or store" of data accessed through the APIs. An app that keeps its own copy of the schedule needs a different source for that copy.
• No service-bureau use. Access is only through your own application and site; sub-licensing or running the API for another company is not allowed. Each vendor registers its own app.

The terms also say eCW approves apps automatically when they use only the common scheduling data set and follow the federal certification criteria, and that eCW may limit daily query volume.

HL7 SIU feed: the complete day list in real time

An HL7 SIU feed is the most reliable way to get a provider's full day list from eClinicalWorks. eCW says it follows standard HL7 SIU messaging to keep appointments in sync with other systems, and lists S12 (new booking), S13 (rescheduled) and S15 (cancelled) among the messages it sends. Some integration guides list S14 (modified) in place of S13; confirm the exact event list for your practice when you order the interface.

Because eCW sends the message when the front desk books the visit, the patient is in your data hours or days before check-in. The practice orders the interface from eCW, typically under a statement of work, and the feed usually lands in an interface engine such as Mirth Connect, which acknowledges each message and writes it to your database.

A synthetic S12 message looks like this (all values made up):

MSH|^~\&|ECW|CLINIC01|MIRTH|APPDB|20261019083000||SIU^S12|MSG0001|P|2.3
SCH|APT000123|APT000123|||||FOLLOWUP^Follow-up visit|||15|MIN|^^15^20261019150000^20261019151500|||||||||||||Booked
PID|1||PAT0042^^^ECW||TEST^PATIENT||19800101|F
AIP|1||PRV001^SAMPLE^PROVIDER|||20261019150000|||15|MIN
AIL|1||MAIN^^^CLINIC01

Field positions vary between eCW versions and practices, so map from real messages captured in the practice, not from a template. Our Mirth Connect eClinicalWorks guide covers segment-by-segment mapping, ACK handling and replay.

Design a live appointment table

Store one row per appointment, keyed on the eCW appointment id, and let each SIU event update that row. Your app then answers "Dr X's day" with a simple query instead of a chain of API calls.

CREATE TABLE ecw_appointment (
  practice_code   text        NOT NULL,
  appointment_id  text        NOT NULL,   -- eCW id from SCH
  provider_id     text        NOT NULL,   -- from AIP
  patient_id      text        NOT NULL,   -- from PID
  visit_type      text,
  starts_at       timestamptz NOT NULL,
  duration_min    int,
  location        text,                   -- from AIL
  status          text        NOT NULL,   -- booked, rescheduled, cancelled
  last_event      text        NOT NULL,   -- S12, S13, S15
  updated_at      timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (practice_code, appointment_id)
);

-- The day list, including patients not yet checked in
SELECT starts_at, patient_id, visit_type, status
FROM ecw_appointment
WHERE practice_code = 'CLINIC01'
  AND provider_id = 'PRV001'
  AND starts_at::date = DATE '2026-10-19'
  AND status <> 'cancelled'
ORDER BY starts_at;

Keep cancelled rows instead of deleting them, so you can tell a cancellation from a lost message. Alert when a practice goes quiet during clinic hours, because a silent feed looks exactly like an empty schedule.

Other routes: data services and UI automation

Two other routes exist, and both trade control for speed. Scheduling data services such as NexHealth expose eCW appointments through their own API; NexHealth's changelog notes eCW support for double booking through an appointments_per_slot setting on its v20240412 API version. Confirm with the vendor that your practices' eCW deployments are supported, and budget for a second vendor and a second business associate agreement.

UI automation (sometimes called RPA or browser automation) drives the eCW screens with a staff login, so it can read anything a user can see. It is quick to start and can work where no interface exists. It also breaks when screens change, depends on a user account and its login, and may conflict with eCW's terms or the practice's policies, so get the practice's written approval before you use it.

Which route fits your product

The right route depends on what the product does with the schedule. A backend app that needs every booking needs a feed; an app that books on behalf of patients needs the healow Scheduling API.

Checks before you go live

Prove the day list in a real practice before anyone relies on it. Run these four checks with the practice's front desk:

1. Book a test visit. It appears on the Resource Schedule and in your data with the right provider, visit type, duration and location.
2. Reschedule it. The same record moves; no duplicate appears.
3. Cancel it. The slot reopens in eCW and your record shows cancelled.
4. Compare a full day. Your list for one provider matches the eCW schedule screen, including patients who have not checked in.

If your product also writes back (tasks, notes or bookings), confirm each write lands in the right eCW queue or chart, and plan for the eCW contract those writes need. Our eClinicalWorks API guide covers registration, authentication, write access and rate limits in detail, and our FHIR Encounter guide explains Encounter statuses across EHRs.

How we can help

We build eClinicalWorks integrations for health-tech products, from FHIR reads to SIU feeds. Our team has built more than 350 interfaces on Mirth Connect, and our eCW healow SMART on FHIR walkthrough shows a live sandbox launch. For AI products that need the day's patient list, see our healthcare AI agent work.

If your eCW day list is missing patients, book a 30-minute scoping call. We will run the Encounter check with you, tell you which route fits, and give you a fixed-price plan for the first practice. Read more on our eClinicalWorks integration page.