ModMed API Documentation: EMA REST and FHIR Endpoints

Key facts

The ModMed API has two APIs with different limits: the EMA Proprietary API reads and writes EMA and ModMed PM data with no deletes, and the Certified FHIR API reads EMA and gGastro data with bulk export. Sandboxes and resource grants each take up to two weeks, no fees are published, and there are no webhooks.

• The EMA Proprietary API has 43 read and search operations and 20 write operations (13 create, 7 update). It has no delete. Source: OpenAPI definitions on the ModMed API portal, spec 3.4.3_FINAL.
• The Certified FHIR API covers EMA and gGastro, serves 31 resource types, and is read, search and bulk export only. Source: ModMed API portal, getting-started page.
• ONC's CHPL lists both products on US Core 6.1.0, USCDI v3, SMART App Launch 2.0.0 and Bulk Data 1.0.0. Source: CHPL listings 11032 (EMA v7) and 11054 (gGastro v6).
• Sandboxes for the proprietary API "can take up to two weeks to provision", and resource provisioning can take up to two more weeks. Source: ModMed API portal.
• The Certified FHIR API "does not have a public sandbox". Authorization and API calls run against the production environment. Source: ModMed API portal, authentication page.
• No webhooks or FHIR Subscription appear anywhere in the 174 portal pages. Change detection is polling. Source: our full read of the portal, November 13, 2026.

What can you build with the ModMed API?

With the ModMed API you can build patient intake, online booking, insurance capture, referral intake, AI scribe text, prior authorization evidence, charge capture, an analytics warehouse, and appointment reminders. The first five and charge capture write through the EMA Proprietary API. The rest read, either from the proprietary API or the certified FHIR API. Each one has a limit you should design around from day one.

Every use case below runs only on capabilities ModMed documents. Business value is the typical goal for that use case, not a measured result. Build times are typical build estimates for an experienced team once access is granted. ModMed's own access waits are listed separately.

1. Digital intake and registration

2. Online booking

3. Insurance capture

4. Referral intake

5. AI scribe and transcription

6. Prior authorization evidence

7. Charge capture

8. Analytics warehouse

9. Reminders and outreach

All nine use cases compared

*Typical build estimate for an experienced team once access is granted; separate from ModMed's access waits. Separately, plan for ModMed's access waits: up to two weeks for a sandbox and up to two weeks for the resource grant on the proprietary API.

What we left off this list: anything that needs a real-time event, a delete, a write to gGastro, prescriptions, vitals or immunization writes, payment posting, claims or eligibility. None of these are in the API reference. Care-gap registry reporting can run on the bulk export, but the submission to a registry happens outside ModMed.

Want a second opinion on which of these fits your product? Talk to our integration team.

Which ModMed APIs exist, and when do you use each one?

ModMed publishes two APIs on portal.api.modmed.com. The EMA Proprietary API reads and writes EMA and ModMed PM data. The Certified FHIR API, built for ONC (g)(10), reads EMA and gGastro data and supports bulk export but never writes. ModMed also offers HL7 interfaces, arranged through synapSYS.

The proprietary API is FHIR R4 in style but is ModMed's own. ModMed calls it a "Proprietary FHIR API". Paths look like /firm/{prefix}/ema/fhir/v2/Patient, and every practice has its own URL prefix. It does not cover gGastro: "currently this is not supported for MMGI practices."

The certified API is standard FHIR R4 with SMART on FHIR, so the usual FHIR integration tooling applies. ModMed states it plainly: "Currently this API supports READ and SEARCH only (no WRITE capabilities) + Bulk FHIR."

HL7 interfaces exist for EMA, ModMed PM and gGastro, per the getting-started guide. Specs are not on the portal. You request them from synapsys@modmed.com. For interface engine work, see our HL7 integration services.

How do you get ModMed API access, from registration to production?

ModMed API access has two tracks. For the proprietary API, apply as a partner, wait up to two weeks for a sandbox, request each resource and operation (up to two more weeks), pass a technical review, then get a production key. Each practice then grants access with its own credentials. For the certified API, register your app yourself and ModMed reviews new apps daily.

EMA Proprietary API, step by step

1. Apply. Use the become a partner form or "Request Developer Tools" on the synapSYS developer page.
2. Get a sandbox. ModMed "typically provide[s] 2 sandbox environments". The generic sandbox has sample patients, practitioners, locations and encounters. A practice training sandbox, often called the ModMed practice sandbox, has more realistic data. A sandbox gives access to all resources by default.
3. Request resources. Send your vendor name, app name, a description and each resource with its operations, for example "Patient READ/SEARCH, ChargeItem CREATE/READ/SEARCH".
4. Pass the final review. This is an end-to-end demo, a proof of concept in the sandbox, and a technical talk about resources and call frequency. You must show you can GET what you need and POST or PUT what you plan to write.
5. Get a production key and go-live instructions.
6. Connect each practice. Each practice creates practice-specific credentials for you.

Usage falls under ModMed's Proprietary API Terms of Use. No fees are published in any ModMed document we read.

Certified FHIR API, step by step

1. Register in the FHIR vendor dashboard (self service).
2. Pick the app type, public or confidential client, PKCE (none or S256), FHIR v4.0.1, and enter the launch, redirect, logo, policy and terms URLs.
3. The app starts Disabled. "MMI will review new apps daily and Enable apps that are configured correctly."
4. Bulk apps are enabled once a practice admin adds your ClientId under "Manage Bulk FHIR".
5. The FHIR base listed in ModMed's authentication docs is https://fhirmp.mmi.prod.fhir.ema-api.com/fhir/r4, a production host; ModMed says there is no public sandbox. Per-practice endpoints are listed at mm-fhir-endpoint-display.prod.fhir.ema-api.com.

Minimum software is EMA 7.0 or higher, with TLS 1.2 or later.

Which endpoints does the EMA Proprietary API have?

The EMA Proprietary API has 24 resources across patients, scheduling, visits, insurance, documents, clipboard data, billing, orders, results, tasks and transcription. 13 accept a create and 7 accept an update. None accept a delete or a patch. Every call needs a Bearer token and an x-api-key header.

Base URLs: generic sandbox https://stage.ema-api.com/ema-dev/firm/, practice training sandbox https://stage.ema-api.com/ema-training/firm/, production https://mmapi.ema-api.com/ema-prod/firm/.

Two headers change behavior. Content-flag: Pagination_optimization_disabled returns a true total, at a speed cost. Content-flag: Referral adds referral data to Patient and Appointment.

Which resources does the ModMed Certified FHIR API serve?

The ModMed Certified FHIR API serves 31 resource types, all read and search, plus bulk $export at system, Patient and Group level. CHPL lists US Core 6.1.0 and USCDI v3. ModMed's July 2024 PDF still says US Core 4.0.0, so trust the portal, the live CapabilityStatement and CHPL over the PDF.

For how DocumentReference notes compare across EHRs, see our DocumentReference guide. The PDF also lacks Coverage, MedicationDispense, Questionnaire, QuestionnaireResponse, RelatedPerson, ServiceRequest and Specimen. All seven are on the live server.

What can you write to ModMed, and what can't you?

You write to ModMed only through the EMA Proprietary API. You can create and update patients, appointments, coverage, clipboard items and general tasks, and create documents, charges, procedures, referring providers and transcription. You cannot delete anything, update a procedure, create a recall, write to gGastro, or write through the certified API.

• No deletes. No DELETE or PATCH appears on any proprietary resource.
• Procedures are create only. "There is no Update operation for Procedure." Status must be completed, and only past surgical or ocular surgical history is accepted.
• No recall creation. "PM Recalls cannot be created or updated through this endpoint." General EMA tasks can be created. On update, authoredOn, description, location, for and status are fixed.
• Clipboard items wait for staff. "Conditions added or updated through the API will need to be reconciled by the Practice." The same applies to medications and allergies. Show these items as "sent for review" in your UI.
• Charges and coverage need ModMed PM. On EMA-only practices those writes are not available.
• Certified FHIR API is read only. No create, update or delete of clinical data.

How does ModMed API authentication work?

ModMed API authentication differs by API. The certified API uses SMART App Launch for patient and provider apps, and SMART backend services with a signed JWT (private_key_jwt, ES384 confirmed working) for bulk. The proprietary API uses OAuth client credentials plus an x-api-key. All token endpoints sit on ModMed's Keycloak at sso.ema.md.

SMART launch. Authorize at https://sso.ema.md/auth/realms/fhir/protocol/openid-connect/auth, token at the matching /token URL. Client auth is client_secret_post, and PKCE S256 is recommended. Scopes follow patient/X.rs, user/X.rs and system/X.rs, plus openid, fhirUser, launch, launch/patient, online_access and offline_access. An online_access refresh token ends with the user's EMA session. An offline_access one does not. New apps start with a standalone launch. A provider app's EHR launch link is placed in EMA after that.

Backend services. Register a JWKS, sign the assertion with ES384, keep its expiry around five minutes, and send scope. Do not send client_id in the body. The sample response shows expires_in: 1800.

Proprietary API. The token endpoint is https://sso.ema.md/auth/realms/ema-fhir/protocol/openid-connect/token in production. You get an RS256 JWT with ACL scopes and no refresh token (sample expires_in: 900). The older password grant is being sunset.

Discovery file caveat. The live .well-known/smart-configuration lists only client_secret_post and points its token endpoint at the fhirmp host. The docs say bulk uses private_key_jwt at sso.ema.md. Build to the docs and read the discovery file per practice.

What are the known issues and gotchas in the ModMed API?

The known ModMed API gotchas are these. The paging total is misleading, slot search stops at five days, unknown Condition codes file silently to the Problem List, bulk export rejects most standard parameters and skips unscoped types without an error, the rate limit is stated two ways, there are no webhooks, and the certified API has no sandbox.

1. Paging total. By default total is the count on the current page, not the full result. Loop until a page returns total of 0.
2. Five-day slots. "Slot Search is currently limited to 5 day increments." Only the eq date prefix works. A two-week calendar is three calls.
3. Condition section fallback. Conditions default to the Problem List. You pick another section through the condition-type identifier on create. An unknown code on create files silently to Problem List. The same code on search returns an error.
4. Token without x-api-key. It "still returns a 200 with a valid-looking token, but every downstream FHIR call then fails." Log the key on the token call in your health check.
5. Rate limit stated twice. The rate-limiting guide says 1,250 calls a minute per key. The 429 text in the OpenAPI definitions says "1000 calls/min default". Budget for 1,000.
6. Bulk export quirks. See the next section.
7. No webhooks. See change detection below.
8. No certified sandbox. Certified FHIR calls run against production, starting with the fhirmp base host and then each practice endpoint.

How does ModMed bulk $export differ from the Bulk Data spec?

ModMed bulk $export supports only three parameters, _outputFormat, _since and _type, sent as query parameters on the POST. The status call returns a Status: In Progress header (not X-Progress) with a fixed Retry-After: 120. Output is ndjson, at most 1,000 resources per file. Types your token is not scoped for are skipped with only a note in the error file.

• Kick-off: POST /$export, POST /Patient/$export, or /Group/{id}/$export. ModMed creates groups on request.
• Sending _until, _elements, patient, includeAssociatedData, _typeFilter, organizeOutputBy or allowPartialManifests fails the request.
• Status: GET /fhir-services/$export-status/{id}. 202 while running. 200 with the manifest as application/json.
• Cancel: DELETE the same URL. A later GET returns 404.
• _outputFormat=csv returns a 400 with "Invalid Tenant".
• System export includes Location and PractitionerRole. Patient export includes Questionnaire but not those two.

How do you detect changes without ModMed webhooks?

Without ModMed webhooks, you detect changes by polling. Search with _lastUpdated on the proprietary resources that support it, walk every page, upsert by ModMed id and save a checkpoint. For the certified API, run a bulk export with _since. This polling design is our recommendation. ModMed documents the parameters, not the pattern.

_lastUpdated is a search parameter on Patient, Practitioner, Organization, Location, Appointment, Encounter, Coverage, InsurancePlan, Condition, ServiceRequest, DiagnosticReport and Task. Set the new checkpoint to the time the run started, so records changed during the run are picked up next time. Size your interval against the rate limit, since every practice has its own volume.

How do EMA and gGastro differ for API work?

EMA and gGastro share the same Certified FHIR API and ONC standards, on separate endpoint hosts, so reads and bulk export work the same way for both. Only EMA has the proprietary read and write API. For gGastro, ModMed documents no API write path, so write-back means HL7 through synapSYS, which is available for both products.

CHPL lists EMA v7 (certified November 29, 2022) and gGastro v6 (certified December 7, 2022). Both are Active and both carry (g)(7), (g)(9) and (g)(10). gGastro's endpoint list is at public-api.gastro.prod.fhir.ema-api.com, separate from EMA's public-api.mmi.prod.fhir.ema-api.com. The PDF gives EMA 7.0 as the minimum version and leaves a placeholder for gGastro.

What does a realistic ModMed integration plan look like?

A realistic ModMed integration plan starts with the partner application, a sandbox wait of up to two weeks and a resource grant of up to two more weeks, then build, technical review and per-practice rollout. ModMed publishes only those two waits; every other duration below is a typical build estimate for an experienced team. Build reads while you wait.

For a certified, read-only app, phases 2, 4 and 6 drop out. You need the daily app review and a practice that connects.

What is not possible or not documented in the ModMed API?

The ModMed API does not offer webhooks or any event push, DELETE or PATCH, writes through the Certified FHIR API, or proprietary API access for gGastro. It also omits prescriptions, immunizations and vitals on the proprietary API, and payment posting, claims and eligibility. The full list, from our read of the portal:

• Webhooks, FHIR Subscription or any event push.
• DELETE or PATCH on any resource.
• Writes through the Certified FHIR API.
• Any proprietary API access for gGastro.
• Prescriptions (MedicationRequest), immunizations, vitals or Observation on the proprietary API.
• Payment posting, claims, eligibility, staff user management and schedule templates.
• Appointments, balances and inbound charges on EMA-only practices.
• Visit notes while the encounter is still in progress.
• Slot search over more than five days in one call.
• A public sandbox for the certified API.
• A stated rate limit for the certified API, or stated access token lifetimes for interactive apps.
• Published fees for either API.

Planning a ModMed integration?

If you are deciding between the proprietary API and the certified API, or need to scope write-back for EMA and ModMed PM, see our ModMed integration services, or talk to our integration team. For payer-side prior auth, see electronic prior authorization integration.

Sources

All read on November 13, 2026.

• ModMed API portal: Getting Started
• ModMed API portal: EMA Proprietary API getting started
• ModMed API portal: Development Basics
• ModMed API portal: EMA Proprietary API authentication
• ModMed API portal: Certified API authentication
• ModMed API portal: Rate Limiting
• ModMed API portal: Count and Pagination
• ModMed API portal: Become a Certified FHIR API vendor
• ModMed published FHIR endpoints
• ModMed: Become a partner
• ModMed synapSYS developers
• ModMed Proprietary API terms of use

For pharmacy-side prior authorization, see our guides to CoverMyMeds API integration and DataScan WinPharm integration.