How to Automate Federal RFP Search: Alerts, APIs, and AI Matching

Checking SAM.gov by hand does not scale. A single agency can post hundreds of notices a day across nine notice types, and almost none are yours. Anyone who has tried to keep up manually has already discovered the real problem: this is a filtering problem, not an access problem. The data is free and public. Finding your slice of it is the work.

Here are the three ways to automate it, what each actually does, and where each one breaks.

The three approaches

Approach	Cost	Setup	Latency	Controls the filter
SAM.gov saved search alerts	Free	Minutes, no code	Daily email	SAM.gov's filters only
Get Opportunities API	Free with a key	A day of code	Whatever you schedule	Entirely yours
AI relevance matching	LLM inference	Built on top of the API	Same as your pull	Plain-language description

Most teams should start at the top row and only move down when they hit its limits.

Option 1: SAM.gov saved searches

SAM.gov lets you build a search with its filters, save it, and get email notifications when new notices match. It is free, it requires no code, and it is the right starting point for most small firms.

Its limits are the limits of its filter set. You get the fields SAM.gov exposes, combined the way SAM.gov combines them. If your sense of "relevant" does not reduce to NAICS codes, set-aside types, and keywords, you will get a daily email you learn to ignore. That is the failure mode: not missing the alert, but the alert training you to stop reading it.

Option 2: The Get Opportunities API

If you want control, pull the notices yourself. The specifics that matter:

• An api_key is required on every request. You generate it from your Account Details page on SAM.gov, and it is only visible until you navigate away, so copy it when you see it.
• postedFrom and postedTo are required, in MM/dd/yyyy format, and may span no more than one year per request. Backfilling further means looping over windows.
• limit goes up to 1,000 records per page and defaults to 1. That default surprises people. Always set it explicitly and page with offset.
• Rate limits vary by account type. The documentation ties requests per day to federal, non-federal, and general roles rather than publishing one number, so build in backoff instead of assuming headroom.
• deptname and subtier are deprecated in v2. Use organizationCode or organizationName.

The filters worth knowing: ncode for NAICS (up to six digits), typeOfSetAside, ptype for notice type (o solicitation, k combined synopsis/solicitation, r sources sought, p presolicitation), state and zip for place of performance, rdlfrom and rdlto for response deadline, and status for active, inactive, archived, cancelled, or deleted.

That set covers structured filtering completely. It does not cover relevance.

Why NAICS and keywords are not enough

This is the part that makes RFP search genuinely hard, and it is why "just filter on your NAICS code" advice fails in practice.

A NAICS code is an industry, not a capability. 541512 covers help desk staffing and enterprise architecture alike. Filtering on it hands you both. Worse, agencies code similar work differently, so the code that describes your business is not reliably the code on your opportunity.

Solicitations do not use your vocabulary. You sell data platform engineering. The notice says "grid resilience and forecasting analytics support." You search for "data platform" and never see it. No keyword list survives contact with the way contracting officers write, because every agency has its own dialect and most notices are written to describe an outcome rather than a service category.

Keyword filters fail in both directions at once. Loosen them and you drown. Tighten them and you miss the work you were best positioned to win.

What AI matching adds, and the one thing it must do

A language model scoring the full notice text against a plain description of what you sell solves the vocabulary problem. "Proposals related to expanding AI compute capacity" will surface a notice about secure research infrastructure buildout even though the two share almost no words.

That capability comes with one non-negotiable requirement: it has to show you why.

An unexplained relevance score is worse than a keyword filter, because you cannot audit it, you cannot tune it, and you cannot tell a bid team why they are reading a 40-page solicitation. Every match needs the source record, the specific language that triggered it, and a reason in words a human can argue with. If an AI matcher cannot tell you why something matched, you have replaced a filter you understood with one you have to trust blindly, on a decision that costs a week of proposal time.

The same goes the other way. You want to know what it rejected and why, at least on a sample, because a silent false negative is invisible and permanent.

A monitor that survives contact with reality

If you build this yourself, the shape that works:

1. Pull on a schedule against a trailing window, not a single day. Notices get amended and reposted, and a window with overlap absorbs that.
2. Dedupe on notice ID, not title. Titles change between amendments.
3. Filter in two stages. Run cheap deterministic rules first (set-aside, place of performance, dollar range, notice type) to cut the volume, then score only the survivors with a model. Scoring everything is how a monitoring bill gets out of hand for no accuracy gain.
4. Store the match reason alongside the record, with the model and prompt version that produced it. When someone asks in March why a January opportunity was flagged, the answer should be retrievable rather than reconstructed.
5. Keep the raw payload. Normalize for your own use, but preserve the source record, external ID, retrieval time, and content hash. Your pipeline will change and you will want to re-run it against history.
6. Watch the early notice types. If you only monitor solicitations, you see requirements at the moment you have the least ability to shape them. Sources Sought and Presolicitation are where the leverage is.

None of this is exotic. The reason most teams do not have it is that it sits in the gap between "check the website" and "buy enterprise software," and the gap is a few hundred lines of code plus a decision about how much you trust a model.

Which should you pick?

Start with SAM.gov saved searches. They are free and they will tell you within two weeks whether structured filters describe your business.

If the daily email is mostly noise, the filters are not the problem and more of them will not help. That is the signal to move to the API and add relevance scoring on top, with explanations attached to every match.

If you sell below $25,000 per engagement, automate none of it. Work under the publicizing threshold mostly never appears on SAM.gov, and your route in is direct relationships with small-purchase buyers.

---

Sources. API parameters, key requirements, date limits, and paging from the SAM.gov Get Opportunities Public API documentation. Notice type codes from the same source. Publicizing threshold from FAR 5.101 and FAR 5.203, current as of FAC 2026-01. Verified October 14, 2026.