State License Verification Automation

Verify a provider’s license against the state board’s own register: license status, issue and expiration dates, and any disciplinary actions, with an evidence screenshot of the board’s record. Primary-source verification, built board by board.

Go-live in as little as 30 min·Browser agent·Public source

Overview

What this workflow does

License verification is board-by-board work because the sources are board-by-board: roughly fifty state boards per profession, each with its own register, search flow, and status vocabulary. A browser agent runs the check a credentialing coordinator runs today: it opens the board’s own license search, finds the license, and reads the full record back, status normalized to active, expired, inactive, revoked, or suspended, plus the license number and type, issue and expiration dates, and the board’s disciplinary-action history.

The workflow is built per board and per license type, California RN today via the state’s DCA license search, and extended board by board the same way the state Medicaid exclusion coverage grows. A request for a board that isn’t built yet ends with a clear scoped error naming what’s supported, never a wrong answer.

How Asteroid runs this workflow

Fifty boards, one verified license record shape

A provider's identity, profession, and state enter the queue, Asteroid opens the right state board's own register, reads the full license record with its disciplinary history, and returns it normalized to your roster, with outages, ambiguous matches, and unexpected restrictions routed to your credentialing team.

How it actually runs

1. The agent opens the state board’s own license register, the primary source, not an aggregator’s copy of it. Board sites often sit behind bot protection, so the agent runs with a residential-proxy and captcha-solving profile, and it never fabricates a challenge token: if verification genuinely can’t complete, the run errors rather than sneaking past.
2. It confirms the request is in scope for the board and license type it’s built for; anything else returns the scoped error.
3. It searches by license number when you have it, the most precise path, or by first and last name.
4. It opens the license detail and reads the record: status, license number and type, issue and expiration dates, and every disciplinary action with its date, type, and description, or the register’s explicit statement that there are none.
5. It screenshots the board’s record as audit evidence, timestamps the check, and returns one structured record.

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.

{
  "source": "CA DCA License Search",
  "status": "found",
  "checked_at": "2026-07-16T14:02:11Z",
  "result": {
    "license_status": "Current",
    "license_number": "RN •••482",
    "license_type": "Registered Nurse",
    "name": "SAMPLE, JANE",
    "issue_date": "2014-06-12",
    "expiration_date": "2027-06-30",
    "disciplinary_actions": []
  },
  "evidence_screenshot_url": "https://…/evidence/run_51de….png"
}

For many license types, the board’s website is the API

National aggregators like Nursys and the FSMB Physician Data Center cover nurses and physicians, and if your roster stops there, they’re a reasonable rail. It usually doesn’t. Psychologists, LCSWs, LPCs, LMFTs, and most of the behavioral-health license mix have no national aggregator at all, so verification for them is the board’s own register or nothing. And even where an aggregator exists, the board’s register is the primary source, which is the standard credentialing files are held to. This workflow runs against the primary source directly and captures the disciplinary history most aggregate feeds flatten into a flag.

At scale

A single run verifies one license on one board. As a program, verifications run on the roster’s renewal cycle, licenses expire on the board’s schedule, not yours, and the exceptions, expirations, disciplinary actions, unmatched licenses land with your credentialing team with the board’s own record attached. License verification is part of the credentialing and verification workflow library.

Human in the loop

License checks run on SOC 2 Type II, HIPAA-compliant infrastructure, each with a logged result per board, which is what a delegated-credentialing audit wants to see. A disciplinary action on the record.

Frequently asked questions

Our credentialing files have their own format and rules. What is configured for us?

The board search is fixed; everything around it bends to your file standard. Asteroid configures which inputs you send, which record fields you need, the output format, delivery destination, and which findings pause for your credentialing team. Verifications arrive in the queue your coordinators already work; nothing new to learn on their side.

What does the agent need to reach a state board register?

No credentials from you: board registers like California's DCA license search are public. Because board sites often sit behind bot protection, the agent runs with a residential-proxy and captcha-solving profile that Asteroid operates; it never fabricates a challenge token, and if verification genuinely cannot complete, the run errors rather than sneaking past. License requests arrive as roster rows, sheets, or API calls, and records return the same way.

What happens with an unsupported board, an unmatched license, or bot protection that will not clear?

Each has a defined stop. A board that is not built yet returns a clear scoped error naming what is supported, never a wrong answer. Multiple matches on a name are reported for a person to resolve, or you re-run with the license number for an exact answer. Bot protection that will not clear ends the run honestly as a technical error; a check that did not happen is never recorded as clean.