OIG LEIE & SAM Exclusion Screening API: 49 official US lists in one call

Screen employees, providers, contractors and vendors against the federal exclusion lists and the state Medicaid exclusion lists in one call, with match scores, per-list provenance, and a public freshness ledger you can audit before you trust us.

Why this exists: HHS-OIG guidance directs healthcare employers to screen staff and vendors against the exclusion lists at hire and monthly thereafter. Employing or contracting with an excluded party can trigger Civil Monetary Penalties. The federal LEIE is the easy part, and every vendor does it. The states are the hard part: each publishes its own list, on its own schedule, in its own format, at a URL that keeps moving. Most teams either pay enterprise prices or click through forty-odd state websites by hand every month.

What is in the dataset

Source	Records	Refresh
OIG LEIE (federal List of Excluded Individuals/Entities)	~83,700	monthly, on OIG's cycle
SAM.gov Exclusions (federal procurement/debarment)	~168,000	daily full snapshot
State Medicaid exclusion lists	tens of thousands	per state, weekly to yearly

Every response carries the as-of date of every list consulted. The lists mode publishes the same ledger for free, including what we do not cover.

Coverage, stated honestly

Call lists for the live map. It answers the question that actually matters, what did you not check?, in three parts:

• Automated: ingested, with per-source freshness dates.
• Manual: the state publishes a list we cannot yet fetch automatically (a form-POST portal or a bot wall). We name the state and give you its official URL rather than pretending it isn't there.
• Publishes no list: 7 states, DC and all 5 territories publish no Medicaid exclusion list at all, each verified individually against the official source. For those jurisdictions LEIE + SAM.gov IS the complete screening surface. that is a finding, not a gap.

We would rather show you a named gap than an inflated number.

Modes

Mode	What it does	Billing
search	Screen one person (last_name/first_name, optional npi) or one entity (business_name)	1 screening event
screen_roster	Batch-screen a roster; returns per-party hits	1 event per party
lists	Dataset freshness and coverage map	free

Thresholds differ by mode, deliberately. search defaults to min_score 0.6 (wider, for a human reviewing one party); screen_roster defaults to 0.75 (tighter, so a large roster is not buried in near-misses). Set min_score explicitly on either if you want them to agree.

The monthly re-screen, in one field

Pass a stable monitor_id (e.g. "main-staff") with screen_roster, and give every party your own stable id. Each run then compares against the previous run for that roster and tags each party new_or_changed_hit, cleared, unchanged, or no_baseline on the first run. Schedule it monthly and you get only what changed.

Both fields are required for change tracking, and the reason is worth stating: cleared is a claim that someone came off a list. Without a stable monitor_id two different rosters would share one baseline; without your own party id, reordering the roster would attribute one person's exclusion to another. We refuse rather than guess.

For the same reason the API suppresses cleared and reports unverified_this_run instead whenever the comparison is not like-for-like, if you changed min_score between runs, or if a source failed out of that day's build. A party disappearing because a state website was down is not a party who was cleared, and comparison_note in the summary says which it was.

Match quality: scored candidates, never a bare yes/no

• npi_exact (1.0): NPI match, the strongest signal
• exact_name (1.0): normalized name match (suffixes, punctuation, case folded)
• last_exact_first_initial (0.9), and tiered partials
• fuzzy (0.6 to 0.9): edit-distance candidates, with phonetic recall so common misspellings still surface (SMYTH/SMITH, JONSON/JOHNSON). Review the score: a fuzzy hit is a candidate for a human to judge, not a finding.

Two design decisions worth knowing:

1. A party on several lists comes back once per list, with provenance. We do not collapse them into one anonymous "hit". Which list someone is on is the compliance answer, and a state exclusion is not a federal one.
2. Most LEIE individuals carry NPI 0000000000. Anyone promising you clean NPI joins has not read the data. Name-and-date matching is the real work, so results are candidates with scores and provenance for human review.

Compliance decisions need a human. This API is engineered so the right candidates are in front of that human, each saying which list it came from, which version, and why it matched.

Typical uses

• Credentialing and HR onboarding checks inside your own product
• The monthly re-screen, scheduled, reporting only changes
• Vendor and contractor due diligence before signature

What this is NOT: read before you integrate

Not a background-check service. The Provider is not a consumer reporting agency and nothing here is a consumer report under the FCRA or any state analogue. You may not use this Service as a factor in deciding about a person: hiring, firing, promotion, credit, insurance, housing or benefits.

That sounds like it contradicts the use case, so here is the line precisely: use this to find the candidates that need looking at, then verify each one against the official source it names and make your decision on that verified record. A hit here is a pointer to a government publication, never a finding about a person.

Honest limits

Not legal advice. Not a substitute for primary-source verification where a match is acted upon. Every match names the list it came from (source_id), and the free lists mode gives that list's official URL and as-of date, so any hit can be checked against the government source it came from. Where a state is listed as manual, we have not checked it for you; its official URL is in the source row.

Methodology: every record is built from, and checked against, the official primary source, and each source's URL and as-of date are published so you can verify any result yourself.

Support: friendlyapidev@gmail.com

---

Terms of Use

Effective 9 August 2026. These Terms govern this and every other data service published by the Provider. "The Provider" means the operator of the Service, reachable at friendlyapidev@gmail.com. "The user" means anyone who accesses the Service, paid or free. By using it you agree to them.

§1's consumer-reporting provisions and §5's prohibition on decisions about individuals are directed principally at services that return records about named people.

1. What this service is

The Service provides structured data compiled from public government sources. It is an information product. It is not legal advice, not a compliance determination, and not a background-check or consumer report.

Nothing in the Service constitutes a verdict about any person or entity. The Service returns candidate matches with confidence scores and source provenance, which a competent human must review before any action is taken.

The Provider is not a consumer reporting agency, and nothing the Service returns is a "consumer report" or "investigative consumer report" within the meaning of the Fair Credit Reporting Act (15 U.S.C. § 1681 et seq.) or any state analogue. The Service is not assembled or evaluated for the purpose of establishing a consumer's eligibility for employment, credit, insurance, or housing, and the Provider does not follow the procedures the FCRA requires of consumer reporting agencies. Permitted uses are set out in §5.

2. No warranty

THE SERVICE AND ALL DATA ARE PROVIDED "AS IS" AND "AS AVAILABLE", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF ACCURACY, COMPLETENESS, CURRENCY, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

Specifically, and without limiting the above, the Provider does not warrant that:

• the data is complete, current, or free from error;
• every relevant record has been collected, or that any particular jurisdiction, list, or record is included;
• a "no match" result means a person or entity is not subject to any exclusion, sanction, action, or legal obligation;
• source publications will remain available, unchanged in format, or on any particular schedule.

3. The data comes from third parties we do not control

All data is derived from public government publications. Those publishers control what they publish, when, in what format, and whether it is accurate. They change formats without notice, take sites offline, and publish records containing their own errors. The Provider reproduces and normalises what those sources publish and does not independently verify the truth of any underlying record.

Each result identifies the source it came from, and the Service publishes the as-of date and official URL of every source it carries, so any result can be checked against the government publication it derives from.

4. The user's verification duty

The user is solely responsible for verifying any result against the official primary source before relying on it or acting on it, and for obtaining professional advice appropriate to their circumstances.

The Service's published coverage statement is part of these Terms. It states which jurisdictions are collected automatically, which are published by their source in a form the Service does not collect, and which publish nothing at all. A user who acts on the Service without reading it does so at their own risk.

5. Acceptable use

Permitted. Query the Service, integrate it into your own product, and display individual results to your own users, including as part of a compliance workflow you operate.

Prohibited. The user shall not:

1. Use the Service, in whole or in part, as a factor in any decision about an individual's employment, engagement, retention, promotion, credit, insurance, housing, or eligibility for any benefit. The Service is not a consumer report (§1). Screening obligations that arise from law or regulation must be discharged against the official primary source, and any decision about a person must rest on that verified source and the user's own judgement, not on this Service.
2. Extract, copy, or redistribute the dataset in bulk, or use it to build, train, or populate a competing dataset or data feed. (Querying the Service and showing results to your own users is expressly permitted above.)
3. Use the Service in violation of any law, or to re-identify, harass, or defame any individual appearing in the data.

A record in these datasets means only that a government body published it. It is not a finding by the Provider about any person.

6. Limitation of liability

TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE PROVIDER SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR ANY LOSS OF PROFITS, REVENUE, DATA, GOODWILL, OR BUSINESS OPPORTUNITY, ARISING OUT OF OR RELATING TO THE SERVICE, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), OR ANY OTHER THEORY, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

THE PROVIDER'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THE SERVICE, IN THE AGGREGATE AND FOR ALL CLAIMS COMBINED, SHALL NOT EXCEED ONE HUNDRED US DOLLARS (US$100).

The user acknowledges that this limitation is a material part of the bargain, that the fees charged reflect it, and that the Provider would not offer the Service on these terms without it.

Two notes on why the cap is a flat figure rather than a multiple of fees. It is never zero. A cap of zero for a user who paid nothing invites the argument that the clause is illusory, and a court that agrees may strike the whole limitation rather than read it down. And it is fixed rather than computed, so there is nothing to reconstruct from billing records years later.

Nothing in these Terms excludes or limits liability that cannot lawfully be excluded or limited. If any part of this section is held unenforceable, the remainder continues to apply to the fullest extent permitted.

7. Indemnity

The user shall indemnify and hold the Provider harmless from any claim arising from the user's use of the Service, including any decision made in reliance on it and any breach of §5.

8. Availability and changes

The Service may change, add, or remove data sources and coverage at any time, and may be unavailable. Changes to coverage are reflected in the published coverage statement.

9. Governing law

These Terms are governed by the laws of the State of New York, without regard to conflict-of-laws principles. The parties submit to the exclusive jurisdiction of the state and federal courts located in the State of New York, and each waives any objection to that venue.

Disputes are resolved in court; these Terms do not require arbitration.

Pricing

Pay per event, no subscription. Prices fall on higher Apify plans.

Event	What triggers it	Price
screening	One person or organisation screened against all 49 lists	$0.10 (from $0.06)

lists mode, which shows every source and its freshness, is free. A 500 person roster is $50 to screen against 348,040 records; commercial screening services charge that per seat per month.

10. Contact

friendlyapidev@gmail.com

Support is handled by email. There is no telephone support and no guaranteed response time.

---