Recompete Watchlist

Track which federal contracts must recompete in the next 6 to 18 months, whether they are genuinely competed, who holds them now, and which contracting office to call, while the window to influence is still open.

The gap this closes

There is a candid discussion in r/govcon that keeps landing on the same conclusion: the firms that win consistently are not the ones reacting fastest to SAM.gov postings. By the time a solicitation posts, the pre-solicitation window, where a sources-sought response, an industry-day conversation, or a note to the contracting officer actually shifts your odds, has usually already closed. The advice that thread converges on is blunt: treat recompete dates as your real watch list, not SAM, and anything renewing in less than six months is too close to influence.

That is a data problem dressed as a relationships problem. The signal already exists in public award data: every active contract carries an end date, an options ceiling, an incumbent, and a competition history. The work is assembling it into a forward-looking watchlist and reading it correctly, which is exactly what teams currently hand-build out of USASpending exports, SAM, and a spreadsheet. We built this endpoint for that workflow: it does the assembly, attaches the bid/no-bid facts, and hands you into the contact layer, so a two-person BD function can run the pre-solicitation motion across five NAICS codes without it breaking down.

The framing here is not ours. Treating recompete dates as the watch list, and using sources-sought to get on a contracting officer's radar before the RFP, is the workflow that discussion landed on. We built the data layer for it.

One principle throughout: we surface facts, never a score. There is no "73% win probability." A win score is a guess you would end up owning when it is wrong. Every field on this endpoint is a fact pulled from the system of record; the bid/no-bid call is yours.

How federal recompete timing actually works

A federal contract has two end dates, and the difference between them is the whole game:

• Current end date (current_end_date), when the contract's currently-funded period of performance ends. This advances each time the agency exercises an option year.
• Potential end date (potential_end_date), the latest the contract can run if every remaining option is exercised. Fixed at award.

The gap between them, which we surface directly as option_runway_days, tells you whether the next decision is a routine option exercise (a renewal) or a real recompete. A contract ending in eight months with three option years left will almost certainly just renew; the same contract with no options remaining must be re-solicited. A recompete watchlist that ignores this is just a noisy "everything ending soon" list.

Because you read your market differently than the next firm does, the window is yours to set, not ours to bake in:

• ends_after_months and ends_within_months bound the window. Set ends_after_months=6 to skip the contracts too close to influence and lead with the actionable 6-to-18-month band.
• date_anchor=current_end (default) anchors the window on the next decision point. date_anchor=potential_end anchors it on the guaranteed final end, the contracts that must recompete by then, regardless of how many options remain.
• options_exhausted_only=true narrows to the high-confidence "must recompete, not renew" subset (options effectively used up).

Coverage note that matters for timing: federal IT services are overwhelmingly bought as task orders off larger vehicles (GWACs, agency IDIQs), not as standalone contracts. A "recompete" in those markets is often a new order competed among the vehicle's holders rather than a fresh public solicitation. The endpoint flags this per row (is_task_order, parent_award_id_piid) so you read the play correctly.

Call 1: your market's recompete watchlist

Define a market and a window. Here is a service-disabled-veteran-owned small business looking at VA IT-services recompetes (NAICS 541512), in the actionable 6-to-18-month band, capped at contracts under $25M, soonest first:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://govconapi.com/api/v1/recompetes?naics=541512&agency=veterans\
&set_aside=veteran&ends_after_months=6&ends_within_months=18\
&amount_max=25000000&sort_by=ends_soonest"

The first row that comes back (real response, abbreviated to one record):

{
  "data": [
    {
      "contract_award_unique_key": "CONT_AWD_36C10B26N10250028_3600_VA11816D1025_3600",
      "award_id_piid": "36C10B26N10250028",
      "parent_award_id_piid": "VA11816D1025",
      "is_task_order": true,
      "incumbent_uei": "LRN9VLLCX9Y8",
      "incumbent": "INSIGNIA TECHNOLOGY SERVICES, LLC",
      "agency": "Department of Veterans Affairs",
      "sub_agency": "Department of Veterans Affairs",
      "awarding_office": "TECHNOLOGY ACQUISITION CENTER NJ (36C10B)",
      "naics": "541512",
      "psc": "DA01",
      "set_aside": "SERVICE DISABLED VETERAN OWNED SMALL BUSINESS SET-ASIDE",
      "place_of_performance_state": "VA",
      "current_end_date": "2026-12-22",
      "potential_end_date": "2031-03-22",
      "option_runway_days": 1551,
      "current_value": 4117163.4,
      "extent_competed": "FULL AND OPEN COMPETITION",
      "offers_last_cycle": 8,
      "de_obligated": null,
      "mod_churn": 2,
      "incumbent_excluded": false,
      "months_until_end": 6.1,
      "subcontractors": [
        { "name": "GREENBRIER GOVERNMENT SOLUTIONS INC", "uei": "KVMTJANNET58", "subaward_amount": 899808.0 },
        { "name": "APPLIED SCIENCE & INNOVATION INC.", "uei": "ETVYBDWS54G6", "subaward_amount": 435413.85 }
      ]
    }
  ],
  "early_signals": [ /* live sources-sought / pre-sol in this market, see below */ ],
  "pagination": { "limit": 50, "offset": 0, "total": 34, "total_is_estimate": false, "has_next": false },
  "filters_applied": { "ends_after_months": 6, "ends_within_months": 18, "date_anchor": "current_end",
                       "naics": "541512", "agency": "veterans", "set_aside": "veteran", "amount_max": 25000000.0 }
}

How to read this one row. Insignia holds a $4.1M VA IT task order ending in 6.1 months, which is what put it on the list. But look at option_runway_days: 1551: there are still more than four years of option periods left, so this one most likely renews rather than recompetes in December. It earns a watch, not a sprint. The offers_last_cycle: 8 tells you that when it does recompete, it is a genuinely contested SDVOSB fight, not a wired single-bidder award. The awarding_office ("Technology Acquisition Center NJ") is your entry point into the contact layer (below), and the two subcontractors are the incumbent's current team, your teaming candidates or the competition to plan against. Thirty-four contracts match this market and window; this is one.

The moat: which "competed" contracts are actually competed

This is the part no other tool packages, and it is the single most important number on the page. The official "extent of competition" flag is theater. The truth is the offer count, and we carry both, side by side.

Measured on IT services (NAICS 541512): 37% of contracts labeled "full and open competition" drew exactly one bidder, and 46% of "full and open after exclusion of sources" drew one. A contract that says "full and open" but received a single offer last cycle is, in practice, wired to the incumbent. A contract that says "full and open" and drew seven offers is a real fight you can enter if you qualify. Same flag, opposite call, and only the offer count tells them apart.

The contrast is stark in real VA IT data. Sorted by value, the largest recompetes split cleanly:

A null offer count is a signal, not a blank. When offers_last_cycle is null, no competition was recorded. On a standalone contract marked "not competed," that means sole-source or directed, the Oracle case above. On a task order (is_task_order: true), it usually means the competition happened at the vehicle level and the order itself did not record an offer count. We never coerce null to 0 or relabel it; read it together with extent_competed and is_task_order.

Is the incumbent beatable?

Three fields, all facts, that tell you whether the incumbent is holding firm or losing their grip:

• de_obligated, the sum of negative obligations on the contract (dollars pulled back). Scope shrinking under the incumbent is a stress signal; a large de-obligation on a contract about to recompete is worth a hard look. Null when there are none.
• mod_churn, the number of contract actions. On its own a high count can just mean a big, active contract; paired with a large de_obligated it reads as a contract in trouble.
• incumbent_excluded, true when the incumbent's UEI currently appears on the federal exclusions (debarment) list. Rare, but a debarred incumbent on a recompete is a wide-open takeover.

None of these is a verdict. They are the facts a capture team would otherwise pull by hand from USASpending and SAM, attached to the same row that told you the contract is recompeting.

From a recompete to a person: the Contacts handoff

A recompete is only actionable if you can reach the people who run it. Every row carries the awarding_office (here, "Technology Acquisition Center NJ"), and that is the hinge into GovCon Contacts, the people layer for federal procurement. The motion:

1. The watchlist gives you the office. You now know which contracting shop owns the recompete and runs the buys in your market.
2. Contacts turns the office into named people, and the vendors they buy from. Search that agency or office in Contacts and you get the active contracting officers, each with an AI dossier of their buying patterns, NAICS focus, set-aside preferences, and, critically, the vendors they frequently award to. That last list is the "who is already doing similar work here" answer: those firms are your teaming targets, or the incumbents you are planning against.
3. The early-signal feed gives you the exact CO the moment anything posts. Every row's early_signals block lists the sources-sought, pre-solicitation, and special notices live in your market right now, each with the contracting officer's name and email and the response deadline. That is the documented moment to get on the radar.

Here is a real entry from the early_signals block on the VA IT query above:

{
  "notice_type": "Sources Sought",
  "title": "Interoperability and Interface Modernization Request for Information",
  "posted_date": "2026-06-11",
  "response_deadline": "2026-06-29T16:00:00+00:00",
  "contact_name": "William Milline",
  "contact_email": "[email protected]",
  "solicitation_number": "36C10G26Q0072_0001"
}

That is a live VA IT sources-sought, with the contracting officer's name, email, and a response deadline. You can respond to it today. And if all you have from a notice is a name, the Contacts resolver API (GET /api/v1/contacts/lookup?name=...) returns the verified email, phone, agency, and location for an exact match. You can also set early_signal_types=justification to surface posted sole-source justifications (J&As) in your market, which tell you what is being directed away from competition and why, with the CO who signed off.

The teaming map: named subcontractors

Each recompete row attaches the incumbent's named subcontractors on the active award, pulled from federally-reported subaward data (FFATA). In the Insignia row above, that is Greenbrier Government Solutions and Applied Science & Innovation. This is your teaming map: the firms already delivering on the work are the ones to team with, or the competitors to displace.

An honest limitation: FFATA only requires reporting of subawards over $30,000, and on task orders subs are often reported under the parent vehicle rather than the order. So the subcontractors array is populated on a minority of recompetes (roughly one in twenty in IT). When it is present it is gold; when it is empty it means no qualifying subaward was reported, not that the incumbent works alone.

A full pass, end to end

One market, one sitting:

1. Scan. GET /api/v1/recompetes?naics=541512&agency=veterans&set_aside=veteran&ends_after_months=6&ends_within_months=18. Thirty-four contracts in the influence window.
2. Triage on contestability. Drop the NOT COMPETED sole-source rows (you will not crack those this cycle) and the rows where offers_last_cycle is 1 against a "full and open" flag (effectively wired). Keep the genuinely contested ones, and note any with a large de_obligated (a stressed incumbent).
3. Read the runway. For each keeper, check option_runway_days: low runway means a real recompete is coming; high runway means a likely renewal to watch, not chase.
4. Map the players. Note the incumbent and the subcontractors: who you would be unseating, and who you might team with.
5. Find the people. Take the awarding_office into GovCon Contacts, pull the office's active COs and the vendors they favor, and build your outreach list.
6. Get on the radar. Work the early_signals feed: respond to the live sources-sought, email the CO before the RFP drops.

That is the pre-solicitation motion the community describes, run on facts, end to end, from one endpoint plus the contact layer.

What is covered, and what is not

• Source and depth. Federal prime contracts (FPDS via USASpending). Comprehensive coverage is fiscal year 2025 onward (October 2024). Because recompetes are forward-looking, any still-active contract has recent actions, so the floor is not a practical limit here.
• Forward-looking, so no history window. Unlike our search endpoints, this one is not bounded by a plan history window; it filters on future end dates, which you control.
• The contracting officer before anything posts. For task-order-heavy markets like IT, a recompete usually has no standalone notice to recover an exact CO from. The reliable paths are the CO on the live notice once it posts (the early_signals feed, ~100% carry name and email) and the awarding office plus its current COs via Contacts. We do not fabricate a contract-to-CO match where the notice does not exist.
• No future-notice link. A recompete's future solicitation number does not exist yet, so there is no hard key from a contract to its eventual notice. The early_signals feed surfaces what is live in the market; it does not claim a specific notice is the recompete of a specific contract.
• No score. Factual only, by design.

How it compares

Response field reference

Parameters

FAQ

How is the recompete date derived?

From the contract's period-of-performance end dates in federal award data, not a prediction. current_end_date is when the funded period ends; potential_end_date is the latest it can run with all options. You set the window you care about; we do not forecast or score.

Why show the offer count and the competition flag separately?

Because they disagree, often. Measured on IT services, 37 to 46 percent of contracts labeled "full and open" drew a single bidder. The flag is the agency's label; the offer count is what actually happened. The gap between them is the bid/no-bid signal, and no other tool packages it.

What does a null offer count mean?

No competition was recorded. On a standalone "not competed" contract that means sole-source or directed. On a task order it usually means the competition happened at the vehicle level and was not recorded on the order. We never turn null into 0; read it with extent_competed and is_task_order.

Can I get the contracting officer before the recompete posts?

For markets bought as task orders (most of IT), there is usually no standalone notice to recover an exact past CO from. The reliable paths are the CO on the live notice once anything posts (the early_signals feed carries name and email at ~100% on early-stage notices) and the awarding office plus its active COs via GovCon Contacts. We do not invent a CO match where the data does not support one.

How do I combine this with the Contacts product?

Every recompete carries the awarding_office. Take it into GovCon Contacts to get the office's active contracting officers, their buying patterns, and the vendors they award to most, your outreach list and your competitive picture. The early-signal notices give you the exact CO email to act on now.

What about task orders and vehicles?

Flagged per row. is_task_order: true with a parent_award_id_piid means the recompete is likely a new order competed among the vehicle's holders rather than a fresh public solicitation, so eligibility (holding the vehicle) is the play. In task-order markets that fact is often worth more than the CO name.

How fresh is the data?

Award data refreshes daily from USASpending; the early-signal notices refresh from SAM. Coverage is fiscal year 2025 onward.

Is there a win score?

No, and there will not be. Every field is a fact from the system of record. The conclusion is yours.

How do I get access?

The Recompete Watchlist is included with the Pro plan. A non-Pro key receives 402 Payment Required.

Cross-links

• GovCon Contacts, the office-to-named-people layer this pairs with
• Contacting Officer Contacts API, resolve a CO name to email/phone
• Federal Contract Awards API, the underlying FPDS award data
• Subawards API, the teaming/subcontractor layer
• Teaming Partner Finder, find qualified partners by past performance
• Pricing