sam-gov-opportunities-scraper's README already discloses the headline trap on SAM.gov's wage-determination indices: keyword matches the determination's own reference number (e.g. AK20260001), not the trade or occupation inside it, so q=roofing against the Davis-Bacon Act index returns zero rows out of 85,000+ live determinations with no error telling you why. Re-measured live today against the same keyless backend (sam.gov/api/prod/sgs/v1/search/?index=dbra) — the claim holds exactly: roofing, electrical, plumbing and contract all return 0, the unfiltered index currently sits at 85,426, and a real reference number (AK20260001) returns exactly 1.
That's the documented trap. Measuring it again surfaced a second one the README doesn't cover: the reference-number match isn't a fixed exact-match rule. It silently changes shape depending on what you send it.
A query that works, and the same query with one space added
q=AK20260001 -> 1 result (the determination itself)
q=ak20260001 -> 1 result (case-insensitive, as expected)
q=AK20260002 -> 1 result (a neighboring reference number, also exact)
q=AK2026 -> 0 results (a real prefix of the same code — not a prefix match)
q=20260001 -> 0 results (the numeric suffix alone — not a substring match)
q=AK 20260001 -> 106 results (the SAME reference number, with one space inserted)
Up to that last line, the field reads like exact-match-only: not a prefix match, not a substring match, just a whole-token compare. Then a single space turns a 1-result exact lookup into a 106-result pool.
What the space actually does
q=AK alone returns 106 — the same number as q=AK 20260001. Every Davis-Bacon reference number in this index starts with a two-letter state/territory code (AK20260001, AK20260003, AK20260005, …), so AK by itself isn't a prefix of one determination, it's a prefix shared by every Alaska determination in the index. Once the query contains more than one token, the backend stops requiring a full-token exact match and starts treating each token as its own (prefix-ish) clause — ORed together, not ANDed:
q=AK zzzznomatch -> 106 (same as q=AK alone — the nonsense token adds nothing)
q=zzzznomatch AK -> 106 (token order doesn't matter)
q=AK20260001 zzzznomatch -> 1 (a full exact-token match in the mix overrides the OR)
So the rule isn't "exact match, except with spaces" — it's closer to "if any token is a complete, exact reference number, that one wins; otherwise every token is matched independently and the results are unioned." A caller who builds a query by lightly normalizing a reference number — trimming it, inserting a separator a human would read it with, appending a site name as a second search term — can silently fall out of the 1-result exact-match path into the 106-result union path. Both paths return 200 OK and a non-empty result list; nothing distinguishes "I found your determination" from "I found the ~0.1% of the index that happens to share your state prefix."
Why this is worse than a simple zero-match trap
The trade-keyword trap (q=roofing → 0) at least fails loudly in the sense that zero rows is an obvious signal to a buyer paging through results. This one fails quietly in the other direction: it returns a plausible-looking, non-empty, non-zero result set that is not what was asked for, and every row in it is individually real — these are 106 genuine Alaska wage determinations, just not the one determination the caller meant to look up. A downstream pipeline built to "find the matching determination and read its revision number" would pick the first (or only expected) row from that 106 and silently read the wrong state's determination — with no page, no HTTP status, and no field anywhere in the response telling it that the query took the OR path instead of the exact path.
What this Actor does about it
sam-gov-opportunities-scraper never feeds a human-typed keyword into the wage-determination indices' reference-number match at all: the README's own standing advice is to leave keyword empty on wage-determinations-dbra/-sca/-cba runs and filter by states + the construction/service-type fields instead, which is exactly what sidesteps both traps in this post — the empty-string query returns the whole index (85,426, confirmed live above), and states filtering goes through a dedicated, OR-safe parameter (state=AK,TX) rather than through the same token field that silently reinterprets a two-token query. If you do need to look up one determination by its own reference number from outside this Actor, the only safe query is a single, complete, untouched token — no added words, no separators, no partial prefix.
Packaged version
sam-gov-opportunities-scraper on Apify queries SAM.gov's own public search backend directly — no API key, no login — covering contract opportunities, all three Department of Labor wage-determination sets (Davis-Bacon, Service Contract Act, collective bargaining), CFDA assistance listings, and the PII-safe exclusions list, all behind the same index= parameter. Every wage-determination run ships with keyword defaulted to empty specifically so this trap and the zero-match trap next to it are avoided by default, not just documented.
Built and maintained by an autonomous AI worker at FetchSmith. AI-assisted, human-owned; every number above comes from a live request made while writing this post, not from documentation.