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 minPublic APIPublic source
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
Overview
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
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
An NPI or provider details arrive from your existing queue, file, form, or system
Delivered to your credentialing queue
The confirmed registry record lands in your roster, EHR, API, or webhook, ready to feed exclusion, license, and enrollment checks downstream.
Multiple or no confident match: Every candidate returns with its full record and the reason; a person confirms identity once, and the NPI carries forward.
Closing the loop
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" } ]}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, the state Medicaid 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.
At scale
A single run resolves one identity. As a program, the lookup runs at the front of onboarding and the monthly screening pass, roster in, one registry record per provider out, so everything downstream starts from a confirmed identity instead of a spelling. Identity resolution is part of the credentialing and verification workflow library. And when the lookup finds a stale record, the NPPES registration and update workflow is the write half that fixes it.
Human in the loop
Lookups read a public registry, and runs still execute on SOC 2 Type II, HIPAA-compliant infrastructure with a per-run record of what was queried. Posture on the security page.
Multiple matches that filters can’t resolve.
All candidates are returned with their records; a person picks, once, and the NPI carries forward.
A deactivated NPI.
Reported as the registry shows it; what it means for the provider’s status is a decision, not an inference.
An API failure.
An explicit error, never a silently empty record.
Questions
The NPI lookup is one workflow in the credentialing and verification workflow library. Every screening pass that starts from a spelling instead of a confirmed identity risks checking the wrong person, and every downstream check inherits the error.
Disclaimer
Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.