WHO ICTRP Clinical Trials Scraper

Scrape the WHO International Clinical Trials Registry Platform (ICTRP) search portal — a single search interface aggregating clinical trial registrations from 22+ national and regional registries, including ClinicalTrials.gov (USA), EU-CTR/CTIS (Europe), ISRCTN (UK), ChiCTR (China), ANZCTR (Australia/NZ), CTRI (India), DRKS (Germany), jRCT (Japan), IRCT (Iran), and more. HTTP-only, no login, no proxy, no API key.

What this actor does

• Two modes: search (condition / intervention / title / sponsor / secondary-ID / recruitment-status / date-range) and byTrialIds (exact lookup)
• Client-side filters: phase, source registry, recruiting country, results availability
• Full trial metadata pulled from each trial's detail page — condition, intervention, sponsor, phase, countries, study type/design, target size, outcomes, results-availability, eligibility criteria (age/gender/inclusion/exclusion), funding source
• Empty fields are omitted

Output per trial

• trialId, sourceRegistry — the national/regional registry that owns the record (e.g. ClinicalTrials.gov, ChiCTR, EUCTR)
• title, scientificTitle, acronym
• condition, intervention
• sponsor — primary sponsor
• secondaryId — supplementary identifier (sponsor protocol number, IND/IDE number), when on file
• recruitmentStatus, phase
• studyType, studyDesign, allocation, assignment
• gender, ageMinimum, ageMaximum — eligibility criteria
• inclusionCriteria, exclusionCriteria — full eligibility criteria text, when split by the source
• sourceOfMonetarySupport — funding source
• countries[] — countries of recruitment
• dateRegistration, dateEnrollment, lastUpdated
• targetSize
• resultsAvailable — boolean
• outcomes[] — primary/secondary outcome names (up to 10)
• trialUrl — canonical WHO ICTRP trial detail page (mirror)
• sourceRegistryUrl — canonical page on the primary registry (e.g. the actual clinicaltrials.gov or chictr.org.cn page), when linked
• resultsUrl, protocolUrl — links to posted results / study protocol, when published
• recordType: "trial", scrapedAt

Input

Field	Type	Default	Description
mode	string	search	search / byTrialIds
condition	string	–	Health condition / disease
intervention	string	–	Drug, device, procedure
title	string	–	Title contains
sponsor	string	–	Primary sponsor (partial match)
secondaryId	string	–	Secondary/supplementary ID (not the primary trial ID)
trialIds	array	–	Exact trial IDs (mode=byTrialIds)
recruitingStatus	string	ALL	ALL / Recruiting
dateRegistrationFrom / dateRegistrationTo	string	–	YYYY-MM-DD
phase	string	–	Client-side phase filter
sourceRegistry	string	–	Client-side registry filter
country	string	–	Client-side recruiting-country filter (partial match)
hasResults	string (select)	ALL	ALL / Yes / No — filter by posted-results availability
maxItems	int	20	Hard cap (1-200)

Example: recruiting diabetes trials in Germany, phase 3

{
  "mode": "search",
  "condition": "diabetes",
  "recruitingStatus": "Recruiting",
  "phase": "Phase 3",
  "country": "Germany",
  "maxItems": 30
}

Example: exact trial lookup

{
  "mode": "byTrialIds",
  "trialIds": ["NCT07670416", "ChiCTR2600127247", "ISRCTN12345678"]
}

Example: trials sponsored by a specific company

{
  "mode": "search",
  "sponsor": "Pfizer",
  "sourceRegistry": "ClinicalTrials.gov",
  "maxItems": 50
}

Use cases

• Pharma competitive intelligence — track a competitor's trial pipeline across every major registry from a single feed
• Regulatory / market access research — monitor trial activity by condition, country, or phase
• Academic research — bulk-export trial metadata for systematic reviews and meta-analyses
• Patient recruitment platforms — surface currently-recruiting trials by condition and country
• Investment research — monitor sponsor trial activity as a pipeline signal

FAQ

What's WHO ICTRP? A World Health Organization initiative that aggregates clinical trial registrations from 22+ national/regional primary registries into one searchable index, standardizing on the WHO Trial Registration Data Set.

How is this different from ClinicalTrials.gov? ClinicalTrials.gov is one of the 22+ registries WHO ICTRP aggregates. Searching WHO ICTRP covers ClinicalTrials.gov and every other participating registry (EU-CTR/CTIS, ISRCTN, ChiCTR, ANZCTR, CTRI, DRKS, jRCT, IRCT, and more) in one search.

Why is secondaryId different from the trial ID? WHO ICTRP's "Secondary ID" field holds supplementary identifiers (sponsor protocol numbers, IND/IDE numbers) distinct from the registry's own primary trial ID. Use mode=byTrialIds for exact primary-ID lookups.

Why do phase, sourceRegistry, country, hasResults, and secondaryId filter client-side instead of narrowing the search itself? The WHO ICTRP portal's phase/country picker controls require JavaScript-driven interactions that can't be reliably replayed as a plain HTTP request, and the server-side secondaryId search box does a loose/fuzzy match (verified live — searching NCT returned trials whose actual secondary ID had nothing to do with NCT). Instead, the actor fetches full trial detail for every search-matched candidate and filters precisely against the real parsed phase/registry/country/results/secondaryId fields — more accurate than the upstream fuzzy match.

Are all of WHO ICTRP's advanced-search checkboxes exposed? Most are — the ones that map onto a field the actor reliably parses (recruitment status, phase, source registry, recruiting country, results availability). A few niche upstream checkboxes (COVID-19-only, rare diseases/orphan drugs, genome editing, pediatric-only) are not exposed as filters: WHO ICTRP doesn't publish a structured flag for these on the trial detail page, so building a filter would mean guessing from free-text fields (e.g. parsing "Age minimum" strings like 18 Years / 6 Months / blank) — too unreliable to ship as a filter. ageMinimum, ageMaximum, and gender are still available as raw output fields for anyone who wants to apply their own logic downstream.

How fresh is the data? WHO ICTRP re-imports each source registry on its own cadence (typically weekly; some registries daily). Each trial's lastUpdated field reflects the underlying registry's own last-modified date.

Is there a rate limit? No documented hard cap. The actor uses small delays between requests to be polite.

Why do some searches take a while? trialsearch.who.int is a slow legacy IIS server — each trial detail page can take several seconds to render. The actor scans up to ~600 search-matched candidates (6 pages x 100/page) to satisfy maxItems and the phase/sourceRegistry/country filters. Broad searches (no client-side filters) usually finish in well under a minute; a narrow phase + registry + country combination layered on top of a broad condition search can legitimately need to scan hundreds of candidates and take several minutes — increase the run timeout under Run options for those cases, or narrow the upstream condition/intervention/sponsor terms so fewer candidates need scanning.