Health Provider API
Provider validation for healthtech onboarding

Validate provider records before they enter your system.

Confirm NPIs against the official US registry, normalize fields for onboarding and rosters, and trace every check with request IDs—the same NPPES source of truth without hand-parsing raw JSON.

Get free API keyDocs quickstart

Free tier: 100 lookups / month, 1 API key, no credit card. See pricing

No credit card on free tierOpenAPI specPostman collectionUS NPI Registry (NPPES) source dataNPI-1 and NPI-2

Request

GET /api/v1/npi/{npi}

Live API
curl -sS -H "Authorization: Bearer YOUR_API_KEY" "https://healthproviderapi.com/api/v1/npi/1003000126"

Response (sample)

Registry status, entity type, taxonomy, and request ID—ready for onboarding rules.

{
  "data": {
    "npi": "1003000126",
    "entityType": "NPI-1",
    "status": "active",
    "name": {
      "full": "JOHN SMITH, M.D.",
      "first": "JOHN",
      "middle": null,
      "last": "SMITH",
      "prefix": null,
      "credential": "M.D."
    },
    "primaryTaxonomy": {
      "code": "208M00000X",
      "description": "Hospitalist",
      "state": "DC",
      "license": "MD600003480"
    },
    "taxonomies": [
      {
        "code": "208M00000X",
        "description": "Hospitalist",
        "state": "DC",
        "license": "MD600003480"
      }
    ],
    "mailingAddress": {
      "street": "123 EXAMPLE MEDICAL PLZ",
      "city": "WASHINGTON",
      "state": "DC",
      "zip": "20001",
      "country": "US"
    },
    "practiceLocations": [
      {
        "street": "456 CLINIC AVE",
        "city": "ARLINGTON",
        "state": "VA",
        "zip": "22201",
        "country": "US"
      }
    ],
    "enumerationDate": "2007-08-31",
    "lastUpdated": "2026-05-01",
    "source": {
      "name": "NPPES",
      "version": "2.1"
    }
  },
  "meta": {
    "requestId": "req_public_demo",
    "cached": true
  }
}
Example

What validation looks like in your onboarding flow

Your form may collect display name and state for UX; authoritative validation is a registry lookup by NPI. NPI issuance does not prove licensure or credentialing—your team remains responsible for clinical and legal checks.

Form vs API call

# Collected in your onboarding form (your app)
NPI: 1003000126
Display name: John Smith
Practice state: TX

# Sent to the API (registry lookup)
GET /api/v1/npi/1003000126

Official NPPES vs Health Provider API · Branch on data.status, data.entityType, and data.primaryTaxonomy in your rules.

Request (Growth+ enrichment)

Header enrichment: quality_freshness

curl -sS -H "Authorization: Bearer YOUR_API_KEY" -H "enrichment: quality_freshness" "https://healthproviderapi.com/api/v1/npi/1003000126"

Response (OpenAPI sample)

Demo NPI 1003000126—includes data.enrichment and meta.enrichment.nonVerification.

{
  "data": {
    "npi": "1003000126",
    "entityType": "NPI-1",
    "status": "active",
    "name": {
      "full": "JOHN SMITH, M.D.",
      "first": "JOHN",
      "middle": null,
      "last": "SMITH",
      "prefix": null,
      "credential": "M.D."
    },
    "primaryTaxonomy": {
      "code": "208M00000X",
      "description": "Hospitalist",
      "state": "DC",
      "license": "MD600003480"
    },
    "taxonomies": [
      {
        "code": "208M00000X",
        "description": "Hospitalist",
        "state": "DC",
        "license": "MD600003480"
      }
    ],
    "mailingAddress": {
      "street": "123 EXAMPLE MEDICAL PLZ",
      "city": "WASHINGTON",
      "state": "DC",
      "zip": "20001",
      "country": "US"
    },
    "practiceLocations": [
      {
        "street": "456 CLINIC AVE",
        "city": "ARLINGTON",
        "state": "VA",
        "zip": "22201",
        "country": "US"
      }
    ],
    "enumerationDate": "2007-08-31",
    "lastUpdated": "2026-05-01",
    "source": {
      "name": "NPPES",
      "version": "2.1"
    },
    "enrichment": {
      "version": "v1",
      "factors": [
        "completeness",
        "quality_score",
        "freshness"
      ],
      "dataQuality": {
        "score": 100,
        "completeness": {
          "hasName": true,
          "hasPrimaryTaxonomy": true,
          "hasMailingAddress": true,
          "hasPracticeLocation": true
        }
      },
      "freshness": {
        "lastUpdated": "2026-05-01",
        "enumerationDate": "2007-08-31",
        "daysSinceLastUpdated": 32,
        "band": "recent"
      }
    }
  },
  "meta": {
    "requestId": "req_public_demo",
    "cached": true,
    "enrichment": {
      "requested": [
        "completeness",
        "quality_score",
        "freshness"
      ],
      "applied": [
        "completeness",
        "quality_score",
        "freshness"
      ],
      "creditCost": 2,
      "nonVerification": true
    }
  }
}
The pain

Dirty provider data is expensive—raw NPPES does not fix it alone

The official registry is authoritative, but onboarding teams need validated, normalized records—not another parser in every service.

  • Onboarding and roster flows ingest bad NPIs, stale statuses, and inconsistent names before anyone notices.
  • Raw NPPES is the source of truth—but not shaped for product teams validating providers in production.
  • Each service rebuilds parsers, auth, caching, and audit trails instead of one validation path the org can trust.

What you get instead

  • Registry-backed validation

    Confirm format, active/deactivated status, entity type, and primary taxonomy in one call—same official data, normalized for your workflow.

  • Onboarding, rosters, and directories

    Lookup, directory search, and bulk reconciliation share one schema so enrollment, credentialing, and directory sync do not fork parsers.

  • Traceable checks and ops

    Request IDs, cache metadata, quotas, and documented errors—so support and compliance can follow what was validated and when.

Get free API keyDocs quickstart
Why onboarding teams use it

Provider data quality on top of the official registry

Validate and normalize NPI-backed records for enrollment, rosters, and directories—with lookup, search, bulk, and traceable request metadata.

Validate before you store
Catch invalid or deactivated NPIs at enrollment with explicit registry status, entity type, and taxonomy fields your rules can branch on.
Normalized provider records
Stable JSON for individuals and organizations—usable in onboarding UIs, rosters, and directories without NPPES field archaeology.
Audit-friendly metadata
Every response includes a request ID plus cache and quota signals—easier support and operational review than raw registry calls alone.
Lookup, search, and bulk
Direct NPI validation, name/location search for typeahead, and batch lookup for roster reconciliation under one API key.
Get started

Three steps to your first lookup

Sign up, create a key in the dashboard, and call the API—the same path documented in our quickstart.

  1. 1

    Create your account

    Sign up in under a minute. No credit card on the free tier.

  2. 2

    Generate an API key

    Open the dashboard and create a Bearer token for your app or internal tool.

  3. 3

    Make your first call

    Look up an NPI or run a provider search and return clean provider data right away.

Funnel: sign up → dashboard API keys → Authorization: Bearer

Get free API keyDocs quickstart
Use cases

Where healthtech teams plug it in

Same NPI Registry API for patient-facing apps and back-office tools—telehealth onboarding, credentialing, billing, and provider directories.

Provider onboarding
Validate NPIs at enrollment with search-as-you-type and normalized registry fields.
Explore use case →
Credentialing
Validate NPIs, map roster data, and reduce manual cleanup in credentialing workflows.
Explore use case →
Provider directory
Power in-app search and nightly sync with lookup, search, and bulk reconciliation.
Explore use case →
Billing and RCM
Resolve provider and organization NPIs for claims prep, payer tools, and revenue workflows.
Explore use case →
Telehealth
Check clinician identity during onboarding and keep provider directories in sync.
Explore use case →
API surface

NPI lookup and provider search in one product

High-intent endpoints documented in OpenAPI—lookup by NPI, search by name and location, bulk refresh for directories.

What the response gives you
Structured fields your app can render or store without parsing NPPES.

data includes NPI, entity type, status, provider name, and primary taxonomy—already normalized for product screens and workflows.

meta exposes cache status and a request ID for support and tracing.

Also in the contract

  • GET /api/v1/providers/search for provider search
  • Published docs for request and response fields
  • NPI lookup and directory search share one monthly quota: 1 credit per lookup HTTP 200 or 404 (not found); 1 credit per search HTTP 200; upstream 502 errors do not bill. Enrichment requests cost 2 credits (Growth+).
Free tier

Start free, upgrade when volume grows

100 lookups / month and 1 API key—enough to wire your integration and run real tests before you pick a paid plan.

Get free API keyDocs quickstart
Which should I use?

Official NPPES vs Health Provider API

You can use the official NPI Registry directly. Health Provider API is for teams that need clean provider records in production—normalized fields, traceable validation, roster workflows, and a stable OpenAPI contract on top of the same NPPES source of truth.

Use official NPPES directly if…Use Health Provider API if…
You need occasional lookupsYou need clean provider records in production
You maintain your own NPPES parserYou want normalized fields and a stable OpenAPI contract
You do not need audit trailsYou need traceable validation (request IDs, dashboard usage)
You do not need bulk or roster workflowsYou validate onboarding data or reconcile provider rosters in bulk
You own refresh and change-detection logicYou want enrichment signals today; directory change monitoring is on the roadmap

Same CMS source of truth. Choose us when you need production-ready provider records, not another NPPES parser per service.

Full comparison guide
FAQ

Common questions from engineering teams

Straight answers about data source, search, free tier limits, and what this API does not replace.

Why not use the official NPI Registry API?
You can use the official NPI Registry directly. Health Provider API is for teams that need clean provider records in production—normalized fields, traceable validation, roster workflows, and a stable OpenAPI contract on top of the same NPPES source of truth. Which should I use: official NPPES vs Health Provider API?.
What is this API and where does the data come from?
Health Provider API helps healthtech teams validate and normalize provider records from the official US NPI Registry (NPPES)—for onboarding, rosters, and directories—with Bearer auth, stable JSON, search, bulk lookup, request IDs, and documented quotas.
Is this an NPPES alternative?
Same NPPES source of truth—not a replacement registry. Health Provider API is a product layer for validating and normalizing provider records in onboarding, rosters, and directories, with Bearer auth, stable JSON, request IDs, search, and bulk lookup.
Can I search by provider name or location?
Yes. In addition to direct NPI lookup, you can use provider directory search by name, organization, and location. That makes it useful for telehealth, credentialing, and provider directory features.
Do I need a credit card to test it?
No. The free tier includes 100 lookups / month and 1 API key with no credit card required. You can upgrade later if your usage grows.
Is this a replacement for clinical or legal verification?
No. NPI issuance does not prove licensure or credentialing. This API helps you validate and normalize official registry data; your team remains responsible for compliance, legal review, and clinical verification in your workflow.

Stop bad provider records at the front door

Free tier for healthtech teams—sign up, create a key, and validate your first NPI against the official registry today.

Get free API keyView pricing