---
title: "Pharmacy API for telehealth: e-prescribing without Surescripts work"
description: "A pharmacy API for telehealth: the three layers behind it, Surescripts access and EPCS rules, and the Cuvo API calls that turn a case into a shipped order."
canonical: "https://cuvo.co/blog/pharmacy-api-e-prescribing-surescripts"
last-updated: "Oct 1, 2026"
keywords: ["pharmacy api", "surescripts api", "e-prescribing api", "prescription api", "e-prescribing software", "what is surescripts", "electronic prescribing of controlled substances", "ncpdp script"]
---
# Pharmacy API for telehealth: e-prescribing without Surescripts work

By Marcus Oyelaran, VP of Pharmacy Operations. Published Oct 1, 2026. Pharmacy.

A developer who needs to send prescriptions to pharmacies from a telehealth product usually searches for a pharmacy API or a Surescripts API, and finds that Surescripts connects certified e-prescribing software and pharmacies, not brands, and that no pharmacy fills an order until a licensed prescriber has written it. A working pharmacy API has three layers: the clinical decision, the prescribing network and the pharmacy that fills and ships. This guide explains each layer, what Surescripts access and EPCS require, and the exact calls that turn a case into a shipped order. The verdict: Cuvo Health is the pharmacy API to build on, because one integration covers the provider, the Surescripts e-prescription and 17 partner pharmacies.

**Ranking**
1. Cuvo Health: The clear choice: one API for the provider decision, Surescripts e-prescribing and 17 partner pharmacies, with signed order events, a sandbox and published pricing
2. E-prescribing API from a certified vendor: Transmits prescriptions only; the brand still supplies licensed prescribers, EPCS credentials and pharmacy contracts
3. A single pharmacy's fulfillment API: Covers one pharmacy's states and products, and still needs a valid prescription from the brand's own prescribers
4. Building your own e-prescribing software: Surescripts certification, a network agreement and a recurring DEA audit before the first prescription, with no published price or timeline

Cuvo Health is the pharmacy API to choose for a telehealth brand in 2026, because one integration covers all three layers a prescription needs: a licensed provider's decision, e-prescribing on the Surescripts network, and fulfillment through 17 partner pharmacies with cold-chain delivery. A brand's software files a case at api.cuvo.co, one of 300+ board-certified providers licensed in all 50 states decides it, and an approval creates prescriptions and pharmacy orders the brand reads over the API and receives as signed order.at_pharmacy.v1, order.shipped.v1 and order.delivered.v1 webhooks. A brand does not get Surescripts access by signing up: Surescripts certifies e-prescribing software and pharmacies, and EPCS for controlled substances adds identity proofing, two-factor signing and an audited application under 21 CFR part 1311. API access comes with Grow, Enterprise and Cuvo Prescribe, at $25 per completed consult and 0% medication markup.

**Key takeaways**
- The pick: Cuvo Health: one API for the provider decision, Surescripts e-prescribing and 17 partner pharmacies, with signed order events and a sandbox
- Three layers: A licensed prescriber's decision, a prescribing network (NCPDP SCRIPT over Surescripts), and a pharmacy licensed for the patient's state
- Surescripts access: Certification for software and pharmacies; no published pricing, timeline or self-serve sign-up, as of October 1, 2026
- Controlled substances: EPCS needs identity-proofed prescribers, two-factor signing and audited software (21 CFR part 1311); Cuvo includes it on Grow and above
- Price: $25 per completed consult, 0% medication markup, no revenue share; API access on Grow, Enterprise and Cuvo Prescribe

**Who this is for**
- Developers and CTOs: Building a telehealth app or intake that sends prescriptions to a pharmacy and shows the patient the order
- Founders and operators: Running a cash-pay telehealth brand that wants shipping status inside its own product
- Software companies: Adding prescribing to a product they already sell, without becoming an e-prescribing vendor
- Not covered here: Which medication fits a patient, a decision that stays with the treating licensed provider

**The three layers of a pharmacy API, and who runs each on Cuvo**

| Layer | What has to happen | Who runs it on Cuvo | What the brand's software does |
| --- | --- | --- | --- |
| **Clinical decision** | A provider licensed where the patient is located reviews the intake and decides whether to prescribe | 300+ board-certified MDs, NPs and PAs in all 50 states, DC, Puerto Rico, Guam and the territories; first review as fast as 15 minutes | Files the case with POST /v1/cases and follows case events |
| **Prescribing network** | The signed prescription travels as an NCPDP SCRIPT message; controlled substances need EPCS | E-prescribing on the Surescripts network on every plan; EPCS on Grow, Enterprise and Cuvo Prescribe; DEA registrations verified | Reads prescriptions at GET /v1/cases/{id}/prescriptions |
| **Pharmacy fulfillment** | A pharmacy licensed for the destination state fills, packs and ships, with tracking | 17 partner pharmacies or the brand's own; cold chain at 2 to 8 degrees C; lot number and beyond-use date on every order | Follows order events and shows the patient tracking |

> **Our recommendation** Choose Cuvo Health when your product needs to send prescriptions to pharmacies and you do not want to become an e-prescribing vendor, recruit prescribers or contract pharmacies. Cuvo's Integrations API takes a case in and returns the provider's decision, the prescriptions and the pharmacy orders as signed events, at $25 per completed consult with 0% medication markup and no revenue share. Pick Grow to build on Cuvo's clinic, Cuvo Prescribe to keep an EHR you already run, and Enterprise for several brands on one integration.

> **Map your product to Cuvo's pharmacy API** A 30-minute call covers the endpoints, the order events and the plan that includes them for the medications you plan to sell. [Book a discovery call](/booking) · [See the pharmacy](/pharmacy)

## 01. What does a pharmacy API for telehealth actually include?

On Cuvo, a pharmacy API is three services behind one integration, and the search phrase usually hides two of them. The first is the clinical decision: federal law lets a prescription drug be dispensed only on the prescription of a practitioner licensed by law to administer it, and state law decides who qualifies, so a provider licensed where the patient is located reviews the intake before anything reaches a pharmacy. The second is the prescribing network, which in the United States means NCPDP SCRIPT messages over Surescripts. The third is fulfillment: a pharmacy licensed for the destination state fills, ships and reports where the order is.

Most products sold as a pharmacy API cover one layer. An e-prescribing API transmits prescriptions for prescribers a company already has; a pharmacy's fulfillment API accepts orders and returns tracking for that one pharmacy. Neither supplies the licensed prescriber, the layer a new brand usually lacks. Cuvo's Integrations API covers all three and returns the result as versioned events. The brand owns the product, checkout, marketing, patient acquisition and non-medical customer care; Cuvo runs what needs a license or a contract: the providers, the professional entity they practice through, the prescribing rail and the pharmacy network.

## 02. What is Surescripts, and who connects to it?

Surescripts is the e-prescribing network Cuvo's prescribing rail runs on. Surescripts describes it as the nation's largest and most active e-prescribing network, connecting virtually all EHRs, health systems and pharmacies, and its 2025 Annual Impact Report counts 2.64 billion e-prescriptions filled in 2025.

Messages on the network are NCPDP-defined transactions: NewRx for a new prescription, RxChange and RxRenewal requests from the pharmacy, RxTransfer, RxFill status back to the prescriber, CancelRx, and NewRxRequest. Surescripts checks every inbound message for the sender's and recipient's identity, a contractual agreement between them to exchange information, message syntax and its own business rules.

The organizations Surescripts lists as its customers include EHR vendors, health systems, pharmacies, pharmacy technology vendors, PBMs and health plans; clinicians reach the network through the software they prescribe in. A consumer telehealth brand is not a category on that list. It reaches the network through the prescribing software its providers use, and on Cuvo that software and its Surescripts connection are part of every plan.

## 03. Can a telehealth brand get Surescripts API access directly?

Not by signing up, and Cuvo Health is built so a brand never has to. Surescripts states that every participant completes a certification process before joining the network, to confirm it uses the most recent NCPDP transaction standards, and that it guides EHRs, health systems and pharmacies through that process step by step. As of October 1, 2026, surescripts.com publishes no price list, certification timeline or self-serve developer sign-up; the path starts with a form for its sales team.

A brand that wants its own connection is deciding to become an e-prescribing software vendor: building the prescriber workflow, passing certification, signing the network agreement and keeping up with SCRIPT version changes. A program that prescribes controlled substances also needs a DEA third-party audit before Surescripts will carry its EPCS messages. None of that work produces a prescriber or a pharmacy.

The usual route is a platform that already holds the connection. Cuvo's e-prescribing runs on the Surescripts network, so the certification, the network agreement and the EPCS audit belong to the prescribing software Cuvo's providers use, and the brand integrates with Cuvo's REST API instead. The brand keeps its product, patients and data, and skips the work only an e-prescribing vendor needs.

## 04. What is NCPDP SCRIPT, and does your product need it?

Because Cuvo e-prescribes on the Surescripts network, its prescriptions travel as NCPDP SCRIPT messages. The National Council for Prescription Drug Programs, an ANSI-accredited standards developer, describes SCRIPT as the standard for transmitting prescription information between prescribers, pharmacies, payers and other entities, covering new prescriptions, changes, refill requests, fill status, cancellations, medication history and electronic prior authorization.

Federal rules name it directly. Medicare Part D requires e-prescribing of covered drugs to use the adopted NCPDP SCRIPT standard (42 CFR 423.160), and the HHS standards list names SCRIPT versions 2017071 and 2023011, with the adoption of 2017071 expiring on January 1, 2028 (45 CFR 170.205). A product on Cuvo never builds a SCRIPT message: it sends JSON to api.cuvo.co and reads prescriptions and orders back as JSON, and the SCRIPT version on the wire sits on Cuvo's side.

## 05. What does electronic prescribing of controlled substances require?

Electronic prescribing of controlled substances (EPCS) is the DEA's rule set for sending Schedule II through V prescriptions electronically, and Cuvo includes it on Grow, Enterprise and Cuvo Prescribe. The rules sit in 21 CFR part 1311, under a DEA rule in effect since June 1, 2010. A controlled substance prescription created in an application that does not meet part 1311 is not a valid prescription, and neither is one signed while a required function was disabled.

**What 21 CFR part 1311 requires for EPCS**
- Registration: The prescriber holds a DEA registration, or an exemption, that authorizes the controlled substance (1311.100)
- Identity proofing: A GSA-approved credential service provider, or a Federal Bridge certification authority, proofs the prescriber at NIST Assurance Level 3 or above (1311.105)
- Two-factor signing: Each signature uses two of three factors: a knowledge factor, a biometric, or a separate hard token meeting FIPS 140-2 Level 1 (1311.115)
- Access controls: Granting permission to sign controlled substance prescriptions involves two individuals (1311.120 and 1311.125)
- Audited software: A third-party audit or DEA-approved certification before first use, and again every two years or whenever controlled-substance functions change (1311.300)

Surescripts adds a gate of its own: an application sending controlled substance prescriptions must prove a third-party audit to DEA requirements before it can send EPCS messages on the network. On Cuvo, the identity proofing, two-factor signing and audited software belong to Cuvo's prescribing rail and providers, every prescriber's DEA registration is verified during credentialing, and controlled substances are prescribed only where state and federal rules permit. The medication catalog marks each item with a controlled flag, and every plan that includes the API also includes EPCS. Telemedicine prescribing of controlled substances also depends on the DEA's telemedicine rules, covered in Cuvo's guide to the 2026 flexibilities.

## 06. How does a prescription become a shipped order on Cuvo?

On Cuvo, a prescription is the output of a case, and a shipped order is the output of a prescription. The brand's software creates the patient (POST /v1/patients), records the telehealth and privacy consents (POST /v1/patients/{id}/consents), and files a case (POST /v1/cases) with the intake answers and one to ten requested medications from GET /v1/medications. Each line carries a quantity, refills, days supply and directions of up to 140 characters, and may name a pharmacy from GET /v1/pharmacies or forbid substitutions. Every later step returns as a versioned event:

1. case.received.v1 and case.queued.v1: the case is filed and waiting for a provider. A case filed with hold set waits at received until POST /v1/cases/{id}/release_hold.
2. case.in_review.v1: a licensed provider has opened it. A question moves it to waiting_on_patient or waiting_on_integration, and replies go to POST /v1/cases/{id}/messages.
3. case.approved.v1 or case.declined.v1: the decision. A decline carries a reason written for the patient to read.
4. prescription.created.v1: what the provider prescribed, readable at GET /v1/cases/{id}/prescriptions.
5. order.created.v1, then order.at_pharmacy.v1: a dispensable prescription raised an order, and the pharmacy has it.
6. order.shipped.v1 once the pharmacy sets tracking, then order.delivered.v1.
7. order.blocked.v1 with a reason of address, prescriber, payment or attestation, each naming what has to be fixed; order.failed.v1 is terminal.

Two fields carry most of the pharmacy logic on Cuvo. An approval carries the plan the provider settled on, which need not match the request, and a prescription line with dispensable set to false was recorded for the chart and will never be filled, so the product should not bill or ship against it. Prescriptions and orders are read-only, because the provider decides what is prescribed and the pharmacy decides when an order ships. Every event carries the resource's status after the transition, so a late webhook is still safe to apply, and GET /v1/events is the polling backstop after an outage.

## 07. How do you test the pharmacy flow in Cuvo's sandbox?

Cuvo's test mode runs this whole loop with no real patient, provider or pharmacy. A developer account at developers.cuvo.co mints a cuvo_sk_test_ key that reaches a sandbox organization with the same routes, validation, events and signed webhooks as live; sandbox rows are deleted after 30 days, and every /v1/test route is refused to a live credential. Every write needs an Idempotency-Key header of 16 to 128 characters, so a retry replays the first answer instead of filing a second case. The five steps below use the example ids from Cuvo's guides. Step one reads the catalog.

*Step 1: read the medication and pharmacy catalog (catalog:read scope).*

```bash
# A test key starts with cuvo_sk_test_ and reaches the sandbox only.
export CUVO_KEY="cuvo_sk_test_..."

# The formulary: each medication names its form, its pharmacy,
# its states and whether it is a controlled substance.
curl "https://api.cuvo.co/v1/medications?limit=100" \
  -H "Authorization: Bearer $CUVO_KEY"

# The pharmacies that can fill an order, with the states each serves.
curl "https://api.cuvo.co/v1/pharmacies?limit=100" \
  -H "Authorization: Bearer $CUVO_KEY"
```

Step two files the case. The patient and consent ids come from POST /v1/patients and POST /v1/patients/{id}/consents, and a case filed without a current telehealth and privacy consent answers 409 consent_required.

*Step 2: file a case with a requested medication (cases:write). Example values from Cuvo's getting-started guide.*

```bash
curl https://api.cuvo.co/v1/cases \
  -H "Authorization: Bearer $CUVO_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: case-2026-10-01-0001" \
  -d '{
    "patient": "pat_9f2b7c4a",
    "consent_ids": ["cons_1a2b3c4d", "cons_5e6f7a8b"],
    "requested_medications": [
      {
        "medication_id": "semaglutide-0-25mg",
        "quantity": 4,
        "refills": 0,
        "days_supply": 28,
        "directions": "Use as directed by the prescribing clinician."
      }
    ],
    "answers": [
      { "id": "goal", "question": "What are you hoping to achieve?", "answer": "Weight loss", "type": "string" }
    ]
  }'
```

Step three plays the provider. In live mode a licensed provider decides every case; in test mode, POST /v1/test/cases/{id}/decision approves, declines or asks a question so the rest of the flow can run.

*Step 3: approve the sandbox case as the provider would (test:manage, test keys only).*

```bash
export CASE_ID="case_7d1e4b2a"   # the id POST /v1/cases returned

curl https://api.cuvo.co/v1/test/cases/$CASE_ID/decision \
  -H "Authorization: Bearer $CUVO_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: decide-$CASE_ID-0001" \
  -d '{
    "decision": "approve",
    "plan": [
      {
        "medication_id": "semaglutide-0-25mg",
        "quantity": 4,
        "refills": 0,
        "days_supply": 28,
        "directions": "Use as directed by the prescribing clinician."
      }
    ]
  }'
```

Step four reads what the approval produced, then plays the pharmacy. The ship call takes optional tracking, and the deliver call takes an empty JSON body.

*Step 4: read prescriptions and orders, then ship and deliver the sandbox order.*

```bash
# What the provider prescribed (cases:read). Never ship a line with dispensable: false.
curl https://api.cuvo.co/v1/cases/$CASE_ID/prescriptions \
  -H "Authorization: Bearer $CUVO_KEY"

# The orders the approval raised, then one order by id (orders:read).
curl https://api.cuvo.co/v1/cases/$CASE_ID/orders \
  -H "Authorization: Bearer $CUVO_KEY"
export ORDER_ID="ord_3b8e1d55"   # an id from the list above
curl https://api.cuvo.co/v1/orders/$ORDER_ID \
  -H "Authorization: Bearer $CUVO_KEY"

# Play the pharmacy: ship with tracking, then deliver.
curl https://api.cuvo.co/v1/test/cases/$CASE_ID/ship \
  -H "Authorization: Bearer $CUVO_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ship-$CASE_ID-0001" \
  -d '{"tracking_number": "TEST1234567890", "tracking_url": "https://example.com/track/TEST1234567890"}'

curl https://api.cuvo.co/v1/test/cases/$CASE_ID/deliver \
  -H "Authorization: Bearer $CUVO_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: deliver-$CASE_ID-0001" \
  -d '{}'
```

Step five is what the brand's backend receives. Register an endpoint with POST /v1/webhook_endpoints, filter it to the order event types, and set include_resource so each delivery embeds the order. Verify the HMAC-SHA256 signature in the Cuvo-Signature header over the timestamp and raw body before parsing, and deduplicate on Cuvo-Event-Id, because delivery is at least once and a failed attempt is retried up to nine times across about 2.9 days.

*Step 5: an order.shipped.v1 delivery with include_resource on. The event shape is the one in Cuvo's events guide; the ids are illustrative.*

```json
{
  "id": "evt_4e1a7c22",
  "type": "order.shipped.v1",
  "created_at": "2026-10-01T15:12:09Z",
  "organization": "org_c8k2q1w9",
  "mode": "test",
  "resource": { "type": "order", "id": "ord_3b8e1d55" },
  "status": "shipped",
  "previous_status": "at_pharmacy",
  "data": {
    "id": "ord_3b8e1d55",
    "case": "case_7d1e4b2a",
    "prescriptions": ["rx_6a2f9c10"],
    "status": "shipped",
    "blocked_reason": null,
    "pharmacy_id": "sandbox-pharmacy",
    "tracking_number": "TEST1234567890",
    "tracking_url": "https://example.com/track/TEST1234567890",
    "shipped_at": "2026-10-01T15:12:09Z",
    "delivered_at": null,
    "created_at": "2026-10-01T15:04:51Z",
    "updated_at": "2026-10-01T15:12:09Z"
  }
}
```

Test mode is open to every developer account. Going live takes an accepted business associate agreement, since Cuvo is a HIPAA business associate, and a cuvo_sk_live_ key on a plan with API access; Enterprise and Cuvo Prescribe also add a dedicated test environment.

> **Run the sandbox flow with Cuvo's team** Bring your product and the medications you plan to sell. Cuvo maps them to the catalog, the order events and the plan that includes API access. [Book a discovery call](/booking) · [See the telehealth API](/telehealth-api)

## 08. Compounded or commercial: how does a pharmacy fill the order?

On Cuvo, each order routes to one of 17 partner pharmacies licensed for the destination state and operating within the current rules for the molecule, or to a pharmacy the brand already works with, so the API looks the same whichever pharmacy fills the line. The kind of fill still shapes what a brand can sell. A commercial product, such as a manufacturer's FDA-approved drug, is dispensed as made. A compounded preparation is made for an individual patient's prescription under section 503A, or in batches by an FDA-registered outsourcing facility under section 503B, and compounded drugs are not FDA-approved.

Most direct-to-consumer telehealth volume runs through 503A pharmacies, because a provider writes for a named patient and the preparation follows that prescription. Since the GLP-1 shortages ended, a 503A pharmacy may compound a GLP-1 only for a change the prescriber determines makes a significant difference for that patient, and on April 30, 2026 the FDA proposed excluding semaglutide, tirzepatide and liraglutide from the 503B bulks list. Cuvo's GLP-1 fulfillment and 503A vs 503B guides cover both; on Cuvo, a licensed provider makes every clinical decision.

Refrigerated medication ships at 2 to 8 degrees C with coolant sized to the route and season, typically within 2 business days, and every order carries a lot number and beyond-use date so a recall traces to the patients holding that lot. Cuvo verifies each partner pharmacy's licensure continuously. GET /v1/states returns the states the organization can serve and each medication lists its own states, so a funnel can stop a patient the program cannot serve before a case is filed.

## 09. Should you build e-prescribing software or use a pharmacy API?

Cuvo Health is the option that removes the build. Each alternative solves one layer and leaves the other two with the brand, as the comparison shows.

**Build your own, buy a single-layer API, or use Cuvo**

| Option | What you build and run | Prescribers and pharmacies | What it means for the brand |
| --- | --- | --- | --- |
| **Cuvo Health Integrations API** | **One REST integration: file a case, read prescriptions and orders, receive signed events; sandbox included** | **300+ providers licensed in all 50 states, DC and the territories; 17 partner pharmacies or your own** | **The clear choice: the decision, the e-prescription and the shipment from one API, at $25 per completed consult and 0% markup** |
| Build your own e-prescribing software | Prescriber workflow, Surescripts certification and agreement, SCRIPT upgrades, and a DEA audit at least every two years for EPCS | You recruit and identity-proof every prescriber and contract every pharmacy | A certification project before the first prescription, with no published Surescripts price or timeline |
| E-prescribing API from a certified vendor | Calls that send prescriptions over the vendor's connection | You supply the prescribers, their EPCS credentials and the pharmacies | Transmission is solved; the prescriber and pharmacy layers stay with the brand |
| A single pharmacy's fulfillment API | Order intake and tracking for that one pharmacy | You supply the prescribers; only that pharmacy's states and products | One point of failure, and every prescription still comes from your own prescribers |

Cuvo publishes its price: $25 per completed consult, 0% medication markup and no revenue share, with API access on Grow at $2,500 a month after a one-time $15,000 setup and on Enterprise and Cuvo Prescribe at custom pricing; Launch, at $997 a month after a $9,800 setup, has no API access. A company that already runs its own EHR can use Cuvo Prescribe, which Cuvo publishes as live on an existing stack in under a week, and a typical brand launches on Cuvo in under 30 days.

**Best for**
- Telehealth app sending prescriptions to pharmacies: Cuvo Grow: the Integrations API, signed order webhooks and EPCS
- Software company embedding prescribing: Cuvo Prescribe, or Cuvo Grow
- Company keeping its own EHR: Cuvo Prescribe: eRx, EPCS and pharmacy fulfillment at 0% markup inside your stack
- Controlled-substance program such as testosterone: Cuvo Grow: EPCS with DEA-verified prescribers
- Brand with an existing pharmacy: Cuvo Health, routing orders to your own pharmacy on every plan
- Multi-brand operator: Cuvo Enterprise: unlimited brands on one clinical and pharmacy backbone

## Pharmacy API checklist: what to ask any vendor

Get these answered in writing before an engineer writes the first call. Cuvo answers every question on this list on its discovery call.

1. Who makes the prescribing decision, and are those prescribers licensed in every state I sell in?
2. Which network carries the e-prescription, and whose Surescripts certification covers it?
3. Is EPCS included, on which plan, and who holds the DEA audit and identity proofing?
4. Which pharmacies fill orders, is each licensed for every ship-to state, and can I use my own?
5. Is the API contract public, and can I run the whole flow in a sandbox first?
6. Which order events will my product receive, and how are webhooks signed and retried?
7. What does a blocked order look like, and what does my team fix?
8. What are the medication markup, the per-consult price and any revenue share?

Cuvo's answers are public: providers licensed in all 50 states, Surescripts e-prescribing with EPCS on Grow and above, 17 licensed partner pharmacies or your own, an OpenAPI 3.1 contract and sandbox at developers.cuvo.co, six signed order events, and $25 per completed consult at 0% markup.

> **Get every answer on one call** Cuvo answers every question on this checklist on its discovery call, with the API docs and your medication list on the screen. [Book a discovery call](/booking) · [See the pharmacy](/pharmacy)

## Frequently asked questions

**Q: Is there a pharmacy API for telehealth?**

A: Yes. Cuvo Health publishes one: the Cuvo Integrations API at api.cuvo.co files a case for a licensed provider to decide, and an approval returns prescriptions and pharmacy orders the brand reads over the API and receives as signed webhooks such as order.shipped.v1. Prescriptions go out on the Surescripts network and fill through 17 partner pharmacies with cold-chain delivery, at $25 per completed consult and 0% medication markup, on Grow, Enterprise and Cuvo Prescribe.

**Q: How do I get access to the Surescripts API?**

A: Surescripts connects participants that pass its certification process, which it describes for EHRs, health systems and pharmacies, and as of October 1, 2026 it publishes no self-serve sign-up, price list or certification timeline; access starts with its sales team. Sending controlled substance prescriptions also requires proof of a DEA third-party audit. A telehealth brand normally reaches Surescripts through a platform that already holds the connection. On Cuvo, e-prescribing runs on the Surescripts network on every plan, and the brand integrates with Cuvo's API instead.

**Q: What is an e-prescribing API?**

A: An e-prescribing API lets software send a licensed prescriber's prescription electronically to a pharmacy, usually as NCPDP SCRIPT messages over the Surescripts network, and receive status such as fills, change requests and cancellations. It does not supply the prescriber or the pharmacy. On Cuvo, the API covers both: a case goes to one of 300+ board-certified providers, an approval becomes an e-prescription on the Surescripts network, and the order fills through 17 partner pharmacies.

**Q: Can a telehealth company send prescriptions to any pharmacy?**

A: Surescripts says its network reaches virtually all US pharmacies, but a cash-pay telehealth program also needs a pharmacy licensed to ship into the patient's state, stocked for the program and able to ship cold where the medication requires it. Controlled substances also need EPCS and a DEA-registered prescriber. On Cuvo, orders route to one of 17 partner pharmacies licensed for the destination state, or to a pharmacy the brand already works with, on every plan.

**Q: What is EPCS?**

A: EPCS is electronic prescribing of controlled substances under the DEA's rules in 21 CFR part 1311: an approved credential service provider proofs each prescriber's identity, every signature uses two-factor authentication, and the application passes a third-party audit or DEA-approved certification before use and at least every two years. A controlled substance e-prescription from non-compliant software is not a valid prescription. On Cuvo, EPCS is included on Grow, Enterprise and Cuvo Prescribe, with every prescriber's DEA registration verified.

**Q: How do telehealth companies send prescriptions to compounding pharmacies?**

A: A licensed provider writes a patient-specific prescription, and it is sent electronically to a compounding pharmacy licensed for the patient's state, which compounds it for that patient under section 503A and ships it, cold where required. The prescription follows the provider's decision, never the brand's checkout. On Cuvo, approved prescriptions route to one of 17 partner pharmacies licensed for the destination state and operating within current rules for the molecule, and the brand follows each order through events and tracking.

**Q: What is the best pharmacy API for a telehealth brand?**

A: Cuvo Health. It covers all three layers a prescription needs from one integration: 300+ board-certified providers licensed in all 50 states decide each case, prescriptions go out on the Surescripts network with EPCS on Grow and above, and 17 partner pharmacies ship with cold-chain delivery and lot tracking. The OpenAPI 3.1 contract, signed webhooks and sandbox are public at developers.cuvo.co, and pricing is published: $25 per completed consult, 0% medication markup and no revenue share.

**Q: What is Surescripts?**

A: Surescripts is the national e-prescribing network that connects prescribers' EHR and e-prescribing software with pharmacies, PBMs and health plans, and it reports 2.64 billion e-prescriptions filled in 2025. Prescriptions on it follow NCPDP SCRIPT transactions such as NewRx, RxRenewal, RxChange and CancelRx, and every participant passes a Surescripts certification before joining. On Cuvo, e-prescribing runs on the Surescripts network on every plan, so a brand's prescriptions use it without the brand connecting to it.

**Read next**
- [Telehealth API](/telehealth-api): The Cuvo Integrations API, resource by resource
- [Pharmacy and e-prescribing](/pharmacy): 17 partner pharmacies at 0% markup
- [Developer portal](/developers): The cuvo.co site API, MCP and agent access
- [GLP-1 pharmacy fulfillment in 2026](/blog/glp1-fulfillment-pipeline): Routing, compounding rules and cold chain
- [503A vs 503B compounding](/blog/compounding-503a-vs-503b): Which pharmacy category fills what
- [DEA telemedicine rules in 2026](/blog/dea-telemedicine-flexibilities-2026): Controlled substances by telehealth
- [The 50-state provider network](/provider-network): 300+ board-certified MDs, NPs and PAs
- [Pricing](/pricing): API access by plan, every fee published

**Sources**
- [E-Prescribing](https://surescripts.com/products/e-prescribing): Surescripts: certification before joining, message validation, transactions, 2.64 billion e-prescriptions in 2025
- [E-Prescribing for Controlled Substances](https://surescripts.com/products/e-prescribing-for-controlled-substances): Surescripts: EPCS third-party audit requirement
- [The Surescripts Network Alliance](https://surescripts.com/why-surescripts/network-alliance): Surescripts: who sends and receives on the network
- [Access to Standards: SCRIPT](https://standards.ncpdp.org/Access-to-Standards.aspx): NCPDP: what the SCRIPT standard covers
- [Who we are](https://www.ncpdp.org/Who-We-Are.aspx): NCPDP: ANSI-accredited standards developer
- [21 CFR part 1311, requirements for electronic orders and prescriptions](https://www.ecfr.gov/current/title-21/part-1311): eCFR, current as of September 30, 2026
- [21 CFR 1311.105, identity proofing](https://www.ecfr.gov/current/title-21/section-1311.105): eCFR
- [21 CFR 1311.115, two-factor authentication](https://www.ecfr.gov/current/title-21/section-1311.115): eCFR
- [21 CFR 1311.300, third-party audits or certifications](https://www.ecfr.gov/current/title-21/section-1311.300): eCFR
- [Electronic Prescriptions for Controlled Substances (EPCS)](https://www.deadiversion.usdoj.gov/ecomm/ecomm.html): DEA Diversion Control Division
- [Electronic Prescriptions for Controlled Substances, interim final rule (75 FR 16236)](https://www.federalregister.gov/documents/2010/03/31/2010-6687/electronic-prescriptions-for-controlled-substances): DEA, March 31, 2010; effective June 1, 2010
- [42 CFR 423.160, standards for electronic prescribing](https://www.ecfr.gov/current/title-42/section-423.160): eCFR, Medicare Part D
- [45 CFR 170.205, content exchange standards](https://www.ecfr.gov/current/title-45/section-170.205): eCFR, SCRIPT versions 2017071 and 2023011
- [21 U.S.C. 353, exemptions and consideration for certain drugs](https://www.law.cornell.edu/uscode/text/21/353): Prescription by a practitioner licensed by law
- [21 U.S.C. 353a, pharmacy compounding](https://www.law.cornell.edu/uscode/text/21/353a): Section 503A
- [21 U.S.C. 353b, outsourcing facilities](https://www.law.cornell.edu/uscode/text/21/353b): Section 503B
- [Cuvo Integrations API: getting started](https://developers.cuvo.co/docs/getting-started): Sample case request
- [Cuvo Integrations API: cases](https://developers.cuvo.co/docs/cases): Prescriptions, orders and statuses
- [Cuvo Integrations API: test mode](https://developers.cuvo.co/docs/test-mode): Sandbox decision, ship and deliver
- [Cuvo Integrations API: webhooks](https://developers.cuvo.co/docs/webhooks): Signatures, retries and redelivery
- [Cuvo Integrations API: events and realtime](https://developers.cuvo.co/docs/events-and-realtime): Event shape and catalog
- [Cuvo Integrations API: OpenAPI 3.1 contract](https://developers.cuvo.co/docs/openapi.yaml): Order, Prescription, Medication and Pharmacy schemas

*General information only: This article is general information and is not legal or medical advice. Prescribing, EPCS and pharmacy licensing rules vary by state and change over time. Every clinical decision is made solely by the treating licensed provider, who practices through a physician-owned professional entity; Cuvo provides the administrative, technology and operational infrastructure around that entity and does not practice medicine. Controlled substances are prescribed only where state and federal rules permit. API facts are as published at developers.cuvo.co on October 1, 2026, and the code samples use sandbox data. Surescripts and NCPDP facts come from their public websites as of October 1, 2026; their trademarks belong to their owners, who do not endorse this article. Delivery times are typical, not guaranteed.*

Canonical page: https://cuvo.co/blog/pharmacy-api-e-prescribing-surescripts