RegulatoryCore

RegulatoryCore provides cross-agency access to drug regulatory authorizations from the FDA (US) and EMA (EU). Each record is one authorization, normalized onto a shared schema (unified authorization status, procedure type, and regulatory designations mapped onto common comparison axes), so US and EU records can be filtered and compared side by side without being equated. Updated weekly.

Sources & Documents

Every record is built from primary agency filings. The structured metadata is parsed from each agency's official application records and enriched from the underlying regulatory documents.

What feeds the metadata

Each FDA record draws on:

• Application records. Application number, brand name, and submission class for each NDA/BLA, plus the set of documents filed with it (labels, review packages, approval letters).
• Label data. Active substance, therapeutic indication, marketing-authorisation holder, approval date, prescription class (Rx/OTC), and marketing status.
• Review documents and approval letters. Expedited-program designations: Accelerated Approval (with its indication), Breakthrough Therapy, Fast Track, and RMAT.
• Withdrawal notices. Withdrawal date, reason, and a link to the source notice.
• Orphan status. FDA Orphan Drug and EMA Orphan Medicine designations.

Each EMA record draws on:

• EPAR record data. Authorization and CHMP opinion status, procedure type, INN and active substance, therapeutic area and indication, pharmacotherapeutic group and ATC code, marketing-authorisation holder, every key date (CHMP opinion, EC decision, MA grant, withdrawal, refusal, lapse), revision number, and the regulatory flags (conditional approval, exceptional circumstances, accelerated assessment, additional monitoring, advanced therapy, biosimilar, generic/hybrid, orphan, PRIME).
• EPAR assessment reports and SmPCs. The source documents linked from each record.

On both agencies, moleculeType and referencesDrugCore are derived by linking each authorization's active ingredient(s) to DrugCore.

Document text & retrieval

Behind every record sits the parsed full text of its source PDFs, split into sections:

Direct links. Every record links straight to its source PDFs: fdaDetails.labelUrl (FDA label), emaDetails.smpcUrl (EMA SmPC), and sourceUrl (the agency landing page for the full review or EPAR set).

Full-text search. GET /records?query= searches the structured metadata (product name, active substance, indication, holder) and sweeps the parsed full text of every label, review, SmPC, and EPAR. When a content phrase drives the match, the matching sections come back on each record's documentSections[], each carrying a matchedText excerpt. A clinical phrase that lives only deep in a Warnings section or a Medical Review, never in the structured fields, still surfaces the drug. See Search the regulatory source documents.

Scoped search. Add &amassId=AMRC_... to confine the same full-text search to a single record's documents.

Table of contents. GET /records/{amassId} returns the record's full section index on documentSections[] (content-free — documentSectionId, path, title, docType).

Fetch a section. GET /records/{amassId}/document-sections/{documentSectionId} returns one section with its full parsed content. See Reading a drug's source sections.

Endpoints

Search: GET /v1/cores/regulatorycore/records

Cross-agency search across FDA and EMA authorizations by text, with optional filters.

query matches the structured metadata and sweeps the parsed full text of every label, review, SmPC, and EPAR. When document content drives a match, the hit sections are returned on each record's documentSections[] with a matchedText excerpt (the array is empty when the match was metadata-only). Pass amassId to scope the full-text search to a single record's documents.

# query searches both the record metadata and the parsed source documents
curl "https://api.amass.tech/api/v1/cores/regulatorycore/records?query=immune-mediated%20hepatitis&limit=10" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Parameters:

Example with filters: active orphan antibodies authorized by the EMA since 2020:

curl "https://api.amass.tech/api/v1/cores/regulatorycore/records\
?query=oncology\
&agency=EMA\
&moleculeType=ANTIBODY\
&authorizationStatus=ACTIVE\
&isOrphan=true\
&minAuthorizationDate=2020-01-01" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Response:

{ "data": [ { "amassId": "AMRC_...", "agency": "FDA", "name": "...", "..." }, ... ] }

Multi-value filters

The enum filters agency, moleculeType, authorizationStatus, and hasDesignation each accept multiple values by repeating the param.

• Within one filter, OR. Repeat the param to match any of the listed values: ?authorizationStatus=ACTIVE&authorizationStatus=CONDITIONAL returns authorizations that are active or conditional.
• Across filters, AND. Mixing different filters narrows the result: ?agency=EMA&moleculeType=ANTIBODY returns EMA authorizations that are also antibodies.

hasDesignation only applies to the agency that owns each designation, so listing designations from both agencies (e.g. an FDA-only and an EMA-only one) keeps records from both, each side matched on its own column.

# Late-stage oncology biologics (antibodies or ADCs) that are active or
# conditionally authorized in either market
curl "https://api.amass.tech/api/v1/cores/regulatorycore/records\
?query=oncology\
&agency=FDA\
&agency=EMA\
&moleculeType=ANTIBODY\
&moleculeType=ANTIBODY_DRUG_CONJUGATE\
&authorizationStatus=ACTIVE\
&authorizationStatus=CONDITIONAL\
&limit=100" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Get by ID: GET /v1/cores/regulatorycore/records/{amassId}

Fetch a single authorization by its Amass ID.

curl "https://api.amass.tech/api/v1/cores/regulatorycore/records/AMRC_abc123\
?include=fdaDetails&include=emaDetails" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Response:

{ "data": { "amassId": "AMRC_...", "agency": "FDA", "name": "...", "..." } }

The record carries documentSections[] — the content-free table of contents of its source documents (every section's documentSectionId, path, title, and docType). Follow any documentSectionId into the section endpoint below to read its full text.

Returns 404 if not found.

Get document section: GET /v1/cores/regulatorycore/records/{amassId}/document-sections/{documentSectionId}

Fetch one parsed source-document section (an FDA label/review or EMA SmPC/EPAR section) with its full text. Discover the documentSectionId from the table of contents on GET /records/{amassId} or from the documentSections[] evidence on a full-text search.

curl "https://api.amass.tech/api/v1/cores/regulatorycore/records/AMRC_abc123\
/document-sections/AMRCDS_def456" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Response:

{
  "data": {
    "documentSectionId": "AMRCDS_def456",
    "amassId": "AMRC_abc123",
    "docType": "FDA_LABEL",
    "path": "5.2",
    "title": "Immune-Mediated Hepatitis",
    "textType": "Label",
    "content": "KEYTRUDA can cause immune-mediated hepatitis... (full section text)",
    "sourceUrl": "https://www.accessdata.fda.gov/.../label.pdf",
    "sourceDate": "2024-03-12"
  }
}

Returns 404 if the section id is unknown for that record. See documentSections shape for the fields. The whole source PDF is at the section's sourceUrl.

Reading a drug's source sections

What does a label actually say about hepatic-impairment dosing — and can I pull the exact section text, not a PDF? Once you have a record's amassId, browse and read its source documents section by section, no PDF parsing on your side. Three steps: list the table of contents, optionally search within that one record, then fetch the section.

1. List the table of contents. GET /records/{amassId} returns the record with a content-free documentSections[] index — every section's documentSectionId, path, title, and docType.

{
  "data": {
    "amassId": "AMRC_abc123",
    "name": "Keytruda",
    "documentSections": [
      { "documentSectionId": "AMRCDS_a1", "docType": "FDA_LABEL", "path": "2.4", "title": "Dosage in Hepatic Impairment" },
      { "documentSectionId": "AMRCDS_a2", "docType": "FDA_LABEL", "path": "5.2", "title": "Immune-Mediated Hepatitis" },
      { "documentSectionId": "AMRCDS_a3", "docType": "EMA_SMPC", "path": "4.2", "title": "Posology and method of administration" }
    ]
  }
}

2. (Optional) Search within just this record. If the document is long, scope the full-text search to this one record with amassId. Matching sections come back with a matchedText excerpt.

curl "https://api.amass.tech/api/v1/cores/regulatorycore/records\
?query=hepatic%20impairment\
&amassId=AMRC_abc123" \
  -H "Authorization: Bearer amass_YOUR_KEY"
# → the record, with documentSections[] narrowed to the hits, each carrying matchedText

3. Fetch the full section text. Take any documentSectionId — from the table of contents or the scoped search — and fetch its complete parsed text:

curl "https://api.amass.tech/api/v1/cores/regulatorycore/records/AMRC_abc123\
/document-sections/AMRCDS_a1" \
  -H "Authorization: Bearer amass_YOUR_KEY"

{
  "data": {
    "documentSectionId": "AMRCDS_a1",
    "docType": "FDA_LABEL",
    "path": "2.4",
    "title": "Dosage in Hepatic Impairment",
    "content": "No dose adjustment is recommended for patients with mild hepatic impairment...",
    "sourceUrl": "https://www.accessdata.fda.gov/.../label.pdf",
    "sourceDate": "2024-03-12"
  }
}

Compare the same topic across markets. Because both the FDA label and the EMA SmPC are indexed under one record's cross-market links, you can read how each agency words the same topic. Resolve the counterpart amassId from authorizationsByAgency, list its table of contents, and fetch the equivalent section (4.2 Posology on the SmPC ↔ 2 Dosage and Administration on the label).

Lookup: POST /v1/cores/regulatorycore/records/lookup

Resolve agency identifiers to Amass IDs in batch. Each item must contain exactly one identifier: fdaApplicationNumber, emaProductNumber, ndc, or splSetId.

curl -X POST "https://api.amass.tech/api/v1/cores/regulatorycore/records/lookup" \
  -H "Authorization: Bearer amass_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "fdaApplicationNumber": "BLA125514" },
      { "emaProductNumber": "EMEA/H/C/003820" },
      { "ndc": "0169-4404" },
      { "splSetId": "ffffffff-ffff-ffff-ffff-ffffffffffff" }
    ]
  }'

Response:

{
  "data": [
    {
      "input": { "fdaApplicationNumber": "BLA125514" },
      "amassIds": ["AMRC_abc123"]
    },
    {
      "input": { "emaProductNumber": "EMEA/H/C/003820" },
      "amassIds": ["AMRC_def456"]
    },
    {
      "input": { "ndc": "0169-4404" },
      "amassIds": ["AMRC_xyz789"]
    },
    {
      "input": { "splSetId": "ffffffff-ffff-ffff-ffff-ffffffffffff" },
      "error": { "code": "NOT_FOUND", "message": "No matching record found" }
    }
  ]
}

A single identifier can resolve to more than one Amass ID, so amassIds is always an array. Individual items can fail without failing the whole request, so always check each item for an error field.

Changes — GET /v1/cores/regulatorycore/changes

A resumable feed of authorizations that were created, updated, or deleted, for keeping a local copy and watchlists in sync without re-reading the corpus. Read updateType to tell them apart.

curl "https://api.amass.tech/api/v1/cores/regulatorycore/changes\
?since=2026-01-01\
&limit=500" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Parameters:

Response:

{
  "data": [
    {
      "amassId": "AMRC_abc123",
      "updateType": "unchanged",
      "updateDate": "2026-07-03",
      "createDate": "2026-03-23",
      "documentSections": [
        { "documentSectionId": "AMRCDS_a1", "updateType": "updated", "updateDate": "2026-09-03", "createDate": "2026-02-11" },
        { "documentSectionId": "AMRCDS_a7", "updateType": "deleted", "updateDate": "2026-09-03", "createDate": null }
      ]
    },
    {
      "amassId": "AMRC_def456",
      "updateType": "updated",
      "updateDate": "2026-09-04",
      "createDate": "2024-11-18",
      "documentSections": []
    },
    {
      "amassId": "AMRC_ghi789",
      "updateType": "deleted",
      "updateDate": "2026-09-05",
      "createDate": null,
      "documentSections": []
    }
  ],
  "nextCursor": "eyJ2IjoxLCJ..."
}

Response fields:

Every object reports its own dates — the entry describes the authorization record, each documentSections element describes that section.

updateDate can predate your since. When updateType is unchanged, the record's own last write may be months before the window you asked for, and the in-window dates are on the documentSections entries. Page on nextCursor and never filter the returned items on a date locally — that would drop exactly the document revisions this feed exists to report.

What to re-fetch. updateType other than unchanged → re-fetch GET /records/{amassId}. Any documentSections entry → re-fetch that section, or drop it if its updateType is deleted. A record-level deleted → drop the record and everything under it; it carries no documentSections because every section went with it.

A deleted section is not a deleted record. The record stays live and fetchable, drop that one section and keep the rest. Only the entry's own updateType describes the record, and a record-level deleted never carries documentSections at all.

updateType describes the record, not the page. A record whose row and sections moved together reads the same on every page carrying part of that change, however many pages that takes. Arrivals covering different days can still differ, updated for the day the row moved, unchanged for a day only its sections did. Process every arrival rather than keeping only the last, and re-fetch the record if any of them says other than unchanged.

A record losing many sections can fill a page on its own. Its section tombstones are scanned against limit while producing no items, so the record's own deleted may arrive several pages later. This is the sharpest case of a short page with a non-null cursor, follow the cursor.

The feed returns identifiers and change metadata, not record content, fetch the records you care about with Get by ID once you know which ones moved.

FDA and EMA share one feed and one cursor. They are the same kind of record in one identifier space, so splitting them would hand you two cursors over that space for no gain. Filter the delivered amassIds on agency after a fetch if you only track one market.

Paging. Pass the nextCursor from each response back as cursor on the next request. Keep going until nextCursor is null, that is the only signal you are caught up. A page can hold fewer than limit items and still have a cursor: limit bounds the rows the feed scans, not the items it returns, so both a day boundary and a record that changed in more than one place on one day leave a page short.

Delivery is at-least-once. The same amassId can appear more than once across pages, so apply the feed as an upsert rather than a counter.

The most recent day is withheld. A day is only served once ingestion for it has finished, so an in-progress run cannot hand you a half-written day and leave the rest stranded behind your cursor. In practice a change becomes visible about a day after it lands.

Resume from a day or two before your last since, not from "now". The feed serves everything from since up to the last fully-ingested day, so nextCursor: null means you have that not that you are caught up to the current date. Advancing your next since to today therefore steps over the withheld day and never comes back for it. Store the since you asked for and re-ask from slightly before it: delivery is at-least-once and you upsert by amassId, so the overlap costs a page and nothing else.

Fetch a changed section straight from Get document section rather than re-reading a table of contents that can run to hundreds of entries for one edit. documentSections names what surfaced this record on this page, not the record's complete section list, a record whose changed sections straddle a page boundary arrives more than once with a different subset each time. Read the table of contents on Get by ID when you need the record's current set.

Watching a specific set of authorizations

If you track a fixed portfolio rather than a mirror of the corpus, pass amassId — repeated, up to 100 per request — and the feed reports only those:

curl "https://api.amass.tech/api/v1/cores/regulatorycore/changes\
?since=2026-01-01\
&amassId=AMRC_abc123\
&amassId=AMRC_def456" \
  -H "Authorization: Bearer amass_YOUR_KEY"

Everything else is unchanged — same envelope, same updateType, same cursor, same price. In particular scoping weakens no guarantee: deletions still arrive, and so do document revisions.

Repeat the parameter once per record. A comma-joined list — amassId=AMRC_abc123,AMRC_def456 — is read as one identifier and rejected.

Two consequences worth knowing:

• A scoped page can never hold more than 100 distinct records, so limit above 100 does nothing.
• A cursor is bound to the amassId set it was issued for. Change the set while paging and the cursor is rejected with a 400.

Records whose Amass ID is malformed, belongs to another Core, or is sent as an empty value are rejected outright rather than skipped. A silently dropped id would leave you believing a record is being watched when it is not.

To watch more than 100, split the list into chunks of 100 and sweep each independently — chunking the same way on every run, since each chunk's cursor is bound to its exact id set. Sort by amassId and slice, or derive the chunk from a stable property of the record; do not chunk by iteration order over a set or hash map.

Deletions

Deletions arrive on this feed as updateType: "deleted", under the same cursor as every other change. That is what lets a consumer holding an amassId tell "removed from Drugs@FDA or the EMA register" from "never existed".

The feed reports current state, not a complete event log. A record removed more than once reports only its most recent removal. If you need a record's exact history rather than its present state, reconcile against a Get by ID fetch.

A withdrawn authorization is not a deletion. Withdrawn, suspended and revoked authorizations stay indexed; they arrive as an authorizationStatus change with updateType: "updated". A deletion means the record left the agency's register outright, which is rare.

Record Schema

Default fields (always returned)

Optional fields

Request these with the include parameter. Repeat for multiple: ?include=emaDetails&include=fdaDetails

The two dates

Two fields describe when Amass touched a record, and they are separate from the agency dates (authorizationDate, fdaDetails.labelDate, fdaDetails.withdrawalDate, and the EMA procedure dates) that say when the agency did something.

lastUpdateDate is when Amass last wrote the row. It moves when the authorization record itself change, a status change, a new designation, a corrected field, but not when only one of the record's parsed source documents changes: a label revision, a re-issued SmPC, or an added EPAR section leaves the row byte-identical. It is filterable from both ends: minLastUpdateDate and maxLastUpdateDate.

lastUpdateDate is also not the same as the change feed's updateDate. The feed also walks the parsed source documents, so a document-only revision surfaces there, as updateType: "unchanged" on the record, with the moved sections named on documentSections — while lastUpdateDate stays put. Polling maxLastUpdateDate will not find that case; the change feed is the only way to see one. When the two disagree, the feed is the more complete answer.

There is no maxCreateDate. A record's create date never changes once set, so a threshold is enough, only the update date describes a moving fact and needs a window.

Covering a long window

Search returns a ranked top-K, so a wide lastUpdateDate window can truncate silently. To cover a long span, request it in slices e.g.: minLastUpdateDate=2026-08-01&maxLastUpdateDate=2026-08-07, then the next week and union the results. Each slice gets its own top-K, so this reaches records a single wide request would drop.

For complete coverage with no truncation at all, use /changes. The division is: search answers "what changed, among things matching my query" ranked, top-K, no deletions. /changes answers "everything that changed" complete, ordered, deletions included.

createDate distinguishes an authorization that is new to Amass from one that has been tracked for years and was merely revised. It is also the reliable way to make that call on the change feed, whose updateType describes a delivery rather than the record. It can be null on records ingested before Amass tracked it.

Reference field semantics

╔════════════════ RegulatoryCore (authorizations) ════════════════╗
║                                                                  ║
║   AMRC_us  (FDA, ACTIVE)  ◄── authorizationsByAgency ──►         ║
║                                  AMRC_eu  (EMA, WITHDRAWN)        ║
║                                                                  ║
║      ── cross-market: same product, arrows stay within Core ──   ║
║                                                                  ║
╚══════════════════════════════════════════════════════════════════╝
                                │
                                │   AMRC_us.referencesDrugCore = [AMDC_xxx]
                                │   ── cross-core link to DrugCore ──
                                ▼
╔══════════════════ DrugCore (active ingredients) ════════════════╗
║                                                                  ║
║                           AMDC_xxx                               ║
║                                                                  ║
╚══════════════════════════════════════════════════════════════════╝

• Cross-market link (authorizationsByAgency) stays inside RegulatoryCore; target IDs start with AMRC_. It carries each linked authorization's status, so the cross-market status-divergence headline (e.g. active in the US / withdrawn in the EU) reads straight off the list.
• Cross-core link (referencesDrugCore) leaves RegulatoryCore for DrugCore; target IDs start with AMDC_.

designations shape

Each designation tags an agency-native program onto a shared comparison axis, so FDA and EMA programs are comparable without being equated.

{
  "axis": "EARLY_ACCESS_BASIS",
  "type": "ACCELERATED_APPROVAL",
  "agency": "FDA",
  "nativeName": "Accelerated Approval",
  "basis": "SURROGATE_ENDPOINT",
  "indication": "...",
  "postMarketingObligation": true
}

authorizationsByAgency shape

{
  "amassId": "AMRC_...",
  "agency": "EMA",
  "name": "...",
  "authorizationStatus": "WITHDRAWN_VOLUNTARY"
}

documentSections shape

One parsed section of a source document comes back in three shapes, so none carries an always-null field:

• Evidence — the list embedded on a full-text search (GET /records?query=). Carries the matchedText excerpt that drove the hit; no content field.
• TOC — the list embedded on the single-record GET (GET /records/{amassId}). The content-free table of contents: structural fields only; no matchedText and no content.
• Section — the single-section fetch (GET /records/{amassId}/document-sections/{documentSectionId}). Carries the full content; no matchedText field.

// Evidence — embedded on a full-text search (matchedText drove the hit)
{
  "documentSectionId": "AMRCDS_...",
  "amassId": "AMRC_...",
  "docType": "FDA_LABEL",
  "path": "5.2",
  "title": "Immune-Mediated Hepatitis",
  "textType": "Label",
  "matchedText": "...KEYTRUDA can cause immune-mediated hepatitis...",
  "sourceUrl": "https://www.accessdata.fda.gov/.../label.pdf",
  "sourceDate": "2024-03-12"
}

// TOC — embedded on the single-record GET (structural only)
{
  "documentSectionId": "AMRCDS_...",
  "amassId": "AMRC_...",
  "docType": "FDA_LABEL",
  "path": "5.2",
  "title": "Immune-Mediated Hepatitis",
  "textType": "Label",
  "sourceUrl": "https://www.accessdata.fda.gov/.../label.pdf",
  "sourceDate": "2024-03-12"
}

// Section — the single-section fetch
{
  "documentSectionId": "AMRCDS_...",
  "amassId": "AMRC_...",
  "docType": "FDA_LABEL",
  "path": "5.2",
  "title": "Immune-Mediated Hepatitis",
  "textType": "Label",
  "content": "KEYTRUDA can cause immune-mediated hepatitis... (full section text)",
  "sourceUrl": "https://www.accessdata.fda.gov/.../label.pdf",
  "sourceDate": "2024-03-12"
}

Both shapes share these base fields:

Plus exactly one variant-specific field (the TOC shape adds neither):

fdaDetails shape

emaDetails shape

Controlled Vocabularies

These enums are case-sensitive in responses (UPPER_SNAKE). Filter inputs accept the same values; authorizationStatus is case-insensitive on input.

agency: FDA, EMA

moleculeType: SMALL_MOLECULE, ANTIBODY, PROTEIN, ENZYME, OLIGONUCLEOTIDE, GENE, CELL, ANTIBODY_DRUG_CONJUGATE, VACCINE_COMPONENT, VACCINE, OLIGOSACCHARIDE, UNKNOWN

authorizationStatus: ACTIVE, APPROVED_NOT_MARKETED, CONDITIONAL, SUSPENDED, WITHDRAWN_VOLUNTARY, WITHDRAWN_FORCED, REVOKED, LAPSED_SUNSET, REFUSED, WITHDRAWN_DURING_REVIEW, EXPIRED, UNKNOWN

procedureType: FDA: NDA, BLA, ANDA, UNKNOWN. EMA: CENTRALISED_HUMAN, WITHDRAWAL_HUMAN, CENTRALISED_VETERINARY, WITHDRAWAL_VETERINARY, UNKNOWN

hasDesignation / designation type: PRIORITY_REVIEW, BREAKTHROUGH_THERAPY, FAST_TRACK, RMAT, ACCELERATED_APPROVAL, ACCELERATED_ASSESSMENT, PRIME, CONDITIONAL_MA, EXCEPTIONAL_CIRCUMSTANCES

designation axis: REVIEW_ACCELERATION, DEVELOPMENT_SUPPORT, EARLY_ACCESS_BASIS

designation basis: SURROGATE_ENDPOINT, INCOMPLETE_DATA, UNCONFIRMABLE_DATA

documentSections[].docType: FDA_LABEL, FDA_REVIEW, EMA_SMPC, EMA_EPAR

See Also

• BiomedCore: Biomedical literature records
• TrialCore: Clinical trial records
• DrugCore: Drug and molecule records
• GeneCore: Gene records
• API Workflows: See RegulatoryCore in action: US/EU approval comparison, regulatory designations, orphan drugs, identifier lookup, and full-text search across labels, SmPCs, reviews & EPARs
• Overview: Errors and rate limits
• Quickstart: Getting started with examples