NPI Registry Lookup — Deactivated vs Never-Issued Check

Batch NPI registry lookup that returns a verdict instead of a silence.

Submit a list of NPIs. Every one comes back resolved into one of four states:

Verdict	Meaning
ACTIVE	Live in the NPPES registry, returned with name, entity type, credential, primary taxonomy, licence number and state, and practice location
DEACTIVATED	CMS deactivated this NPI — returned with the CMS deactivation date
NEVER_ISSUED	Structurally a valid NPI, but CMS has never issued it and never deactivated it
INVALID_FORMAT	Not a possible NPI: fails the 80840-prefixed check digit, or is not ten digits

Why this needs two sources

CMS does not flag a deactivated NPI in the registry API. It removes it.

That single fact is why an NPI lookup built on the registry API alone cannot answer the question buyers actually have. Two consequences follow, and both are measurable against the source:

1. basic.status is a constant. Sampled 1,400 live NPPES API records on 2026-08-06: 1,400 of 1,400 return "A". A status column fed by that endpoint is structurally incapable of ever saying anything else.
2. The API's answer for a deactivated provider is silence — result_count: 0, byte-identical to its answer for a number that was never issued at all.

You can check this yourself without running anything. These NPIs are in the CMS Monthly NPI Deactivation File:

NPI	CMS deactivation date
1982883625	2023-11-29
1366509945	2020-08-17
1003027293	2016-02-01

Query any of them against https://npiregistry.cms.hhs.gov/api/?version=2.1&number=1982883625 and you get {"result_count": 0, "results": []} — no reason, no date, and exactly the same response as an unissued number.

This Actor joins the registry API to the CMS deactivation file (349,557 rows as of 2026-07-13, published monthly on a different host) so the difference is visible. That difference is not academic:

• Submitting a claim under a deactivated NPI is a hard denial — remediation is re-credentialing or a corrected claim.
• A never-issued NPI in your file is a data-entry error — remediation is fixing the number.
• Credentialing a provider against a deactivated NPI is a payer-audit finding.

Input

{
  "npis": ["1366148975", "1982883625", "1003027293", "1234567890"]
}

Up to 5,000 NPIs per run. Spaces, dashes and stray punctuation are stripped, so you can paste straight out of a claims file or a credentialing export.

Output

One row per NPI:

{
  "inputValue": "1982883625",
  "npi": "1982883625",
  "verdict": "DEACTIVATED",
  "isActive": false,
  "deactivationDate": "2023-11-29",
  "checkDigitValid": true,
  "guidance": "CMS deactivated this NPI. It is absent from the registry API entirely -- claims submitted under it will deny and credentialing against it will not stand up to a payer audit.",
  "providerName": null,
  "entityType": null,
  "primaryTaxonomy": null,
  "licenseNumber": null,
  "licenseState": null,
  "city": null,
  "state": null,
  "checkedAt": "2026-08-06T06:15:59+00:00",
  "deactivationFileAsOf": "2026-07-13",
  "deactivationFileRows": 349557
}

An ACTIVE row carries the provider detail instead: providerName, entityType, credential, enumerationDate, lastUpdated, primaryTaxonomy, primaryTaxonomyCode, licenseNumber, licenseState, city, state, postalCode.

Every row states deactivationFileAsOf — the CMS file's own as-of date — so you always know the vintage of the answer rather than having to assume it.

Reactivation

An NPI that was deactivated and later reactivated is live in the registry and present in the cumulative CMS file. Those rows come back ACTIVE with previouslyDeactivated: true and priorDeactivationDate set — the registry wins, and the history is surfaced beside it rather than silently dropped.

Freshness — the run aborts rather than guessing

The CMS deactivation file is published monthly and its filename embeds a date, so it has to be discovered from the CMS index page. If that discovery or the file itself looks wrong, the run fails loudly and returns no rows. It never degrades into "no deactivations found", because every one of these failures would silently reclassify deactivated NPIs as never issued:

• no deactivation ZIP link on the CMS index page
• header row is not exactly NPI / NPPES Deactivation Date
• fewer than 300,000 data rows (the file is cumulative since 2005 and never shrinks)
• the file's own as-of date is more than 75 days old — two fully missed monthly releases

A wrong answer delivered confidently is worse than no answer.

Sources

Both are keyless US federal public-domain data:

• NPPES registry API v2.1 — https://npiregistry.cms.hhs.gov/api/
• CMS Monthly NPI Deactivation File — https://download.cms.gov/nppes/NPI_Files.html

No API key, no account, no scraping of a login-gated site.

Pricing

Pay per event:

• Deactivation file load — once per run, covering the download and indexing of the full CMS deactivation file. Charged only once the file is in hand, so an aborted run costs you nothing.
• NPI checked — per NPI checked against the registry. NPIs rejected on the check digit alone are not charged.