Docs · Exclusion screening in CI/CD

Fail the build before you onboard an excluded provider

The exclusion endpoint screens a list of NPIs against the excluded/compromised-anywhere check, so a pull request, an onboarding job, or a deploy can fail before a provider who is on a federal or state exclusion list slips through. Call it from a shell loop or a GitHub Actions step. Every result carries its source, public list URL to re-confirm against, record date, and limitations metadata.

REST base: https://api.fonteum.com/v1 · Credential: Authorization: Bearer $FONTEUM_API_KEY

What it screens
Shell
GitHub Actions
Failure policy
Auth + source metadata

What it screens

For each NPI, call GET /api/v1/exclusions/{npi} and partitions the result into two clearly-distinct layers. The umbrella signal, compromised_anywhere, is true when either layer matches.

Layer	Meaning	Sources
`Excluded`	Hard, in-force debarment — the provider may not be paid by the program.	OIG LEIE · SAM.gov · currently loaded state Medicaid exclusion lists (GA/IA/MD/MS/MT/NC/ND/NH/NY/OH/PA/TN/WA); other states not covered
`Compromised-flag`	A monitoring or sanction signal short of exclusion.	OIG Corporate Integrity Agreements · CMS Civil Money Penalties

Screening aid — re-confirm any match against the primary source list before acting. An absence is reported as a no-match only under reconciled current coverage. Stale or unreconciled coverage is indeterminate, should fail the workflow, and is not a clearance. Not a legal or credentialing certification.

Shell

Call the exclusion endpoint directly. The second example reads one NPI per line fromnpis.txt; adapt the input parsing to your roster format.

# Screen one NPI with an account key or the read-only demo key.
FONTEUM_API_KEY="${FONTEUM_API_KEY:-fnt_DEMO_PUBLIC_V1}"
curl --fail-with-body \
  "https://api.fonteum.com/v1/exclusions/1245319599" \
  -H "Authorization: Bearer $FONTEUM_API_KEY" \
  -H "Accept: application/json"

# Screen a newline-delimited list of NPIs and keep the JSON response for each.
while IFS= read -r npi; do
  curl --fail-with-body \
    "https://api.fonteum.com/v1/exclusions/$npi" \
    -H "Authorization: Bearer $FONTEUM_API_KEY" \
    -H "Accept: application/json"
done < npis.txt

Response fields

Read both the determination and the coverage context before deciding how a pipeline should proceed. A no-match is not a clearance when coverage is stale or unreconciled.

{
  "data": {
    "npi": "1245319599",
    "excluded": false,
    "compromised_anywhere": false,
    "determination": "no_match",
    "sources": { "...": "source context" },
    "coverage": { "...": "coverage context" }
  },
  "meta": {
    "data_freshness": [{ "source": "…", "cadence": "…" }],
    "limitations_url": "https://fonteum.com/methodology#limitations"
  }
}

GitHub Actions

Add the same request to any workflow — onboarding gates, vendor-roster pull requests, or pre-deploy checks. Store the issued key in a repository or organization secret rather than placing it in the workflow file.

# .github/workflows/provider-onboarding.yml
name: provider-onboarding
on: [pull_request]

jobs:
  screen-providers:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Screen NPIs against Fonteum exclusion sources
        env:
          FONTEUM_API_KEY: ${{ secrets.FONTEUM_API_KEY }}
        run: |
          while IFS= read -r npi; do
            response=$(curl --silent --show-error --fail-with-body \
              "https://api.fonteum.com/v1/exclusions/$npi" \
              -H "Authorization: Bearer $FONTEUM_API_KEY" \
              -H "Accept: application/json")
            echo "$response" | jq .
            excluded=$(echo "$response" | jq -r '.data.excluded // false')
            if [ "$excluded" = "true" ]; then
              echo "Exclusion match for $npi" >&2
              exit 1
            fi
          done < npis.txt

Screen a fixed roster inline

      - name: Set the NPI list for the screening step
        run: |
          printf '%s\n' 1245319599 1003002627 > npis.txt

Failure policy

Exclusion match. The workflow example exits non-zero when data.excluded is true.
Coverage or API failure. Treat stale or indeterminate coverage, a network error, and a non-success API response as a failure condition rather than a pass.
Other signals. Decide explicitly whether data.compromised_anywhere should block your workflow; it can include a monitoring or sanction signal short of an exclusion.

Keep this policy in your own repository so it is reviewed alongside the workflow that uses it.

Auth, rate limits, and source metadata

Demo key. The read-only fnt_DEMO_PUBLIC_V1 credential is limited to 20 requests/minute and 100 requests/day per trusted source IP.
Account key. Create a developer account at /account/signup, issue a fnt_… key from the dashboard, and send it as Authorization: Bearer $FONTEUM_API_KEY. In GitHub Actions, store it as a repository or organization secret.
Source on every match. Each match prints the issuing list, the public source URL to re-confirm against, the in-force date, the snapshot date, and limitations metadata. See methodology and limitations.
Read-only. The screening endpoint only reads. It does not mutate Fonteumdata.