How I Built Clinical Trials API - From Public Data to RapidAPI in 2 Weeks

ClinicalTrials.gov - the U.S. government's registry of every FDA clinical trial - publishes 480,000+ studies as public domain data, updated daily. It's one of the most valuable datasets in healthcare. Pharma companies, CROs, healthtech startups, and academic researchers all need this data programmatically.

But the official ClinicalTrials.gov API v2? It's essentially a REST wrapper around a search engine built for human researchers. No structured eligibility parsing. No geographic radius search. No webhook alerts. Pagination that breaks when you change parameters mid-pagination. If you want to build anything beyond a basic keyword search, you end up scraping the website, downloading 2GB text file exports, or paying enterprise vendors $500+/month.

So I built the Clinical Trials API - a proper REST layer on top of ClinicalTrials.gov with structured eligibility, geo search, and webhook alerts. Here's how it went.

The Stack

• Runtime: Python Workers (Pyodide, Redux memory snapshots)
• Deployment: Wrangler CLI -> 330+ edge locations worldwide
• Backend Data: ClinicalTrials.gov API v2 (public domain, no auth required)
• Marketplace & Billing: RapidAPI
• Pricing: Free / $49/mo (Pro) / $199/mo (Ultra)
• Average Response: 350-500ms warm, ~1s cold start

What I Built

10 endpoints across 4 functional groups:

The Hard Parts

Challenge 1: Parsing Free-Text Eligibility Criteria

This was the hardest technical problem. ClinicalTrials.gov stores eligibility criteria as free text - often a single paragraph or bulleted list with no structure at all:

"Inclusion Criteria: Histologically confirmed triple-negative breast cancer. Age >= 18 years. ECOG performance status 0 or 1. Adequate hematologic and end-organ function. No prior systemic therapy for metastatic breast cancer. Exclusion Criteria: Prior immunotherapy for breast cancer. Active autoimmune disease requiring systemic treatment. Untreated or symptomatic CNS metastases. Pregnant or breastfeeding."

I needed to parse this into structured, machine-readable criteria objects that a patient-matching algorithm could actually use:

{
  "inclusion_criteria": [
    {"category": "Age", "text": "Age >= 18 years", "criterion": "18 years and older"},
    {"category": "Condition", "text": "Histologically confirmed triple-negative breast cancer", "criterion": "Triple-negative breast cancer confirmed by histology"},
    {"category": "Performance Status", "text": "ECOG performance status 0 or 1", "criterion": "ECOG 0-1"}
  ],
  "exclusion_criteria": [
    {"category": "Prior Treatment", "text": "Prior immunotherapy for breast cancer", "criterion": "No prior checkpoint inhibitor therapy"}
  ]
}

My approach: a heuristic NLP pipeline. First, split the raw text into candidate criteria using regex patterns that match bullet points, numbered lists, line breaks, and sentence boundaries. Then classify each candidate into one of 8 categories (Age, Gender, Condition, Lab Values, Prior Treatment, Performance Status, Organ Function, Other) using keyword matching and rule-based logic. Finally, generate a normalized concise form.

Accuracy is about 80-85%. The remaining 15-20% get category "Other" with raw text preserved. A proper ML model would do better, but I wanted to ship v1 and iterate based on feedback. The structured parsing is on the Pro tier ($49/mo) because it's the core value-add that justifies a paid plan.

Challenge 2: Geographic Search Without a Geocoding Budget

ClinicalTrials.gov lists facility addresses (name, city, state, country) but doesn't provide lat/lon coordinates. To build a geographic radius search, I needed to geocode every facility.

The problem: there are ~500,000 unique facility addresses in the database. Commercial geocoding APIs charge per-1,000 lookups. Free geocoding APIs have strict rate limits (~1 request/second).

My approach: a pre-built lookup table. I ran a Python script over 3 days that geocoded all addresses against a free geocoding API with request throttling. The resulting table maps facility addresses to lat/lon and is loaded into the worker's module-level memory. When you query /v1/trials/nearby, the worker:

1. Searches ClinicalTrials.gov for trials matching your filters
2. Looks up each facility's coordinates from the in-memory table
3. Calculates Haversine distance from your search center
4. Sorts by distance and returns the results

The table is ~20MB in memory but only contains facilities with active trials. Response time for a nearby search is 400-600ms including the upstream API call and distance calculations. Not instantaneous, but way faster than you'd get geocoding on-the-fly.

Challenge 3: Pricing - Free Tier That's Actually Useful vs. Revenue

The eternal indie dev dilemma. How do you make the free tier useful enough to attract users but restrictive enough to drive conversions?

My approach: give away the data access, charge for the value-add processing.

The free tier includes 7 of 10 endpoints. You can search trials, get details, do geographic searches, browse conditions, pull aggregate stats - everything you need to build a real prototype. 100 requests/day, 3 saved webhook alerts. No credit card, no expiry. The free tier should deliver the "aha moment": "holy crap, I just queried 480K trials in one API call."

The Pro tier ($49/mo) unlocks the features that save real engineering time: structured eligibility parsing (instead of you building a regex parser) and expanded webhook alerts (25 instead of 3, with 6-hour check frequency instead of daily).

Ultra ($199/mo) for companies where clinical trial data is mission-critical. Higher request limits, unlimited alerts, priority support, dedicated SLA.

The conversion hypothesis: free tier users hit the 100 req/day limit or need eligibility parsing, and $49/mo is cheaper than one hour of developer time.

What I'd Do Differently

1. Geocoding strategy. Spending 3 days rate-limiting against a free geocoding API was dumb. I should have paid $50 for a commercial geocoding service and been done in 2 hours. The "I'll save money by doing it free" instinct is strong in indie devs, but your time is worth more.

2. API design - separate eligibility endpoint vs. inline. I chose a separate endpoint (/v1/trials/{nct_id}/eligibility) because parsing adds ~200ms of processing, and free tier users shouldn't pay the latency cost for a feature they can't access. In retrospect, returning parsed eligibility inline in the trial detail endpoint would be cleaner. Developers expect one request, not two. I may merge these in v2.

The Numbers (So Far)

Just launched. Real numbers coming soon.

I'll update this with real numbers in 30 days.

Try It

https://rapidapi.com/capifactory-capifactory-default/api/clinical-trials-api - free tier, no credit card. Takes 30 seconds to get an API key and make your first call.

If you're building a healthtech product and need clinical trial data, I'd love to hear what endpoints would make this genuinely useful for you. I ship fast - if you need something that doesn't exist yet, tell me and I'll probably have it live within 48 hours.