ClinicalTrials.gov API v2 Reference

The endpoint & real parameters

Endpoint

GET https://clinicaltrials.gov/api/v2/studies

No authentication, no API key.

Example request

curl "https://clinicaltrials.gov/api/v2/studies?format=json&pageSize=2&filter.overallStatus=RECRUITING&query.term=AREA%5BStudyType%5DINTERVENTIONAL&fields=NCTId,BriefTitle,OverallStatus,Phase"

Real response (trimmed)

{
  "studies": [
    {
      "protocolSection": {
        "identificationModule": {
          "nctId": "NCT05879276",
          "briefTitle": "Effect at 3 Months of Early Empagliflozin Initiation in Cardiogenic Shock Patients..."
        },
        "statusModule": { "overallStatus": "RECRUITING" },
        "designModule": { "phases": ["PHASE3"] }
      }
    }
  ],
  "nextPageToken": "ZVdj7o2Elu8o3lp2Wsy8sLL2mpOQJJxuZfOp"
}

Key query parameters

pageToken pagination and how it actually terminates

This API uses cursor pagination, not offset/page numbers. Each response can include a nextPageToken string; pass it back as the pageToken query parameter to get the next page.

Termination condition

Worked pagination loop

async function fetchAllStudies(params) {
  const studies = [];
  let pageToken = null;

  while (true) {
    const url = new URL('https://clinicaltrials.gov/api/v2/studies');
    Object.entries(params).forEach(([k, v]) => url.searchParams.set(k, v));
    if (pageToken) url.searchParams.set('pageToken', pageToken);

    const res = await fetch(url).then(r => r.json());
    studies.push(...(res.studies ?? []));

    pageToken = res.nextPageToken ?? null;
    if (!pageToken) break; // the real stop condition
  }
  return studies;
}

The pageSize cap — and it doesn't error

query.term and the AREA[] syntax

query.term accepts free text, but its real power is field-scoped matching via AREA[FieldName]value. This is how the fetcher behind our own dataset (open-trials-data) restricts to interventional studies:

query.term=AREA[StudyType]INTERVENTIONAL

URL-encoded, the brackets become %5B/%5D:

curl "https://clinicaltrials.gov/api/v2/studies?format=json&pageSize=1&query.term=AREA%5BStudyType%5DINTERVENTIONAL"

The same syntax works for condition search, confirmed live:

curl "https://clinicaltrials.gov/api/v2/studies?format=json&pageSize=1&query.term=AREA%5BConditionSearch%5Ddiabetes"

You can combine AREA[] clauses with plain terms and boolean operators (AND/OR) inside a single query.term string — the field-scoped clause narrows to a specific structured field while the rest of the term can still be free text.

filter.overallStatus

Restricts to one or more exact recruitment status values, e.g. RECRUITING, COMPLETED, NOT_YET_RECRUITING, ACTIVE_NOT_RECRUITING, TERMINATED, WITHDRAWN, SUSPENDED. This is a separate parameter from query.term — it's a structured filter, not a free-text match, and combining it with query.term's AREA[] clauses (as in the example above) is the standard way to build a scoped pull like "recruiting AND interventional."

Field selection syntax

The fields parameter takes a comma-separated list of field names (not full JSON paths — short names like NCTId, BriefTitle, OverallStatus) and restricts the response to only those. Omitting it returns the full record, which is large — restricting fields is worth doing for any real pull.

curl "https://clinicaltrials.gov/api/v2/studies?format=json&pageSize=1&fields=NCTId,BriefTitle"

{
  "studies": [
    {
      "protocolSection": {
        "identificationModule": {
          "nctId": "NCT02841735",
          "briefTitle": "Young Adult Naturalistic Alcohol Study (YANAS)..."
        }
      }
    }
  ],
  "nextPageToken": "..."
}

Note that even with field selection, the response keeps the full nested protocolSection structure — you get fewer fields, not a flat object. See the flattening example below.

The nested response & a worked flattening example

Every study is nested under protocolSection, itself broken into named modules. The ones you'll touch most:

Worked flattening example (JavaScript)

function flatten(study) {
  const ps = study.protocolSection ?? {};
  const id = ps.identificationModule ?? {};
  const status = ps.statusModule ?? {};
  const design = ps.designModule ?? {};
  const sponsor = ps.sponsorCollaboratorsModule?.leadSponsor ?? {};
  const conditions = ps.conditionsModule?.conditions ?? [];
  const interventions = (ps.armsInterventionsModule?.interventions ?? [])
    .map(i => i.name).filter(Boolean);
  // Institutional location data only — see the ethics note before
  // pulling anything from contactsLocationsModule.locations[].contacts
  // or .centralContacts.
  const countries = [...new Set(
    (ps.contactsLocationsModule?.locations ?? []).map(l => l.country).filter(Boolean)
  )];

  return {
    nctId: id.nctId ?? null,
    briefTitle: id.briefTitle ?? null,
    overallStatus: status.overallStatus ?? null,
    phase: (design.phases ?? []).join('; ') || null,
    studyType: design.studyType ?? null,
    conditions,
    interventions,
    leadSponsorName: sponsor.name ?? null,
    leadSponsorClass: sponsor.class ?? null,
    enrollmentCount: design.enrollmentInfo?.count ?? null,
    enrollmentType: design.enrollmentInfo?.type ?? null,
    locationCountries: countries,
    url: id.nctId ? `https://clinicaltrials.gov/study/${id.nctId}` : null,
  };
}

This is the same shape (minus dates, trimmed for space) as the real normalizer behind open-trials-data.

Getting counts

There's no dedicated "count only" endpoint for an arbitrary filtered query — the way to get a count for a specific filter/query combination is to page through with fields=NCTId (minimizing payload size) and count rows, using the pagination loop above. For the registry's total size (unfiltered), see /stats/size below.

The /stats/size endpoint

GET https://clinicaltrials.gov/api/v2/stats/size exists and returns registry-wide size statistics — not a per-query count, but a genuinely useful sanity check for "how big is the whole registry right now."

curl "https://clinicaltrials.gov/api/v2/stats/size"

{
  "totalStudies": 597296,
  "averageSizeBytes": 17274,
  "percentiles": { "50%": 9823, "90%": 28319, "99%": 149565 },
  "ranges": [ { "sizeRange": "0 - 10 kb", "studiesCount": 315938 }, ... ],
  "largestStudies": [ { "id": "NCT02723955", "sizeBytes": 3596689 }, ... ]
}

Useful mainly as a scale reference: as of this run, 597,296 total registered studies, of which our own dataset's recruiting+interventional scope (see below) is roughly 8%.

Ethics note: this API exposes personal contact data

{
  "name": "Antoine KIMMOUN, MD PhD",
  "role": "CONTACT",
  "phone": "3 83 15 40 79",
  "phoneExt": "+33",
  "email": "a.kimmoun@chru-nancy.fr"
}

Responsible consumers of this API should exclude centralContacts, overallOfficials, and any per-location contacts field from anything beyond a single, deliberate per-study lookup done for the study's own intended purpose (helping someone decide whether to enroll). Don't request these fields in a bulk/aggregate pull, don't store them, and don't republish them in a dataset. This is exactly the line open-trials-data draws — its field list is deliberately institutional-only (sponsor organization name/class, country-level locations) and explicitly omits contactsLocationsModule's personal fields entirely, even though the API would hand them over on request.

Auth, rate limits, being polite

• No API key required. Every call in this document was made with no authentication.
• No rate-limit headers observed on our test responses, and no documented hard limit as of this writing. Treat that as a reason for caution rather than license to hammer the endpoint — it's US National Library of Medicine infrastructure.
• Space out paginated requests. A ~150–200ms delay between page fetches is a reasonable default for a bulk pull.
• Use a real, identifying User-Agent header and retry with backoff on 429/5xx, never in a tight loop.