NPPES NPI Lookup Automation

Look up a provider or an organization in the NPPES NPI Registry and get the full registry record back as structured data: NPI, active or deactivated status, taxonomy, license detail, and every listed address. The identity step that every other credentialing check builds on.

Go-live in as little as 30 min·Public API·Public source

Overview

What this workflow does

One run resolves one provider’s identity against CMS’s registry, the free, public NPPES NPI Registry, via its API. Give it a 10-digit NPI for an exact match, or a name with optional state and provider-type filters to search. It covers organizations as well as individuals: an NPI-2 search by organization name returns the entity’s record the same way.

The result is the full registry record, not just a yes or no: enumeration type, active or deactivated status, the provider’s name and credential or the organization’s name, the primary taxonomy with its code, description, license number, and state, every listed address with its purpose and phone and fax, and any other identifiers the registry carries.

How Asteroid runs this workflow

From a name in your queue to a confirmed registry identity

A lookup request arrives from your system, Asteroid searches the NPPES registry and resolves the right provider, and the confirmed record lands back in your credentialing queue, with anything ambiguous routed to a person instead of guessed.

How it actually runs

1. The agent queries the public NPPES NPI Registry API directly: no browser session, no login, no credentials, no proxy. Nothing to provision at all.
2. A scripted fast path answers the lookup immediately; the AI takes over only if the script fails, so the common case is instant.
3. It runs the exact-NPI match when you have the number, or the name search with state and individual-or-organization filters when you don’t.
4. It classifies the result: found, not found, or multiple matches. The latter two are normal results, and a search narrowed by state and type usually resolves a multiple-match into a single record.
5. It maps the full record into structured output. Anything the registry doesn’t carry comes back null.

The confirmed registry record lands in your roster, EHR, API, or webhook, ready to feed exclusion, license, and enrollment checks downstream.

What lands back in your system

Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.

{
  "npi": "1•••••••93",
  "enumeration_type": "NPI-1",
  "status": "active",
  "name": {
    "first": "JANE",
    "last": "SAMPLE",
    "credential": "MD"
  },
  "primary_taxonomy": {
    "code": "207Q00000X",
    "description": "Family Medicine",
    "license": "•••482",
    "state": "TX"
  },
  "addresses": [
    {
      "purpose": "LOCATION",
      "line1": "1200 EXAMPLE PKWY STE 400",
      "city": "AUSTIN",
      "state": "TX",
      "postal_code": "78701",
      "phone": "512-•••-••04"
    }
  ]
}

Identity first. Screening second.

Exclusion lists and license boards are searched by name, and names collide. An exclusion check on the wrong John Smith is worse than no check at all, because it produces a clean record for a person you didn’t actually screen. Resolving the NPI first pins the identity, and every downstream check, the OIG exclusion check, the SAM.gov check, then runs with an NPI in hand to disambiguate whatever the name search returns.

There’s a second finding hiding in this lookup too: a deactivated NPI is its own answer, and it surfaces here before anything else is run.

Frequently asked questions

Our intake process is not identical to this template. What actually has to change?

Nothing on your side. The lookup is configured around your process: which inputs you send (a 10-digit NPI for an exact match, or a name with state and individual-versus-organization filters), which registry fields come back (status, primary taxonomy with license detail, addresses), the output format, delivery destination, and which results route to a reviewer. Your team keeps working in the systems they already use; the lookup arrives as a record in the queue, not a new screen. Configuration sits with Asteroid.

Do we need accounts, keys, or an integration before NPI lookups can run?

No. The agent queries the public NPPES NPI Registry API directly: no browser session, no login, no credentials, nothing to provision. Requests arrive however you already work: an API call, a spreadsheet, or roster rows, and structured records return via your API, webhooks, sheets, Slack, or email; a direct integration is an option, never a prerequisite. There are no source credentials to store or rotate.

What does the agent do when it cannot resolve an identity or the API fails?

It stops and classifies. Not-found and multiple-match come back as normal results with everything the registry showed; a search narrowed by state and type usually collapses a multiple-match into one record. A confirmed NPI then carries forward. An API failure ends as an explicit error, never a silently empty record. The agent never guesses an identity, and fields the registry does not carry come back null rather than invented.

How do we audit lookups and decide which results need human review?

Every run returns a structured record (enumeration type, active or deactivated status, taxonomy, license detail, addresses) with an echo of what was queried and a per-run log, visible in execution history. You set the review rules: most teams auto-accept clean single matches and pause only multiple-match and deactivated-NPI results for a reviewer. A deactivated NPI is a successful run reporting a business finding, not a failure; what it means for the provider's status is a decision your team makes.