SAM.gov Exclusion Check Automation

Check a provider or an entity for federal exclusion and debarment on SAM.gov: a clear found or not-found status with exclusion type, classification, and dates back as one structured record. Pure API, no browser session, no screenshot needed, because the API’s own response is the evidence.

Go-live in as little as 30 min·Public API·Customer API key

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Overview

What this workflow does

This is the government-wide half of exclusion screening. Where the OIG’s list covers exclusions from federal healthcare programs, SAM.gov records exclusions and debarments across the federal government, and it lists organizations as well as individuals. One run checks one provider or entity and returns the shared screening envelope: a found, not-found, or multiple-matches status, with the match detail attached.

You identify the subject three ways, in order of precision: a SAM UEI for an exact entity match, an NPI, or a first and last name. A not-found run is a successful clean check, on record with a timestamp.

How Asteroid runs this workflow

Government-wide exclusion screening, straight from the SAM.gov API

A provider or entity record arrives with your organization's own API key, Asteroid queries the SAM.gov Exclusions API, resolves the identity, and returns the classified record to your roster, with possible matches and incomplete identifiers routed to a person rather than decided by the agent.

How it actually runs

1. The agent queries the official SAM.gov Exclusions API directly, no browser session involved. Authentication uses the free API key from your organization’s own SAM.gov account, stored in an agent profile and sent with the request; the key is never echoed into the output, the logs, or the reported source URL.
2. It matches by UEI when you have one, by NPI, or by name with the individual classification applied.
3. It classifies the result: no records is a clean not-found; one record is found; several are multiple matches; and an API failure is an explicit error, never a silent pass.
4. For every match, it captures the listed name, UEI, exclusion type, the Individual or Firm classification, and the activation and termination dates, normalized to ISO format.
5. It timestamps the check and returns one structured record. The API’s response is the evidence; there’s no portal screen to screenshot and no need for one.

Closing the loop

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": "SAM.gov",
  "status": "found",
  "checked_at": "2026-07-16T14:02:11Z",
  "result": {
    "excluded": true,
    "match_count": 1,
    "matches": [
      {
        "name": "SAMPLE HEALTH SERVICES LLC",
        "uei": "ABC•••••••12",
        "exclusion_type": "Ineligible (Proceedings Completed)",
        "classification": "Firm",
        "active_date": "2021-03-04",
        "termination_date": "Indefinite"
      }
    ]
  },
  "source_url": "https://api.sam.gov/entity-information/v4/exclusions?…"
}

Clean on one federal list isn’t clean

The OIG list answers a healthcare question; SAM.gov answers a federal one, and they are different lists with different reasons for someone to be on them. A provider, an owner, or a vendor entity that’s clean on one can appear on the other, which is why screening programs run both, plus the state Medicaid lists, as one pass. Running only the list you’ve always run is a habit with a gap in it, not a screening program.

This check composes directly with the OIG exclusion check for the federal healthcare side, and with the state Medicaid exclusion check for the state layer.

At scale

One check, or the whole roster and vendor file

A single run answers one subject. As a program, the roster runs on the same monthly cadence as the rest of exclusion screening, and because SAM.gov lists firms as well as individuals, the same primitive covers the entities you contract with, not just the providers you employ.

Human in the loop

What escalates to a human

Runs execute on HIPAA-compliant, SOC 2 Type II infrastructure, and every screening leaves the timestamped trail an auditor asks for first. Full detail on the security page.

Multiple matches on a common name.

All matches are reported with detail; a person confirms identity, or you re-run with the UEI for an exact answer.

A found result.

Exclusion and debarment are contracting and employment decisions. The agent delivers the record; the call is yours.

Questions

How does this template bend to the way our screening pass already works?

You keep your process; Asteroid configures the check around it. That means choosing the identifier you send (a SAM UEI for exact entity matching, an NPI, or a name), the fields returned from the match detail (exclusion type, Individual or Firm classification, activation and termination dates), the output format, and which statuses pause for review. Because SAM.gov lists firms as well as individuals, the same run can cover your vendor file with no separate setup. Your team sees records in their existing queue, nothing new to learn.

What access does the SAM.gov check need, and where do results go?

One thing: a free API key from your organization's own SAM.gov account. The agent queries the official SAM.gov Exclusions API directly: no browser session, no portal login. The key lives in an agent profile, is sent only with the request, and never appears in outputs, logs, or the reported source URL; it stays revocable and rotatable by you. Inputs arrive as roster rows, sheets, or API calls, and each structured record returns the same way.

What happens on an ambiguous match, a bad key, or an API failure?

Each case has a defined ending. An API rejection or failure is retried once, then ends as an explicit error. A check that did not happen is never recorded as clean. Multiple matches on a common name are a classified result: every record routes to a person with UEI, classification, and dates attached, or you re-run with the UEI for an exact answer. The agent reports only what the API returned and never fills in identity details it was not given.