How to Get Your App Into Epic (2026): The Real Path, Costs, and the Gate Nobody Warns You About

You can spin up an Epic sandbox this afternoon, get an OAuth token, and pull a synthetic patient record before lunch. It feels easy. Then you try to go live at a real hospital, and you hit a wall that no amount of code can climb.

Two things surprise almost every team that sets out to integrate with Epic, and both are true in 2026:

• "App Orchard" no longer exists. The program everyone still Googles was retired. The path now runs through Showroom, Connection Hub, and Vendor Services, and half the guides online haven't caught up.
• You cannot self-serve your way to production. Your app stays inert until a real Epic health-system customer switches it on inside their environment. No sponsor, no go-live.

This guide is the honest version: the current program map, the real steps, what it actually costs, how long it really takes, and the gate nobody warns you about, with the words of developers who have been through it.

What "getting into Epic" actually means

"Integrate with Epic" is a direction, not a spec. In practice, it means one of a few very different projects, and conflating them is how timelines blow up.

• A read-only app that pulls clinical data (labs, meds, problems, vitals) through Epic's standardized FHIR APIs.
• A read-and-write app that also sends data back, such as notes or device observations. Write access is far more gated.
• An embedded app that launches inside the clinician's chart, with patient context passed automatically. The deepest and hardest path.
• A bulk or batch integration, server-to-server, for analytics or population data.

Each one has a different access model, a different cost, and a different way of failing. Before anything else, decide which one you are actually building.

The program maze, decoded (App Orchard is gone)

Here is the single most useful correction for anyone researching this. If a hospital tells you to "get listed in App Orchard," that program does not exist anymore.

The lineage: App Orchard launched around 2017 (and charged developers a revenue share that drew years of complaints). It was renamed App Market in 2021, then shut down in December 2022. Epic then split the old single program into two separate things:

• Showroom - the customer-facing marketplace, with three tiers.
• Vendor Services - the paid developer program for deeper, proprietary integration.

The three Showroom tiers, from open to exclusive:

• Connection Hub - a self-attested listing that says "we connect to Epic." It is open to any vendor with at least one live Epic customer connection, costs roughly $500 per year, and is explicitly not an Epic endorsement.
• Toolbox - for products in categories where Epic publishes a recommended integration "Blueprint." Requires Vendor Services membership.
• Workshop - a small set of vendors co-developing new APIs with Epic, usually invite-only.

Vendor Services itself is a paid membership (reported in the $1,700 to $1,900 per year range; Epic does not publish the figure) that unlocks proprietary APIs, an expanded sandbox, and support. Listing reduces sales friction, but it does not remove the production gate we cover below.

open.epic vs Epic on FHIR: the two free front doors

Two Epic sites do the heavy lifting, and both are free:

• open.epic.com - the broad developer hub and home of standards-based interfaces, the API Subscription Agreement, and the going-live documentation.
• fhir.epic.com ("Epic on FHIR") - the FHIR-specific portal where you register your app, get client IDs, and use the sandbox with SMART on FHIR and CDS Hooks.

The two have converged and cross-linked heavily; treat the distinction as functional, not a hard wall. You will use both.

The real path: six steps from sandbox to production

Here is the actual sequence. Steps 1 to 3 are entirely in your control. Steps 4 to 6 are not, and that is the whole story.

1. Register your app on Epic on FHIR. The system generates a production and a non-production client ID automatically, and you declare your FHIR scopes here.
2. Build and test in the sandbox against synthetic data (R4 is current; DSTU2 is legacy). Changes can take up to an hour to sync.
3. Mark the app "ready for production." Important gotcha: once you do, you cannot edit that app record. To change it, you register a new one.
4. A health-system customer signs the open.epic API Subscription Agreement. This is org-level and one-time per organization.
5. Someone at that customer downloads your client by its ID. Only a person with the "Able to Purchase Apps" security point can do it, and the record syncs into their Epic environment within about twelve hours.
6. Per-site security review and go-live. Expect a vendor security questionnaire, HIPAA documentation, a SOC 2 attestation, a penetration-test report, and a signed Business Associate Agreement.

The gate nobody warns you about

Re-read steps 4 and 5. Your production client ID does nothing until a customer's Epic administrator downloads it into their system. Epic's own developer documentation is blunt about it: the associated client ID must be active in the customer's Epic system for the integration to work.

That creates a chicken-and-egg problem every founder eventually meets. You need a sponsoring health system to go live, but health systems are reluctant to be the first to enable an app they cannot yet see running in production. One founder described it on HIStalk after going live:

"Without access to Hyperspace, it is difficult to test the product... prospects want to see a demo of [our app] working with Epic. But without access to an Epic instance, we are unable to do so."

- Chinmay Singh, CEO of SimplifiMed (HIStalk, 2018)

You see the same wall in the developer forums. A team that had happily pulled tokens in the sandbox hit invalid_client the moment they tried production. The answer, from another developer on the official SMART-on-FHIR list, was simply that "the client IDs need to be downloaded into the health system's environment," with additional in-Epic setup required before a token will be issued. The sandbox never tells you that.

The practical takeaway: line up your first sponsoring customer early, and treat that relationship as part of the build, not a step that comes after it. The federated reality also means each additional hospital re-approves and re-provisions you. There is no "integrate once, sell everywhere" with Epic.

Which authentication flow do you need

Epic standardizes on SMART on FHIR and OAuth 2.0. Picking the wrong flow is a common early misstep, so match it to how your app runs:

• App launches inside the clinician's chart (Hyperdrive or Hyperspace) - use SMART EHR Launch. Epic passes the patient and the encounter context to you.
• App runs on the patient's own device (from MyChart or a phone) - use SMART Standalone Patient Launch with PKCE, and request offline_access if you need refresh tokens.
• No human in the loop (bulk export, batch sync, server to server) - use Backend Services, the client_credentials flow with a signed JWT (private_key_jwt). Epic recommends backend OAuth for system integrations.

One trap worth knowing: a 403 from Epic is usually a scope or role problem, not a bad token, and scopes are fixed at registration. Asking for a scope you did not register simply fails.

What is free, and what costs money

The most damaging myth is that Epic charges a fortune just to read data. It does not. Because the 21st Century Cures Act made certified standardized APIs mandatory, every Epic customer must expose the USCDI data set (labs, meds, problems, vitals, demographics) as free, read-only FHIR APIs.

So the standardized read surface is free. What costs money is everything beyond it: a Connection Hub listing, Vendor Services membership for proprietary APIs, the build labor, and each customer's security review. This nuance gets lost in frustrated forum posts. One developer memorably claimed Epic gates sharing behind "a $100k API-key... per-hospital," which captures how the process feels even though the standardized read APIs are, in fact, free. Know the difference so you budget for the real costs, not the mythical ones.

What Epic integration really costs, and how long it takes

Membership fees are rounding errors next to the build. Reported ranges by integration shape:

• FHIR read-only: roughly $40,000 to $80,000, 2 to 4 months.
• FHIR read and write: roughly $80,000 to $180,000.
• Full bidirectional: $150,000 to $350,000 and up, 6 to 14 months.
• Deep Hyperdrive embedding: the most expensive, 8 to 14 months to a first live customer.

One CTO reported a single Epic integration costing about $300,000 in labor over eight months. And the calendar is rarely the build's fault: the customer's own Epic IT team is frequently backlogged three to six months before they can even start your provisioning. Plan for 6 to 18 months end to end, and treat access, not code, as the critical path.

Want the full breakdown? See our deep dive on how long Epic integration really takes — the 9-phase timeline, costs by type, and a readiness checklist to avoid the stalls.

Sandbox is not production

The sandbox is a sales environment. It is clean, small, and well-behaved, which is exactly why it is dangerous. As Brendan Keeler, one of the most respected voices in health-data interoperability, put it:

"Perhaps most problematically, the sandbox environment provides just enough functionality to give developers a false sense of confidence, only for them to encounter significant unexpected challenges during their first actual customer installation."

- Brendan Keeler, Health API Guy

Production brings duplicate demographics, merged records, allergies stored as free text, per-customer endpoint URLs, real rate limits, and 429s. Validate against the messiest real data you can get your hands on before you commit to a date. This is the same principle that holds across every interoperability project: test against reality, not against the demo.

Write-back and bulk data: what Epic permits

Reading standardized data is the easy part. Writing and bulk access are governed, not just technical:

• Write-back is permitted but heavily gated. You can write clinical notes (DocumentReference) and some observations, but orders and billing are often not available through FHIR. Many teams fall back to HL7 v2 through an interface engine for those flows. Treat every write scope as a clinical-governance decision the hospital must approve, not an API toggle.
• Bulk export ($export) runs through the Backend Services flow with system scopes, but "all patients" system-level export is often disabled. Group IDs come from the customer organization by email, not self-service.

For order, billing, and ADT flows that FHIR will not carry, an integration engine like Mirth Connect or an X12 pipeline usually does the heavy lifting alongside the FHIR work. If you want the standards background, our guide to FHIR, HL7, and the other interoperability standards is a good primer.

The mistakes that quietly kill Epic integrations

Beyond the technical gates, a few hard-won lessons from people who have shipped these:

Treating it as a code problem. Keeler's law, repeated across the field, is that "integration is 20% development, 80% negotiation and coordination." The engineering is rarely what stalls you.

Underestimating the platform risk. One developer recounted a sobering experience on Hacker News:

"We demoed the product and at the end, the Epic person says... that they think our product should really be part of Epic... Not surprisingly, Epic did exactly that... Epic undercut us on cost, despite their atrocious UI."

- Anonymous developer, Hacker News (2025)

It is a real dynamic worth pricing into your strategy: build genuine defensibility beyond the integration itself.

Forgetting the per-site tax. Every new hospital is a fresh security review, a fresh provisioning queue, and sometimes a slightly different API behavior. Budget for it from customer number two.

Can offshore or global teams build Epic integrations?

Yes, with care, and it is worth answering honestly because the question comes up constantly. Sandbox development, FHIR and SMART work, app registration, and the bulk of the engineering can be done by a capable global team. What requires discipline is anything touching production PHI: that needs the right Business Associate Agreements, scoped and revocable access, audit logging, and adherence to each customer's security requirements. The work is not gated by geography; it is gated by whether the team handles compliance correctly. A team that treats EHR integration security as a first-class concern can deliver it from anywhere.

Direct vs middleware: a quick decision

You do not always integrate with Epic directly. The honest framing:

• Go direct when Epic is your one or two key customers, you need deep or write-back integration, or you want to own the relationship and margin.
• Use an aggregator (Redox, Particle, Metriport) when you need many EHRs fast and read-only data, and you are comfortable with a dependency and a per-transaction cost. Note that the aggregator space has had real legal turbulence with Epic, so weigh that platform risk.
• Use an interface engine when the hospital speaks HL7 v2, not FHIR, which is still the majority of real-world clinical messaging.

The same logic applies to Cerner (Oracle Health) and the other major EHRs. There is no single right answer, only the one that fits your customer mix and your appetite for owning the plumbing.

How to de-risk it

The teams that get through this cleanly do three things. They line up a sponsoring customer before they write production code. They validate against real, messy data instead of the sandbox. And they treat access, security, and the per-site security review as the project, not an afterthought.

That is the work our team does every day. We build the FHIR, HL7, and X12 connection layer so a startup's own engineers can stay on their product. Our proof is public: our open-source headless FHIR server passes the ONC g10 / Inferno SMART App Launch suite, 47 of 47 tests, and the code is on GitHub. We would rather show you a passing test suite than a slide.

If you are scoping an Epic integration and want a second set of eyes on it, our healthcare interoperability solutions team connects digital-health products to Epic and the major EHRs every day, and our custom healthcare software development team can build the app around it. Talk to our team to pressure-test your scope before you commit to a timeline.