If you build software for health systems, you have probably hit a wall trying to figure out where a payer's FHIR endpoints actually live. The CAQH Endpoint Directory exists to solve exactly that problem, and if you have never used it, the whole process of endpoint discovery can feel like guesswork instead of engineering.

In short, the CAQH Endpoint Directory is a centralized registry where health plans publish their FHIR API endpoints so that providers, vendors, and app developers can find and connect to them without chasing down documentation from dozens of separate payer websites. It supports the interoperability rules that require payers to expose patient access and provider directory APIs, and it gives developers a single, structured source to validate endpoint URLs before wiring up an integration.

This article walks through what the directory actually contains, how the publishing and lookup process works from both the payer and vendor side, and where it fits into the broader FHIR and EPIC integration workflow. If you are building SMART on FHIR apps that need to talk to real-world payer data, understanding this directory will save you time you'd otherwise spend debugging connections that were never configured correctly in the first place.

Why the CAQH Endpoint Directory matters for healthcare organizations

Meeting the interoperability mandate

Regulators didn't leave FHIR endpoint publishing optional. The CMS Interoperability and Patient Access rule requires most payers to expose Patient Access and Provider Directory APIs, and the CMS interoperability guidance makes clear that a discoverable, public FHIR endpoint list is part of compliance, not a nice-to-have. Health plans that skip this step risk audits and enforcement action, so the directory gives them a standard, recognized place to satisfy that obligation instead of scattering endpoint documentation across marketing pages that change without notice.

Without a shared registry, every payer integration becomes a scavenger hunt instead of a repeatable engineering task.

Avoiding the discovery bottleneck

Vendors feel the pain from the other direction. Before the directory existed, engineering teams burned real hours emailing payer contacts, scraping developer portals, and guessing at base URLs that changed every few months. That wasted time translates directly into slower go-live dates and frustrated health system partners waiting on an integration that should take days, not weeks.

Here's the difference the directory makes in practice:

Securely centralizing this information also protects patients. When endpoints live in one governed registry instead of dozens of ad hoc listings, there's less chance a developer connects to a stale or spoofed URL and pulls data through the wrong channel. For organizations building SMART on FHIR apps that touch protected health information, that reliability isn't a convenience, it's a baseline requirement for staying compliant while moving fast.

How the CAQH Endpoint Directory works

The CAQH Endpoint Directory functions as a managed database rather than a static list. Health plans submit their FHIR base URLs, authorization endpoints, and metadata directly to CAQH, which validates the submission before it goes live. Once published, the record becomes searchable by anyone building an integration, whether that's a hospital system's IT team or a third-party app vendor connecting through EPIC's App Orchard.

A directory only works if the data inside it stays current, and that responsibility sits with the payer, not the developer pulling from it.

Who keeps the records current

Ownership matters here. Each payer designates a technical contact responsible for updating their listing whenever an endpoint changes, whether that's a new subdomain, a revised OAuth token URL, or a version bump in their FHIR implementation. CAQH doesn't generate these records on its own; it hosts and structures what payers submit, so the accuracy of any given listing depends entirely on how diligently that payer maintains it.

What a record actually contains

A typical entry gives developers everything needed to start an integration without a support ticket:

• Base FHIR API URL
• OAuth 2.0 authorization and token endpoints
• Supported FHIR version (usually R4)
• Patient Access and Provider Directory API availability
• Organization identifiers tying the record to a specific payer

That structure is what turns endpoint discovery into a repeatable lookup instead of a one-off research project for every new payer connection.

How to find, publish, and validate endpoints in the directory

Locating a payer's FHIR endpoint through the CAQH Endpoint Directory takes a few clicks once you know where to look, but the process differs depending on whether you're searching for an existing listing or submitting a new one. The directory search tool lets you filter by payer name, organization ID, or state, which cuts through the noise when a health plan operates under multiple brand names or regional subsidiaries.

Searching and validating an existing listing

Before wiring an integration into your app, run through this checklist:

• Confirm the base FHIR URL resolves and returns a valid CapabilityStatement.
• Check the listed FHIR version matches what your app expects, usually R4.
• Verify the OAuth token endpoint against the payer's own published documentation.
• Note the last-updated date; a stale record is a signal to reach out to the payer directly.

An endpoint that looks correct on paper still needs a live test call before you trust it in production.

Publishing or updating a payer listing

Payers submit new or revised endpoints through CAQH's provider portal, where a designated technical contact enters the base URL, authorization details, and supported API scopes. CAQH reviews each submission for completeness before it goes live, so updates typically take a few business days to appear rather than showing up instantly. Getting this step right matters just as much for compliance as it does for the vendors depending on an accurate CAQH Endpoint Directory listing to build a working connection.

What the directory means for FHIR app developers and vendors

For vendors building SMART on FHIR apps, the CAQH Endpoint Directory turns endpoint discovery from a research project into a checklist item. Instead of budgeting engineering time to track down every payer's base URL, your team can pull a validated record, confirm the FHIR version, and start building the connection the same day. That shift matters most for teams juggling dozens of payer integrations at once, where manual lookup simply doesn't scale.

Fewer surprises during integration

Access to a standardized source of truth cuts down on the failure modes that eat up sprint time: wrong OAuth scopes, outdated token URLs, or a base endpoint that quietly moved months ago. Developers can cross-check the directory listing against a live CapabilityStatement call before writing a single line of integration code, catching mismatches early instead of during a health system's go-live window.

A directory entry that's easy to verify saves a developer from finding out an endpoint is broken in front of a client.

Faster path to health system contracts

Vendors that lean on the directory also move faster through procurement. Health systems evaluating a new app want proof the vendor already understands payer-side FHIR requirements, and a clean, verifiable connection built from directory data signals exactly that. It's one less technical question standing between a demo and a signed contract, which matters when every week of delay costs a vendor real revenue.

Putting the directory to work for your integrations

The CAQH Endpoint Directory turns what used to be a scavenger hunt into a repeatable step in your integration workflow. Once you know how payers publish and maintain their FHIR endpoints, you can validate a connection in minutes instead of chasing down documentation for weeks. That's the whole point: less guesswork, fewer broken connections, faster go-live dates with the health systems you're trying to win.

Knowing where the endpoints live is only half the job, though. Building the actual SMART on FHIR app, handling EPIC's submission process, and keeping everything HIPAA and SOC2 compliant still takes real engineering time if you go it alone. That's exactly the gap VectorCare closes. Instead of spending months wiring up connections your team has to maintain forever, you can build and deploy your SMART on FHIR app in days and get straight to the part that actually grows your business.