SAM.gov Exclusions & OFAC Screening

This is an on-demand check, not a monitoring subscription. Every call screens the entity you name, at the moment you ask. We don’t hold a vendor roster, watch it on a timer, or send you an alert when something changes — your system decides when to re-screen and owns the schedule. That’s a deliberate boundary, not a gap: a monitoring service that quietly misses a new listing is worse than no monitoring at all, and we would rather you keep the calendar than assume we have it.

Coverage today: both sections are live against real government data. The Consolidated Screening List (CSL) section calls trade.gov for each request whose name it can compare.

The SAM.gov Entity Exclusions section works differently. It is answered from our own copy of SAM.gov’s daily Exclusions extract, not from SAM.gov’s per-query Exclusions API, so no screen spends a SAM.gov request. That per-query API allowed our non-federal key 10 requests a day (confirmed by an HTTP 429 on 2026-08-27); SAM.gov documents a higher daily limit for keys with a SAM.gov role or a system account.

The copy is replaced by a scheduled job once a day at 13:00 UTC, after 7 AM Eastern, the time GSA gives for checking for the day’s file. A request never triggers a refresh. The job refuses an extract with no data rows, with fewer than half the rows of the copy being served, with a required column missing, or dated earlier than the copy being served, and does not start while another refresh is running; in each case the served copy and its date stay in place.

Read source.as_of on the SAM.gov section: it is SAM.gov’s own date for the extract, not the day we fetched it. When that date is more than seven days old, the section’s source.note says the data is stale and gives its age. Within a screening response the note is the only place this is said: a stale copy does not change status, overall.status or overall.incomplete_coverage, so if your process needs current data, compare source.as_of with today’s date yourself. If SAM.gov’s date could not be read, as_of is not SAM.gov’s date, and note says so and says how current the data is cannot be verified. If no copy has been loaded at all, the section reports status: "error", not a clean result.

On the CSL section as_of is always null: trade.gov’s search response carries no per-list update date, and this API does not read the per-list dates trade.gov publishes on a separate endpoint. A null there means the response does not state how current the lists are; it does not set overall.incomplete_coverage.

GET /sources returns each section’s source manifest without running a screen. GET /health reports SAM.gov’s extract date (source_extract_date), its age in days, whether it is stale, the row count of the served copy and the outcome of recent refresh runs. It does not judge whether that row count is plausible.

Reading a response

overall.status is one of four values:

• screening_incomplete: neither section could be checked (both report status: "error"). You do not have a result; treat the vendor as unscreened and retry.
• potential_matches_found: at least one section returned a match. overall.incomplete_coverage can still be true, as it is in the example.
• no_matches_among_screened_records: nothing matched and overall.incomplete_coverage is true. Not a clean screen; overall.reasons says what was not covered.
• no_potential_matches_found: nothing matched and overall.incomplete_coverage is false. The strongest clean answer this API gives, and still not a clearance.

overall.incomplete_coverage is true when any of these happened, and each adds a sentence to overall.reasons: a section’s source.basis is not live; a section reports status: "error", including a name with no Latin letters or digits to compare; the SAM.gov scan reached its limit of 500 candidate records (candidate_scan_truncated); trade.gov returned only part of its results or reported no total (result_page_truncated); or a section held back records it scored under the match floor (records_below_match_threshold above 0; the CSL section counts every record trade.gov returned under the floor, the SAM.gov section only those scoring 0.5 or more).

The example is a response captured 2026-09-15, abridged: it shows 2 of the 15 SAM.gov matches and both CSL matches, and leaves out the reasons, the disclaimer and most of each source. It was captured before the two SAM.gov match fields described next existed, so they are not shown in it.

Dun & Bradstreet data on SAM.gov matches

SAM.gov’s Terms of Use treat exclusion records created before April 4, 2022 as records that may contain Dun & Bradstreet (D&B) data, and name the Legal Business Name and address fields as D&B Open Data, which may be used only with written attribution to D&B and never in bulk. Each SAM.gov match says which side of that line its record is on:

• record_created_date: the created date SAM.gov’s extract gives the record, as published, or null. It is not exclusion_date, which is when the exclusion took effect.
• dnb_open_data: "applies" when that date is before 2022-04-04, "does_not_apply" when it is on or after 2022-04-04, and "unknown" when it is missing or unreadable, which is handled the same as "applies".

Where dnb_open_data is "applies" or "unknown", that match’s matched_name (also quoted in reason), address and state are the D&B Open Data fields, and the SAM.gov section’s source.note carries the attribution to Dun & Bradstreet. That is SAM.gov’s rule for the record, not a statement that D&B supplied those values. open_data_flag is returned as SAM.gov publishes it; SAM.gov leaves it blank, so it says nothing about D&B. This API returns individual match results only.

How matching works

score runs from 0 to 1. Both names are lowercased and stripped of punctuation and common legal forms (Inc., LLC, Co., Ltd., Corp., PLC and similar), and the score is the highest of three comparisons: how close the whole names are by edit distance, how many of their words they share, and 0.91 when the query has two or more words and all of them appear in the listed name. Records scoring under 0.72 are not shown. match_type is exact at a score of 1 and fuzzy from 0.72 up to 1. A section’s status is match when its best match scores 0.92 or more, and possible_match from 0.72.

exact does not mean identical. It means the words matched after that normalization, in any order. On the SAM.gov section, single letters present in only one of the two names are ignored, which is how a search for “Technology” was reported as an exact match on a listed “N.A.Z. TECHNOLOGY” (seen live 2026-09-15 UTC).

What an over-match looks like. Edit distance is measured over the whole name, so a long word two names share can lift a score past 0.72 by itself. In the example’s capture, 13 of the 15 SAM.gov matches for “0DAY TECHNOLOGIES” share only the word “TECHNOLOGIES” with it: “LUZY TECHNOLOGIES LLC” scored 0.824 because, once “LLC” is removed, 3 of its 17 characters differ. Treat a fuzzy match as a lead to check, not as your vendor: compare matched_name, address and exclusion_type before acting, and send state to get state_check on SAM.gov matches.

The same record twice. SAM.gov’s extract sometimes lists a record more than once. Identical rows are reported as one match with the count in source_record_count (2 for “LIMITED 0DAY TECHNOLOGIES” in the capture). Rows that differ in name, address, state, exclusion type or dates stay separate matches; the capture has three for “J & W TECHNOLOGIES LLC”.

Which name to send. Send the full registered legal name. A shorter trading name can score under 0.72 against a longer listed name; when it is held back as a near miss, overall.reasons tells you to re-screen with the full legal name. A name of two or more words that all appear in the listed name scores 0.91. On the CSL section the query is compared with each record’s listed name and every alias it lists, and matched_name is whichever scored highest. On the SAM.gov section, a record is scored when a word of three or more characters from the name you send (or, if it has none, the whole name) appears inside the listed name once spaces and hyphens are removed from both, and listed names containing non-ASCII characters are also read and compared after accents are folded. A misspelling in every longer word of a name can still keep a record from being scored. If you hold more than one spelling of a vendor’s name, screen each.

Errors

Every error body is JSON: {"error": "<code>", "message": "<text>"}.

• 400 invalid_json: the body is not valid JSON, or a batch body is not a JSON object.
• 400 invalid_entity: the body, or an entity in a batch, is not a JSON object.
• 400 missing_fields: entity_name is missing or blank.
• 400 invalid_fields: entity_name is longer than 512 characters, or address, state, uei or duns is present but not a string.
• 400 include_individuals_removed: the request sent include_individuals, which no longer exists.
• 400 missing_entities: POST /screen/batch without a non-empty entities array.
• 400 batch_too_large: more than 25 entities.
• 401 unauthorized: the request did not carry the proxy credential RapidAPI adds.
• 404 not_found: unknown route. 405 method_not_allowed: wrong method for the route.
• 500 provider_misconfigured, 500 internal_error, 503 service_misconfigured and 503 source_unavailable: a fault on our side. No screening result is returned; do not read any of them as a result, and retry later.

A source that fails during a screen is not an HTTP error: the response is 200, that section reports status: "error", and overall.incomplete_coverage is true.

Further reading: SAM.gov’s Exclusions extract as data documents ten measured traps in the daily file this API screens against — the download that answers with a redirect, the layout that does not describe the file, the rows where Name is blank, the exclusion types that changed spelling, the rows that repeat another row under a new SAM Number, and the Dun & Bradstreet date test — with a runnable script and the counts from a dated run. What a screening API does not show you sets out the seven questions to ask of any screening response, including this one.

This API is advisory only. A “no potential matches found” result is never a certified clearance, and every match requires independent human verification before declining, suspending, or terminating a vendor relationship in reliance on it. See the API’s own /terms endpoint for the full disclosure and disclaimer.