ClinicalTrials.gov Change Monitor — New Trials, Status Flips, New Sites

Docs & recipes: pricing math, use-case playbooks and copy-paste API/MCP snippets

A change-detection feed over the official ClinicalTrials.gov v2 API (~600k registered studies). Point it at a therapeutic area, a sponsor, or a country; schedule it daily; and get only what changed since the last run:

change	What it means	Who cares
new_trial	A study matching your filters was just registered/entered your funnel	CI teams: a competitor just started a program
status_change	Recruiting → Active / Terminated / Completed / Suspended… (with previous_status, new_status, why_stopped)	CRO BD: enrollment closing = rescue/next-phase conversations; termination = white space
sites_added	New facilities joined an existing trial — facility name, city, state, country, site status, and PI name exactly as published by CT.gov	Site-selection intel, KOL mapping, "who is expanding where"
enrollment_change	Target/actual enrollment moved (previous_enrollment, new_enrollment, enrollment_delta)	Enrollment trouble (cuts) or confidence (raises) — both are signals
baseline	First delta run only — seeds the tracked universe, flagged is_baseline: true	Your starting book of record
snapshot	Snapshot mode rows (no diffing, no state)	One-off pulls, backfills

This is not another snapshot scraper. Snapshot actors re-dump the same thousands of rows every run and leave the diffing to you — and they structurally cannot catch the most valuable event: a study whose status flips out of your filter (Recruiting → Terminated) simply vanishes from a snapshot. This actor persists a fingerprint of every tracked study in a key-value store and re-checks tracked studies by NCT ID with no status filter, so the flip itself is delivered as a record.

Why not the free CT.gov email alerts?

ClinicalTrials.gov's own "saved search" emails are fine for a patient tracking one disease. They are not a BD tool:

	Free CT.gov email alerts	This actor
Format	HTML email, one study per blob	Structured JSON records, stable schema
What changed	"This study was updated" — go click and guess	Field-level diff: exact status flip, enrollment delta, the specific new sites
Site-level detail	No	Facility + city/state/country + site status + PI name (as published)
Multi-filter portfolios	One saved search per email	Any number of watchlists via stateKey, one per schedule
Automation	Copy-paste from your inbox	Dataset → API/webhooks/Zapier/Sheets; schedulable; callable from AI agents via MCP
Sponsor watch	Weak	Lead-sponsor filter (sponsor: "Merck Sharp & Dohme")

And why not Citeline/TrialTrove? Five figures a year. A daily watch here costs pennies (pricing below).

Input (everything optional — empty input works)

{
  "condition": "non-small cell lung cancer",
  "sponsor": "AstraZeneca",
  "phases": ["PHASE2", "PHASE3"],
  "statuses": ["RECRUITING"],
  "countries": ["United States", "Germany"],
  "mode": "delta",
  "daysBack": 7,
  "stateKey": "nsclc-az"
}

Defaults: condition: "oncology", phases 2–3, RECRUITING, worldwide, mode: "delta", 7-day baseline window. An empty {} input is a valid run (live-tested: ~450 baseline studies).

• condition takes full CT.gov Essie syntax ("multiple myeloma" OR "plasma cell myeloma").
• statuses defines which studies enter tracking. Once tracked, a flip to any status is still reported — that's the product.
• daysBack bounds only the first (baseline) run and snapshot mode: "studies updated in the last N days". Subsequent delta runs automatically use the time since the previous run (+3-day safety margin). Set daysBack: 3650 to baseline the entire matching universe at once.
• stateKey: one independent watchlist per key. Changing filters on an existing key is detected (fingerprint) and safely re-baselines instead of emitting a garbage diff.

Output sample (a status change — the money record)

{
  "change": "status_change",
  "nct_id": "NCT00000001",
  "url": "https://clinicaltrials.gov/study/NCT00000001",
  "brief_title": "A Phase 2 Study of ...",
  "lead_sponsor": "Example Pharma",
  "previous_status": "RECRUITING",
  "new_status": "ACTIVE_NOT_RECRUITING",
  "still_in_tracked_statuses": false,
  "why_stopped": null,
  "phases": ["PHASE2"],
  "conditions": ["Non-Small Cell Lung Cancer"],
  "enrollment_count": 120,
  "enrollment_type": "ESTIMATED",
  "num_sites": 34,
  "countries": ["United States", "Germany"],
  "last_update_post_date": "2026-08-05",
  "primary_completion_date": "2027-06-30",
  "observed_at": "2026-08-06T22:34:59+00:00"
}

new_trial/baseline/snapshot records also carry the full sites array; sites_added records carry new_sites (just the additions) plus sites_added_count. Fields not published by CT.gov are null, never missing. See sample_output.json for real live-run output.

Use cases

• CRO business development — schedule one run per therapeutic area every morning. status_change to ACTIVE_NOT_RECRUITING means enrollment just closed (time the next-phase pitch); TERMINATED with why_stopped is a displacement opening; sites_added in your geography is a warm site-network lead.
• Pharma competitive intelligence — one stateKey per competitor via the sponsor filter: every new program, phase population, enrollment cut, and geographic expansion, as JSON, the day CT.gov posts it.
• Site selection / KOL mapping — sites_added with facility, city, state, and PI name (only as published professionally by CT.gov).
• Investors / biotech analysts — enrollment cuts and quiet terminations often front-run press releases.

Delta mode details

State lives in the named key-value store clinicaltrials-change-monitor-state under your stateKey. Each run: (1) fetches studies matching your filters updated since the last run, (2) re-checks tracked NCT IDs missing from that fetch — with no status filter — so out-of-filter flips are caught, (3) diffs, pushes only changes, and updates state. Studies not updated at all are carried forward silently at zero cost. A study that leaves your filter set is reported once (status_change with still_in_tracked_statuses: false, or left_filter) and then dropped; if it later re-enters, it shows up as new_trial.

Using from Claude / MCP

Once published, call it through the Apify MCP server (https://mcp.apify.com):

{
  "tool": "your-username/clinicaltrials-change-monitor",
  "input": { "sponsor": "Pfizer", "condition": "", "stateKey": "pfizer-watch" }
}

Ask your agent: "What changed in Pfizer's trial portfolio this week?" — that's one delta run.

Pricing

$0.01 per record. Delta records are few and high-value — a daily watch on a whole therapeutic area typically emits a handful to a few dozen records ($0.05–$0.50/day); a single-sponsor watch usually costs under $0.10/day. The one-time baseline on default filters is 450 records ($4.50); bound it with daysBack/maxStudies if you want a cheaper start. Snapshot mode is priced the same — use daysBack and maxStudies to control row counts.

Fair use & data notes

Data comes from the official, free, keyless ClinicalTrials.gov v2 API (data.gov terms), fetched politely: capped page sizes, inter-page pauses, exponential backoff honoring Retry-After. Records are public regulatory disclosures. Person names (site PIs/contacts) are included only exactly as published professionally by ClinicalTrials.gov, and only in their professional capacity; no other personal data is collected or enriched.