NIH RePORTER Grant Funding & Procurement Signals avatar

NIH RePORTER Grant Funding & Procurement Signals

Under maintenance

Pricing

Pay per usage

Go to Apify Store
NIH RePORTER Grant Funding & Procurement Signals

NIH RePORTER Grant Funding & Procurement Signals

Under maintenance

Monitor NIH RePORTER grants and research funding for new awards, award changes, and cautious procurement signals relevant to biomedical research vendors. Adds recurring change detection and evidence—not purchasing guarantees.

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Blake Panter

Blake Panter

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

9 days ago

Last modified

Share

Monitor official NIH RePORTER data for NIH grants, research funding changes, new grant awards, and timing signals that may help prioritize vendor account research. This Actor compares normalized grant snapshots across runs, connects described research needs to an auditable biomedical vendor taxonomy, and emits only new or changed procurement signals by default.

Built for

  • biomedical research vendors and life-science suppliers
  • laboratory equipment, reagent, imaging, logistics, and clinical-research providers
  • business development, market intelligence, and sales operations teams
  • grant consultants and research-funding analysts tracking NIH-funded organizations

Why this instead of a raw NIH grant scraper?

A raw scraper gives you rows to repeatedly download and compare. This Actor turns NIH RePORTER grant data into a recurring monitoring workflow with persistent change detection, buyer filters, award and project-window context, matched evidence terms, stable deduplication keys, and explicit source coverage. The output is a cautious research-prioritization signal—not a claim that a grant award will become a purchase.

Important: A grant, award change, or approaching budget/project end date does not guarantee purchasing. Reported dates are planning windows, not mandatory spend deadlines. Validate any opportunity with the award recipient and the official NIH record.

What is a paid result?

Each dataset item is one grant-procurement-signal pay-per-event result:

  • new-award
  • renewal-or-supplement
  • award-increase / award-decrease
  • budget-window-ending / project-window-ending
  • metadata-change
  • unchanged (only when explicitly enabled)

The Actor does not sell raw grant rows. It adds stable state, change detection, timing interpretation, buyer filters, and an auditable vendor taxonomy.

Official source and coverage

The Actor sends bounded POST requests to:

https://api.reporter.nih.gov/v2/projects/search

Requests are sorted by award_notice_date descending and use the selected fiscalYears. maxSourceRecords limits how many of the newest matching API records are examined. Every result includes sourceCoverage with the API total, examined count, requested limit, fiscal years, retrieval time, and whether coverage was truncated.

Because records are sorted newest first, a bounded run is not full historical coverage when sourceCoverage.truncated is true.

Vendor taxonomy

Classification is deterministic. Evidence contains only configured terms actually matched in NIH title, abstract, terms, or preferred terms:

CategoryExample evidence terms
lab-equipmentlaboratory equipment, centrifuge, microscope, flow cytometer, sequencer
reagents-biospecimensreagent, antibody, assay kit, biospecimen, biobank, blood sample
imagingMRI, PET scan, CT scan, ultrasound, microscopy, neuroimaging
clinical-researchclinical research, clinical trial, patient monitoring, site coordination
recruitment-staffingparticipant recruitment, enrollment, recruiter, research personnel
data-aiartificial intelligence, machine learning, bioinformatics, software, algorithm
logisticscold chain, shipping, courier, specimen transport, supply chain
general-researchresearch support, research resources, laboratory supplies, core facility

A category is evidence about the project description, not proof that a matching purchase will occur.

Input example

{
"fiscalYears": [2026],
"queryText": "biomarker",
"states": ["CA", "MA"],
"activityCodes": ["R01", "U19"],
"agencyCodes": ["NCI", "NIA"],
"minimumAwardAmount": 250000,
"vendorCategories": ["imaging", "reagents-biospecimens"],
"signalTypes": ["new-award", "renewal-or-supplement", "award-increase", "budget-window-ending"],
"endingWithinDays": 90,
"includeInitial": true,
"emitUnchanged": false,
"maxSourceRecords": 1000,
"maxItems": 100,
"pageSize": 100,
"requestTimeoutSecs": 30,
"baselineStoreName": "nih-grant-procurement-signals"
}

Input behavior

  • organizationNames uses case-insensitive substring matching.
  • states, activityCodes, and agencyCodes are case-insensitive. Administering-IC abbreviations such as NCI are normalized as the output agencyCode; source aliases such as CA also match.
  • queryText is matched locally across title, abstract, raw NIH terms and pref_terms, organization, project number, and taxonomy evidence.
  • minimumAwardAmount excludes missing amounts when set; blank source values stay null, never 0.
  • vendorCategories and signalTypes allow any selected value to match. Signal-type selection is applied before unchanged is decided, so an enabled unchanged signal can represent that no selected change type applied.
  • includeInitial: false seeds a fresh baseline without emitting first-seen award signals. Eligible ending-window signals can still be emitted.
  • emitUnchanged: false suppresses unchanged snapshots. Window signals are emitted once per stored identity/date state.
  • maxItems is checked before every paid output. The Actor also stops immediately when Apify reports eventChargeLimitReached.
  • The named baselineStoreName must be reused across scheduled runs. Use a fresh name when intentionally creating a new monitoring baseline.

Output

Each item includes:

  • stable application/project identity and dedupeKey
  • old/current award amounts and dates, plus awardAmountDelta
  • organization, state, principal investigators, administering agency, activity/award codes
  • vendor categories and matched vendorCategoryEvidence
  • a cautious, signal-specific reason
  • official NIH detail URL
  • explicit sourceCoverage
  • detectedAt

Example shape (illustrative values):

{
"signalType": "award-increase",
"dedupeKey": "nih-appl-123-award-increase",
"applicationId": 123,
"organizationName": "EXAMPLE UNIVERSITY",
"oldAwardAmount": 500000,
"currentAwardAmount": 550000,
"awardAmountDelta": 50000,
"vendorCategories": ["imaging", "data-ai"],
"vendorCategoryEvidence": { "imaging": ["magnetic resonance imaging"], "data-ai": ["machine learning"] },
"reason": "The reported award amount increased ...; this is a planning signal, not a purchasing commitment.",
"officialDetailUrl": "https://reporter.nih.gov/project-details/123"
}

Baseline semantics

The key-value store is keyed by stable NIH application identity (appl_id, with project-number fallback). For every filtered current project, the Actor durably stages the normalized baseline and pending signals before pay-per-event output. After each successful sink write/charge, it removes that signal from the pending outbox and persists the acknowledgement before moving to the next signal.

Delivery is at least once, not exactly once. If the process fails after the output sink accepts and charges a signal but before the acknowledgement is persisted, the next run can deliver and charge that signal again. Other partial failures leave unacknowledged signals pending for retry; they do not guarantee that charges cannot repeat. Consumers should make processing idempotent and deduplicate repeated deliveries by the stable dedupeKey included in every item.

Changing filters or baseline names changes the monitored population; choose store names deliberately.

Application type 2, 3, or 5, or a project-number supplement suffix, is labeled renewal-or-supplement. Other first-seen applications are labeled new-award. This is a transparent NIH-code interpretation, not a purchasing prediction.

Local development

bun install --frozen-lockfile
bun run test
bun run typecheck
npx --yes apify-cli validate-schema

Run locally with Apify storage by placing input in storage/key_value_stores/default/INPUT.json, then:

$APIFY_LOCAL_STORAGE_DIR=./storage bun run start

For a stateful smoke test, run twice with the same baselineStoreName; the second unchanged run should emit no new items when emitUnchanged is false. Use a fresh dataset/storage directory if you need a clean output count.

Responsible use

Use signals to prioritize account research, not to assert intent, availability, procurement method, timing, or vendor eligibility. Follow applicable solicitation, grant, institutional purchasing, privacy, and outreach rules. The NIH RePORTER record and recipient organization remain authoritative.