NEWMedicare Advantage 2027 plans are live in the API.Read the changelog
GUIDE

Build or buy provider network data.

Build your own pipeline if network data is your product, or if you need one or two insurers and have engineers to keep it running. Buy if you need many insurers or both markets, and would rather spend engineering time on the product your customers pay for.

What building involves

Insurers publish provider directories, and many publish them as files that code can read. That makes building possible. It does not make it small. A pipeline that answers "is this provider in this plan?" needs at least these parts:

  1. Discovery. Find where each insurer publishes each directory, for each plan year, and notice when the location changes.
  2. Reading. Download and parse files that differ by insurer in structure, size and quality. Large national insurers publish very large files; small regional plans publish small ones that break in their own ways.
  3. Plan mapping. Tie each network in a directory to the plan IDs your users actually hold, for the right plan year. The plan a member sees and the network a directory describes are not always labelled the same way.
  4. Provider matching. Match listings to providers by NPI, and enrich them with names, credentials, specialties and practice locations from public provider registries.
  5. Dating and storage. Keep the date of every read, keep plan years apart, and store a very large number of rows. InPlan holds more than 650 million provider-plan links today.
  6. Re-reading and monitoring. Directories change during the year. Re-read on a schedule, and catch the run that quietly loads nothing because a file moved or changed shape.
  7. Serving. Answer per-provider and per-plan questions fast, with clear semantics for "not found".

The cost is in keeping it running

The first working version is the cheap part. The lasting cost is maintenance: every insurer is a separate integration that can break on its own schedule, and every plan year brings new plan IDs. A pipeline that worked in spring can serve stale answers in autumn without any error, because nothing failed loudly. If you build, budget for monitoring that checks each run produced real rows, not just that the job finished. For part by part effort ranges, see build vs buy, the effort compared.

There is also a cost to getting it wrong in front of users. Telling someone their doctor is in network when the directory no longer lists them is worse than saying you do not know. Whatever you build needs a deliberate meaning for a missing listing.

A quick way to decide

Build or buy, by situation
SITUATIONIF YOU BUILDIF YOU BUY
You need one or two insurers, in one stateBuilding is realisticBuying saves the first months
You need many insurers, or both marketplace and Medicare AdvantageA standing data teamOne integration
Answers must carry a source and a read dateYou design and store itCheck the vendor returns it
You need whole networks for analysis, not single checksBulk storage and joinsData files by state
Network data is your core productBuild: it is your moatBuy only to start faster

What to ask any vendor, including us

  1. Which insurers, plans and states do you hold? Ask for it by name, for your markets. Ours are on the insurer pages, the state pages and coverage.
  2. Does every answer carry a read date and a source type? If not, you cannot tell a user how current an answer is.
  3. How is "not found" returned? An answer of "no" for a plan whose directory was never read is a wrong answer.
  4. Are plan years kept apart? A listing for next year's plan is not a listing for this year's.
  5. Can you test before you pay? Real answers for providers you know are the fastest due diligence.

Test us in two calls

Before deciding, look up providers you know. The first call below returns a provider and a summary of what we hold for them; the second lists the insurers and plan counts we hold in a market and state.

RequestGET /v1/providers/{npi} and /v1/coverage
# what do we hold for a provider?
curl -H "Authorization: Bearer $INPLAN_KEY" \
  "https://api.inplan.io/v1/providers/1376006148"

# which plans and insurers do we hold in a market and state?
curl -H "Authorization: Bearer $INPLAN_KEY" \
  "https://api.inplan.io/v1/coverage?market=aca&state=NC"
Part of the first responseNPI 1376006148, family practice, North Wilkesboro NC
"plan_summary": {
  "aca": { "plans": 199, "issuers": 8, "states": ["GA", "NC", "SC", "TN"],
           "plan_years": [2025, 2026, 2027], "as_of": "2026-10-29" },
  "ma":  { "plans": 146, "organizations": 4, "accepting_new_patients_any": true,
           "as_of": "2026-10-29" }
}

That one family physician is listed in 199 marketplace plans from 8 insurers and 146 Medicare Advantage plans from 4 organizations. Multiply by every provider your users care about, and the scale of a home-built pipeline becomes clear.

What buying costs here

InPlan has a free tier with 500 calls a month and no credit card. Builder is $199 a month for 25,000 calls and adds batch checks of up to 100 pairs per call. Growth adds the providers-in-a-plan call. For analysis rather than single checks, a state data file holds every provider in a state with every plan that lists them. Full details are on the pricing page.

A sensible path for many teams: start on the free tier, check the providers and plans that matter to you, and only then decide whether to build, buy, or buy first and build later.

TRY IT

Run these calls yourself.

The examples on this page use playground providers, so you can run them in the browser with no key. A free key gives 500 calls a month against the full data.