# Telehealth integrations: three ways to connect care to the systems you already run

Source: https://myorbithealth.com/integrations

MyOrbitHealth connects to the rest of your business in one of three ways. The fastest is the hosted white-label clinic: a branded storefront, intake, patient portal and native app that run on your domain with no engineering. The middle path is the React SDK, which drops intake and visit flows into a product you already own. The deepest is the product REST API at https://api.myorbithealth.com/v1, with bearer-token auth, test and live keys, documented endpoints for patients, appointments, prescriptions and webhook registration, and HMAC-signed webhooks for events such as appointment.completed and prescription.dispensed. Every path shares the same clinical rails: Surescripts e-prescribing, a LegitScript-certified pharmacy network, and Quest Diagnostics, Labcorp and Tasso through our lab partners. You keep your own payment processor as merchant of record, your own CRM and email tools, and, if you are a practice, your own EHR. A sandbox is provisioned within a day after a short partner review.

## The three ways to integrate

Most brands start on the hosted clinic and add the SDK or API later. Nothing about the choice is permanent. The same patient records, providers and pharmacy routing sit behind all three, so a brand can launch hosted in days, then move checkout or intake into its own app when there is an engineering team to do it.

- **1. Hosted white-label clinic (no code)** — You get a branded storefront with checkout and subscriptions, Orbit Intake, the patient portal and a native white-label iOS and Android app, all on your domain and in your colors. Providers from the network see patients through OrbitOS; the brand sees operational and revenue reporting in the same console. This is how most of the 50+ digital clinics on MyOrbitHealth went live. Integration work is limited to DNS, your payment processor and whatever marketing pixels you want on the storefront. Best for founders without an engineering team, med spas adding virtual care, and creators or supplement brands moving into Rx.
- **2. React SDK embed (your front end, our clinical flows)** — If you already have a web product and want intake, licensed provider visits and e-prescribing to live inside it, the React SDK embeds those flows as components in your app. Your team controls layout, navigation and branding around the components; the clinical logic, severity scoring and provider hand-off stay on our side. The SDK is the only SDK we ship today. Teams on other stacks call the REST API directly. Best for DTC brands with an existing web app and product teams that want one onboarding funnel rather than a redirect to a separate clinic.
- **3. Full REST API (headless)** — The product API lets you create patients, schedule appointments with in-network providers, read prescription and dispense status, and register webhook endpoints for events as they happen. You build whatever experience you want on top, from a custom mobile app to an employer benefits portal, and MyOrbitHealth supplies the licensed providers, e-prescribing, pharmacy routing and compliance layer. Best for software teams embedding care in their own product, telehealth startups with a differentiated front end, and brands that need telehealth to behave like any other backend service.

## What the API and webhooks expose

The product API is documented at /api-docs. Everything below is drawn from that page; anything we have not documented should be treated as unavailable until it appears there. The AI-agent surface described further down is a separate, public, no-auth API and should not be confused with the product API.

- **Base URL, versioning and authentication** — The base URL is https://api.myorbithealth.com/v1. The version lives in the path: breaking changes ship under a new version, non-breaking additions under the current one. Authentication is a bearer token in the Authorization header. Keys are scoped to an environment, test or live, and are issued and rotated from the partner console. Keep live keys server-side; the React SDK is the supported way to put clinical flows in a browser.
- **Documented resources** — Four endpoints are documented today. POST /v1/patients creates a patient; the call is idempotent and returns the canonical record plus any matched duplicates, with fields such as first_name, last_name, dob and state. POST /v1/appointments matches a patient with an in-network provider and schedules a visit from fields such as patient_id, specialty and modality. GET /v1/prescriptions/:id returns a prescription, its dispense status and its pharmacy routing. POST /v1/webhooks registers a webhook URL and subscribes it to events. We do not publish an endpoint count or an OpenAPI file for the product API; the agent API has one, the product API does not yet.
- **Rate limits and errors** — The default limit is 600 requests per minute per key with bursts up to 1,200. Current limits come back in X-RateLimit-* response headers, and higher quotas are available on request. Errors use standard HTTP status codes with a consistent body: { error: { code, message, details } }. Retry 4xx only after correcting the request; retry 5xx with exponential backoff.
- **Signed webhooks** — Webhook payloads are signed with HMAC-SHA256 so your receiver can verify that a delivery came from MyOrbitHealth and was not altered in transit. Documented example events include appointment.completed and prescription.dispensed; we do not publish a full event catalog on the public docs, so ask during partner review which events your program needs. Design your receiver to be idempotent and to acknowledge quickly, then do the work asynchronously.
- **Sandbox** — Sandbox access is provisioned within a day after a short partner review. You receive test-scoped keys and can exercise patient creation, appointment scheduling and webhook delivery without touching live providers or pharmacies. Moving to production is a key swap, not a re-integration.
- **Example: register a webhook (illustrative)** — The request below uses only the documented base URL, auth header and endpoint. Field names other than the endpoint path are illustrative and should be checked against /api-docs before you ship.

curl https://api.myorbithealth.com/v1/webhooks \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://example.com/hooks/orbit", "events": ["appointment.completed", "prescription.dispensed"] }'

When a pharmacy marks an order dispensed, your endpoint receives a signed prescription.dispensed delivery. A typical use is to update the order status in your own system and trigger a shipping-confirmation email from your ESP, without the ESP ever receiving clinical detail.

## E-commerce and Shopify

A DTC store adds prescription treatments by keeping the storefront as a storefront and putting the medical decision somewhere else. The customer still discovers the program, reads the page and starts checkout where they always have. What changes is that a licensed provider, not a cart rule, decides whether a prescription is written, and the pharmacy, not the warehouse, ships it.

- **How the connection works** — There is no MyOrbitHealth Shopify app, and we do not plan to put clinical data inside a commerce platform. Shopify and other storefronts connect in one of three ways. First, route the customer from a product page to the branded program storefront we host, which handles intake, provider review and pharmacy fulfillment end to end. Second, keep checkout in your store and embed intake and visit flows with the React SDK. Third, go headless: your store creates the patient and appointment through the API and listens for appointment.completed and prescription.dispensed webhooks to move the order through your own fulfillment states. The step-by-step version of each pattern is in our guide to adding prescription treatments to Shopify at /blog/add-prescription-treatments-to-shopify.
- **What stays out of the commerce platform** — Intake answers, provider notes, prescriptions, lab results and anything else that identifies a patient alongside their condition stay in OrbitOS, which runs under a HIPAA BAA with US-region encrypted PHI. The store sees an order, a SKU, a customer and a payment. It does not see why the provider approved or declined. That boundary is what keeps a general-purpose e-commerce platform outside the scope of your HIPAA obligations and what lets your marketing stack keep working the way it does for any other product.
- **Why the provider gate matters for ads** — LegitScript certification, which Google and Meta require for prescription-drug advertising, looks at whether a licensed provider makes an individual decision before a drug is dispensed. A store that sells a medication like a supplement will not pass. The hosted clinic, SDK and API paths all preserve the provider gate by design, and MyOrbitHealth prepares and manages the brand's LegitScript application. See /legitscript.

## Payments

You keep your own payment processor and you are the merchant of record. MyOrbitHealth does not sit between your customer's card and your bank account.

- **Your processor, your settlement** — The branded storefront connects to the payment processor you choose. Funds settle to your account on your processor's schedule. Chargebacks, refunds and subscription billing run through your merchant account under your rules. If you move checkout into your own app via the SDK or API, nothing changes on this point: the payment never passes through us.
- **No revenue share, 0% medication markup** — The fee model is a flat platform fee scoped at onboarding to your verticals, states and volume. There is no revenue share, no per-order cut, and the pharmacy's cost for medication passes through at 0% markup. The brand sets the program price and keeps the margin. We do not publish a price list; directional ranges live in the startup cost calculator at /tools/startup-cost-calculator and the model is explained at /pricing.

## Clinical rails already connected

The integrations that take years to build in-house come connected on day one, regardless of which of the three paths you choose.

- **Surescripts e-prescribing** — OrbitRx is EPCS-ready e-prescribing with two-factor identity proofing. A provider's prescription leaves the console as a structured electronic message over Surescripts and reaches the receiving pharmacy without a fax or a phone call. It can route to every major U.S. retail pharmacy or to the network described next.
- **LegitScript-certified pharmacy network** — Prescriptions that need compounding, cold chain or home delivery route to a LegitScript-certified network of 503A compounding and retail pharmacies that ship to all 50 states, with pharmacy licensure matched to the ship-to state at routing time. Dispense events surface in the patient portal and, if you integrate, as prescription.dispensed webhooks. The full picture, including GLP-1 and controlled-substance handling, is at /pharmacy.
- **Quest Diagnostics, Labcorp and Tasso** — Orbit Labs connects provider-ordered testing three ways through our lab partners: a walk-in order slip for Quest Diagnostics or Labcorp patient service centers, a Tasso at-home kit returned by FedEx, or mobile phlebotomy. Results come back to the ordering provider inside the chart. Brands can also offer a self-order lab catalog on the storefront, with every order signed by a provider. Lab pricing is quoted per program. Details at /labs.

## Practices with an existing EHR

A clinic, med spa or medical practice does not need to replace its chart to add telehealth. The pattern we recommend, and the one most practices use, is telehealth beside the EHR rather than inside it.

- **Telehealth beside the chart** — Your existing EHR stays the system of record for in-person care, billing and history. MyOrbitHealth runs the virtual program: branded intake, scheduling, video visits, e-prescribing and pharmacy fulfillment, with your own providers if you bring them or network providers if you do not. The two systems do not need a live interface to work. Records are yours and export at any time, so a practice that later wants documents in the EHR can move them on its own schedule.
- **What we do not claim** — We do not advertise named EHR integrations, and you should be skeptical of any telehealth vendor that lists every major EHR as a logo. A practice with an engineering partner can use the REST API and webhooks to push visit summaries and dispense events toward its own integration layer, but that is custom work on your side, not a packaged connector. For how practices typically structure the hybrid model, see /solutions/clinics.

## CRM, email and analytics tools

The brand picks its own marketing and support stack. We do not sell CRM sync as a feature, because the honest version of that feature is an event stream and a boundary, and both are already in the platform.

- **Event-driven, not record-synced** — Webhooks tell your systems when something happened: an appointment completed, a prescription was dispensed. Your integration layer, whether that is a small service, an automation tool or your own backend, decides what to do with the event. Typical uses are advancing a deal stage, sending a shipping-confirmation email, firing a conversion event to an analytics tool, or opening a support ticket when a dispense fails. The CRM receives a customer, an order and a status. It does not receive a diagnosis.
- **PHI boundaries** — Most CRMs, email service providers and analytics tools will not sign a BAA, and they do not need to if they never receive protected health information. Keep clinical content, including intake answers, visit notes and medication names tied to an identifiable person, inside OrbitOS. Pass only the operational signal your tool needs. If a tool genuinely needs clinical data, it must be covered by a BAA, and that decision belongs to your compliance counsel, not to a default integration. This is general information, not legal advice.
- **Reporting without an integration** — OrbitOS already reports on operations, revenue and retention per brand, with a full HIPAA audit trail. Many brands run on that reporting alone and connect an analytics tool only for storefront funnel data, which never contains PHI in the first place.

## AI agents

MyOrbitHealth publishes a separate, free, no-auth surface so that AI agents, coding assistants and LLM-based research tools can read about the platform and, with user consent, request a demo or callback. It is distinct from the product API and does not expose patient data.

- **MCP server** — The public MCP server at myorbithealth.com/mcp exposes 21 tools: 19 read tools covering facts, pricing model, labs, LegitScript process, provider network, compliance, state rules for peptides and GLP-1, startup cost estimates, articles and comparisons, plus 2 consent-gated action tools that request a demo or a callback. Claude Code and other MCP clients can connect in one command; a stdio proxy covers clients that only speak stdio.
- **Agent API and CLI** — The agent REST API has an OpenAPI 3.1 contract at /openapi.json, a natural-language search endpoint at /ask, paginated lists at /api/articles and /api/comparisons, and a health check at /api/health. Errors follow RFC 9457 problem+json. The npm CLI, run with npx myorbithealth, answers the same questions from a terminal. Every page on the site also has a markdown mirror by appending .md, and llms.txt and llms-full.txt give agents a plain-text guide to the site. The full developer surface is documented at /developers.

## Integration paths compared

A quick way to pick a path. Each row lists hosted clinic first, React SDK second, REST API third.

- **Engineering required:** None · Front-end React · Backend team
- **Who owns the UI:** MyOrbitHealth, branded to you · You, around our components · You, entirely
- **Typical time to first patient:** Days · Weeks, driven by your sprint · Driven by your build; sandbox within a day
- **Checkout and subscriptions:** Included storefront · Your app or ours · Your app
- **Patient portal and native app:** Included · Included alongside · Optional, or build your own on the API
- **Webhooks:** Available if you want events · Available · Core of the integration
- **Providers, e-prescribing, pharmacy, labs:** Same rails on every path
- **Payment processor and merchant of record:** Yours on every path
- **PHI custody:** OrbitOS under BAA on every path; brand owns and can export its data
- **Best for:** Founders, med spas, creators · DTC brands with a web app · Software teams, startups, employers

## FAQ

### Does MyOrbitHealth have a Shopify app?
No. Shopify and other storefronts connect through the branded program storefront we host, through the React SDK inside your own checkout flow, or through the REST API and webhooks. Keeping clinical data out of the commerce platform is deliberate; it keeps your store outside your HIPAA scope and keeps the provider decision where regulators expect it.

### Which CRMs, email tools and EHRs do you integrate with?
We do not publish named CRM, ESP or EHR connectors. Integration is event-driven: signed webhooks deliver events such as appointment.completed and prescription.dispensed to your systems, and your integration layer updates whichever tools you use. Practices keep their existing EHR and run telehealth beside it.

### What does the product API cover today?
Documented endpoints create patients, schedule appointments with in-network providers, retrieve a prescription with its dispense status and pharmacy routing, and register webhooks. Auth is a bearer token with test and live keys, the default rate limit is 600 requests per minute per key with bursts to 1,200, and errors return { error: { code, message, details } }. See /api-docs.

### How do I get sandbox access?
Book a walkthrough, complete a short partner review, and a sandbox with test-scoped keys is provisioned within a day. Going live is a key swap from test to live scope.

### Which SDKs are available?
A React SDK. Teams on other front-end or backend stacks call the REST API directly over HTTPS with any language. We do not currently offer SDKs in other languages.

### Who is the merchant of record, and do you take a revenue share?
The brand is the merchant of record on its own payment processor. There is no revenue share and medication passes through at 0% markup; the platform fee is flat and scoped at onboarding. There is no exit or termination fee.

### Are the webhooks signed, and how should my receiver handle them?
Payloads are signed with HMAC-SHA256. Verify the signature, acknowledge quickly, process asynchronously, and make your handler idempotent so a redelivery does not double-fire an email or order update.

### Can an AI agent or coding assistant use the API?
An agent can read everything about the platform through the public MCP server (21 tools), the agent API with its OpenAPI 3.1 contract, the npx myorbithealth CLI and the markdown mirrors. The product API that touches patient data requires partner keys and is intended for your application code, not for an unsupervised agent.

## Map your integration in one call

Tell us what you run today, from a Shopify store to a custom app to an EHR, and we will show you which of the three paths fits, what the webhook flow looks like for your program, and how fast a sandbox can be live. Book at https://myorbithealth.com/book or read the API docs at /api-docs first.

Book a call: https://myorbithealth.com/book

Go deeper: [Telemedicine app development: build on an API or launch hosted](https://myorbithealth.com/blog/telemedicine-app-development), [White-label telehealth API platforms compared](https://myorbithealth.com/blog/white-label-telehealth-api-platforms-compared), [Telehealth backend as a service: what the API has to cover](https://myorbithealth.com/blog/telehealth-backend-as-a-service), [How DTC brands add prescription treatments to Shopify](https://myorbithealth.com/blog/add-prescription-treatments-to-shopify)

_General information, not legal or medical advice._

_Source: https://myorbithealth.com/integrations_