Connecting a custom EHR to Surescripts is a certification project, not an API integration. There is no public Surescripts developer portal and no self-serve API key — access is granted through Surescripts’ partner process, and the software must pass conformance testing against the NCPDP SCRIPT standard for the transaction types it will use: NewRx, RefillRx, CancelRx and ChangeRx at minimum, plus RTPB if you’re surfacing real-time benefit information. If the product will prescribe controlled substances, EPCS adds a separate DEA-mandated third-party audit of the application’s identity-proofing, two-factor authentication and logging before it can go live. Certification is measured in weeks to months rather than days, which means the sequencing decision matters more than the engineering one: teams that start the certification track in parallel with development ship on schedule, and teams that treat it as a final step discover a multi-month delay after the product is otherwise finished.

Why There Is No Surescripts API You Can Just Sign Up For

I’ll say the blunt version first, because it’s the answer most people building toward this are actually looking for: you cannot go find Surescripts’ developer docs, register for an API key, and start sending prescriptions this afternoon. That’s not how the network works, and if a vendor’s sales page implies otherwise, be skeptical of everything else on the page too.

The reason is scale and sensitivity, not bureaucracy for its own sake. Surescripts’ network reaches 2.32 million healthcare professionals and provider organizations, connecting nearly every EHR vendor, pharmacy benefit manager, pharmacy and clinician in the country. A single bad actor or a poorly built integration touching that network doesn’t just break one connection — it’s a risk surface across essentially the entire U.S. prescribing infrastructure, including controlled substances. Gating access through a certification process rather than an open API is the tradeoff that makes the network trustworthy enough for every other participant to rely on it.

What You Are Actually Certifying Against: NCPDP SCRIPT

The standard underneath all of this is NCPDP SCRIPT, and what you’re really certifying is your software’s correct implementation of a specific set of message types moving between prescriber and pharmacy:

  • NewRx — sent prescriber to pharmacy, creating a new prescription: patient, prescriber, medication, dosage, SIG, quantity, days’ supply, fill number.
  • RefillRx — a request/response pair: the pharmacy asks for authorization to refill, the prescriber responds.
  • CancelRx — a request to cancel a prescription before it’s dispensed, with confirmation from the other side. This one moves at real volume — Surescripts logged 277.8 million CancelRx requests in 2025 alone.
  • ChangeRx — modifying an existing prescription rather than cancelling and re-issuing.
  • RTPB (Real-Time Prescription Benefit) — a newer piece, formalized under HHS’s HTI-4 rule, that surfaces actual cost and coverage information to the prescriber at the moment of prescribing rather than leaving the patient to discover it at the pharmacy counter. In 2025, over 900,000 prescribers used RTPB a combined 1 billion times, saving patients an estimated $55.1 million.

Notice that SCRIPT and RTPB are doing different jobs — SCRIPT moves the prescription itself, RTPB moves pricing and coverage intelligence. A lot of vendor content blurs the two together. Don’t build your architecture, or your certification scope, assuming they’re the same thing.

The Certification Path, Step by Step

This is the part most competing content skips past in a sentence, so it’s worth being the most detailed section here. The path runs roughly: partner engagement with Surescripts, conformance testing against the specific transaction set your product needs, and then production credentials once testing passes. What that actually means day to day is a documentation-heavy process — proving your implementation handles the message formats correctly, handles error and edge cases the way the standard expects, and doesn’t do anything that would put patient safety or prescription integrity at risk.

Realistic duration runs in the range of a couple of months, not days — and that’s before EPCS enters the picture, which adds its own timeline on top. Plan your product roadmap around that reality rather than around how long the actual API integration code would take to write, because the code is rarely the long pole.

EPCS: What Controlled Substances Add

If your product touches controlled substances at all, EPCS (Electronic Prescribing of Controlled Substances) is not an optional feature flag — it’s a set of DEA requirements under 21 CFR Part 1311 that reach into how your whole application is architected, and it’s worth building this in from the start rather than bolting it on later:

  • Identity proofing. Prescribers have to be identity-proofed to a real assurance standard — NIST SP 800-63-1 at Assurance Level 3 or higher, done by an approved Certification Authority, with government-issued photo ID and verified state prescribing authority. This isn’t a checkbox in your signup flow.
  • Two-factor authentication at the point of signing. Required under 21 CFR 1311.115, and it has to combine two genuinely distinct factor categories — something the prescriber knows, has, and/or is. A password plus a security question doesn’t satisfy this; a password plus a hard token or biometric does.
  • A third-party audit of the application itself. The software has to pass certification before it touches production, and EPCS systems require re-audit by a DEA-approved organization roughly every two years to keep operating.

That third point is the one that surprises teams: this isn’t a one-time gate. It’s a standing operational obligation, and it’s worth budgeting for it as a permanent line item rather than a launch cost.

How This Fits a Custom EHR Build

The practical sequencing advice is the same pattern that shows up everywhere in HIPAA-adjacent healthcare software: start the certification track on day one, in parallel with development, instead of treating it as the last box to check before launch. Kick off the Surescripts partner conversation and the EPCS identity-proofing setup while your team is still building the core charting and scheduling functionality. By the time the product itself is ready, certification has a real chance of being ready too — instead of becoming the thing that sits between a finished build and an actual launch date.

Pharmacy-Side Integration Is a Different Problem

Worth being precise about scope: everything above is the prescriber side — your EHR sending prescriptions out. Integrating with a pharmacy’s own management system on the dispensing side is a related but genuinely separate problem, with its own standards and its own certification questions. We’ve done integration work with PioneerRx specifically on that side, if that’s the connection you’re actually scoping.

What This Costs and What Drives It

The honest cost drivers, without pretending to a number that would be meaningless without knowing your specific scope: how many of the transaction types you need beyond the SCRIPT minimum, whether EPCS is in scope at all, and how much your existing architecture already resembles what certification expects versus how much has to be retrofitted. A team building identity proofing and two-factor auth in from the start pays less, in both time and money, than one bolting EPCS onto a product that assumed a simple username-and-password model.

Next Steps

E-prescribing is one of those requirements that looks like a feature on a product roadmap and turns out to be a compliance project with a software component. If you’re scoping a custom EHR build that needs to prescribe, the certification track should start the same week the engineering does, not after. Talk to our team about sequencing it — we’ve been through the Surescripts partner process, and we’d rather help you plan around the real timeline than let it surprise you three months in.