← Blog
Field note

Epic App Orchard to Showroom: Integrating With Epic in 2026

Thien Nguyen · Nov 11, 2026

In 2026 you can integrate with Epic for $0 in Epic fees: open.epic's public FHIR and standards-based APIs are free and self-service. Pay only if you need more: Vendor Services starts at $1,900 a year for documentation, sandboxes and Epic support, and a Connection Hub listing on Showroom costs $500 per app per year.

App Orchard is gone. Epic replaced it with Showroom, split the developer experience into open.epic (free, self-service) and Vendor Services (paid, supported), and keeps adding APIs: its August 2026 release supports USCDI v5 and US Core 8, and it has published 50+ APIs for the CMS prior authorization rule. For a CTO or head of product, the question is no longer "can we get into Epic?" but "which path, which APIs, and how long will each health system's queue take?" This guide covers what Epic's own pages say as of November 2026. BeevR is not an Epic partner and has no Showroom listing.

What replaced Epic App Orchard?

Showroom replaced App Orchard as Epic's marketplace. Developer tooling now lives in two places: open.epic (including Epic on FHIR at fhir.epic.com) for free self-service access, and Vendor Services for paid support, extra documentation and testing tools.

Epic's Vendor Services FAQ defines the Showroom product tiers:

  • Cornerstone Partners: technologies integral to Epic software.
  • Toolbox: products in specific categories that follow Epic's recommended integration practices (a "Blueprint").
  • Toolbox Under Construction: Toolbox categories whose recommended practices are still being written.
  • Connection Hub: products with a live connection to at least one Epic site.

Two points from the FAQ change how you plan. First, "no special relationship is required to develop or deploy an app." Second, a Connection Hub listing "is not required for customers to download your app." Showroom is marketing and designation, not a gate to the API.

How much does it cost to integrate with Epic in 2026?

Epic's own fees are small: $0 for open.epic, from $1,900 a year for Vendor Services, and $500 per app per year for a Connection Hub listing. The real cost is your engineering time plus each health system's IT and security work, which no Epic page prices for you.

PathEpic fee (published)What you getWhen it fits
open.epic / Epic on FHIR$0Public FHIR and standards-based API docs, self-service sandbox, client ID registration, customer FHIR endpointsStandard SMART on FHIR apps, patient-access apps, read-heavy integrations
Vendor ServicesFrom $1,900/year; 3-month trial with refund less used servicesExtra documentation, Epic-specific APIs, HL7 v2 and X12 specs, expanded sandbox, Hyperspace Simulator, Hyperdrive harness, Sherlock tickets, design helpDeep workflow integration, Epic-specific APIs, embedded apps, interface work
Showroom Connection Hub$500 per app per yearPublic listing; requires attesting one live Epic connectionMarketing to more Epic customers after the first go-live
ToolboxNot publishedEpic designation for products that follow a category BlueprintProducts in a category Epic has defined

Sources: Vendor Services pricing and trial terms from Epic's Vendor Services FAQ; the $500 Connection Hub fee from Epic's Vendor Services materials and Fierce Healthcare's Showroom launch coverage. Epic's FAQ says you sell directly to customers and "negotiate pricing and terms" yourself; none of these Epic materials mention a revenue share.

Bar chart of Epic's published developer fees per year: open.epic and Epic on FHIR $0; Showroom Connection Hub listing $500 per app per year, requiring one live Epic connection; Vendor Services from $1,900 per year.
Epic's fees are small; health-system IT time is the real cost.

Which Epic APIs are free?

Epic says its "catalog of public and industry-standards-based APIs" on open.epic is available "at no additional cost." open.epic counts over 750 no-cost APIs and interfaces, and 3,423 live apps using its web services.

Recent additions matter for 2026 roadmaps:

  • USCDI v5 and US Core 8 in the August 2026 release, including advance directives, care-experience preferences and medication adherence data.
  • 50+ APIs and playbooks for CMS-0057-F (prior authorization, Provider Access, Payer-to-Payer). Impacted payers face API deadlines primarily on January 1, 2027, which is why prior-auth and payer-provider exchange is the busiest Epic integration area this year.
  • An open.epic MCP server that lets AI clients search open.epic documentation and specifications. It is a documentation tool, not a PHI channel.
  • 40+ developer playbooks and "one-click" client ID templates with the recommended APIs pre-selected.

What open.epic does not give you: Epic-specific (non-standard) APIs, embedded desktop and mobile testing, HL7 v2 and X12 interface specs, and direct Epic engineering help. Those are Vendor Services territory.

Four stats from open.epic in November 2026: over 750 no-cost APIs and interfaces; 3,423 live apps using open.epic web services; over 50 APIs for the CMS-0057-F prior authorization rule; USCDI v5 and US Core 8 supported in the August 2026 release.
The free catalog keeps growing, led by CMS-0057 and USCDI v5.

How does backend (server-to-server) auth work with Epic?

Epic follows the SMART Backend Services profile with a signed-JWT client-credentials grant, "though it currently differs from that profile in some respects." You register a JWK Set URL, sign a short-lived JWT, and exchange it for an access token. Each health system must also map your backend client to a user so its activity is audited.

Details from Epic's OAuth 2.0 specification that trip teams up:

  • Algorithms: RS256, RS384 and RS512 for all confidential clients; ES256 and ES384 only for clients that register a JWK Set URL. Epic recommends new apps use a JWKS URL with elliptic-curve keys.
  • JWT lifetime: exp can be no more than 5 minutes in the future.
  • Replay protection: jti must be at most 151 characters and cannot be reused while the JWT is valid.
  • Separate keys: Epic will not accept a non-production JWKS URL as the production URL for new apps. Use separate key pairs per environment.
  • Customer build: outside the sandbox, the health system must complete setup to audit your backend app's access. Budget time for that in every go-live.

We go deeper on scope design, key rotation and agent-specific risks in SMART on FHIR backend services.

Can you write data back into Epic?

Yes, for specific resources. Epic says it "supports read and write operations for dozens of FHIR resources and sub-resources," plus CDS Hooks (patient-view and order-sign) and Epic-specific APIs where standards do not yet exist. Which writes are available depends on the API, the Epic version and the health system's configuration.

Write access raises the bar. Health systems will ask what your app writes, who reviews it, how errors are reversed, and how every action is attributed. For AI features this is the main design question, not a detail. A model that drafts and a person who files is far easier to approve than a model that files on its own. We explain that pattern in human-in-the-loop AI for regulated industries.

Is Epic Bulk FHIR good for analytics and AI training data?

Only for some jobs. Epic supports only the Group export operation (Bulk Data 1.0.1 plus some later features), does not support _since, and lists warehouse synchronization and incremental loads as poor use cases. Results are kept for 14 days, then deleted.

Epic's bulk data tutorial also warns that exports run on the organization's operational database, and recommends polling status every 10 minutes for groups under 100 patients and every 30 minutes for larger groups. Good fits are periodic exports of a defined cohort or registry submissions. For a full analytics or AI pipeline, ask the health system about Epic's warehouse options instead. Our bulk FHIR export guide covers the trade-offs in detail.

How long does an Epic integration take?

Your build can be weeks; the health system's side usually sets the date. Epic says registration, connection and go-live can happen on open.epic "without needing Epic's involvement," but each customer still runs its own security review, analyst build, testing and change control.

Epic lists three groups you work with at each customer: operations (department leads, clinical champions), IT (Epic-certified analysts), and Epic support staff pulled in as needed. Plan for:

  1. Scoping with the customer: which APIs, which scopes, which user the backend client maps to.
  2. Security review: questionnaires, BAA, penetration test evidence, data flow diagrams. A SOC 2 report shortens this.
  3. Analyst build and testing in the customer's non-production environment.
  4. Go-live and monitoring, including what happens when Epic upgrades change behavior.

None of these timelines are published by Epic, and they vary widely by health system. Do not promise a customer a date before their IT team has scheduled the work.

Should you use open.epic, Vendor Services or both?

Start with open.epic. Move to Vendor Services when you need Epic-specific APIs, embedded workflows (Hyperspace, Hyperdrive, MyChart, mobile), HL7 v2 or X12 interfaces, or Epic's design help. List on Connection Hub after your first live customer, when you want other Epic customers to find you.

Signs you need Vendor Services

  • Your workflow needs an API that is not in the public catalog.
  • You need to test inside Epic's client (the Hyperspace Simulator or Hyperdrive harness).
  • You are building an interface (ADT, orders, results) rather than an app.
  • You want Epic's input on design before a health system's analysts review it.

Signs you do not

  • Your app uses standard FHIR resources and SMART launch.
  • You are proving the product with one design-partner health system first.

What are the common failure modes in Epic projects?

The usual ones: building on sandbox data that looks nothing like production, assuming every health system enables the same APIs, ignoring the per-customer user mapping for backend clients, and treating Showroom listing as the finish line.

AI features add three more: sending more PHI to a model than the task needs, letting a model write to the chart without review, and having no evaluation set that proves the feature works on real-world data before go-live. See HIPAA-compliant AI agents for the controls, and LLM testing for regulated industries for the evaluation side.

How BeevR builds this

We build the application side of Epic integrations: SMART on FHIR apps, backend services with JWKS key management, bulk export pipelines, and AI features that draft for a clinician to approve. We work from Epic's public documentation and your customer's environment; we are not an Epic partner, and we tell you when an Epic-native or off-the-shelf product is the better buy. Every action is logged, scopes are minimal, and nothing is written to the chart without a person confirming it. BeevR signs a BAA as a business associate, AI models can run inside your own AWS account under the AWS BAA, and you own the source code and IP from day one.

Our senior, founder-led team in Hanoi has a multi-tenant EHR live across four US clinics at about 300 patients a day, and you get a working demo every Friday. Projects run as fixed-scope, fixed-price phases from $10K per phase. See our EHR integration services and healthcare AI agent development.

Planning an Epic integration for 2027? Book a 30-minute call and we will map your use case to the Epic path, APIs and customer steps it actually needs.