Biotech headlines move fast. The underlying data moves on a schedule.
If you want to build a signal around drug approvals, the first job is not modeling. It is knowing which government system published what, and on which date. FDA data is public, free and reasonably well structured. It is also easy to misread, because the word "approval" covers several different events that look similar in a database row.
This piece explains the plumbing. What Drugs@FDA is, what openFDA adds, how an original approval differs from a supplement, and why a label change is often the least interesting record in the file even though it generates the most rows.
None of this is investment advice.
The two systems you actually need
There are two front doors to the same underlying data.
Drugs@FDA is the human-readable database. You search a drug name or an application number and get the application history: the sponsor, the approval letters, the reviews, the labeling. It is maintained by the FDA's Center for Drug Evaluation and Research and it covers most prescription and over-the-counter human drugs approved since 1939. You can browse it at accessdata.fda.gov/scripts/cder/daf.
openFDA is the API layer. Same agency, machine-readable output, no scraping required. The drug endpoints include a drug/drugsfda endpoint that returns Drugs@FDA application records as JSON. There is no cost and no account needed for basic use, though an API key raises your rate limit. The documentation lives at open.fda.gov.
If you are building anything automated, use openFDA. If you are checking one specific fact by hand, Drugs@FDA is faster and shows you the actual PDF letters, which the API does not.
A third source worth knowing: the FDA publishes monthly and annual lists of novel drug approvals, and CDER publishes a running list of new molecular entities. These are curated, so they are smaller and cleaner than the raw application file. They are also slower.
Application numbers tell you the pathway
Every drug application carries a number with a prefix, and the prefix is the single most useful field in the whole dataset.
NDA is a New Drug Application. This is the standard route for a new small-molecule drug. The sponsor submits full safety and efficacy data.
BLA is a Biologics License Application. Used for biologics: vaccines, monoclonal antibodies, cell and gene therapies. Different statute, similar idea.
ANDA is an Abbreviated New Drug Application. This is the generic route. The sponsor does not repeat the efficacy trials. They demonstrate bioequivalence to an already-approved reference drug. ANDA approvals vastly outnumber NDA approvals in the raw file, and they mean something completely different commercially. A generic approval is usually bad news for the originator and good news for the filer.
If your pipeline treats an ANDA row the same as an NDA row, your signal is measuring the wrong thing. Filter on the prefix first.
Original approval versus supplement
This is where most timelines break.
An original approval is the first time the FDA authorizes a specific application. The application number gets its first approval date. There is exactly one of these per application.
A supplement is a change to an already-approved application. Supplements are numbered sequentially and they cover a wide range of events. A new indication is a supplement. A new dosage form is a supplement. A manufacturing site change is a supplement. A safety warning added to the label is a supplement.
In the data, both appear as records under the same application number, with the submission type distinguishing them. In Drugs@FDA the field is typically shown as SUPPL versus ORIG, with a submission number attached. The first submission is number 1 and the supplements count up from there.
The commercial weight of these is wildly uneven. A supplement approving a new indication for an existing drug can be worth more than many original approvals, because it expands the addressable population without a new launch. A supplement changing a manufacturing site is administrative. Both are supplements. Both look identical in a naive count.
There is no field that says "this supplement matters." You have to read the submission class code. openFDA exposes it, and values like Efficacy, Labeling, Manufacturing (CMC) and Type 2 - New Indication do most of the sorting work for you. That field is the difference between a usable dataset and noise.
Label changes are records, not events
Drug labeling changes constantly. Every change generates a record.
Labeling supplements include things like a new adverse reaction added to a section, a formatting update, a change to the pediatric use language, or a correction. Many are submitted under a "Changes Being Effected" mechanism, where the sponsor implements the change and the FDA reviews after the fact. That means a label change can appear in the data without a discrete approval decision behind it in the way you would expect.
Separately, the FDA publishes a Structured Product Labeling dataset, and openFDA exposes it through the drug/label endpoint. This is the current content of the label, not a history of decisions. It is excellent for asking "what does this drug's warnings section say today." It is a poor source for asking "what happened, and when."
Treat labeling records as context, not as a trigger. Counting label supplements as approvals will inflate your numbers by a large multiple and correlate with nothing.
Which date do you put on the timeline
There are at least four candidate dates for a single approval, and they are not the same day.
- The action date. The date the FDA signed the approval letter. This is the date in the Drugs@FDA record.
- The publication date. When the record actually appeared in the downloadable file or the API. Drugs@FDA data files are refreshed on a regular cycle, not continuously, so a record can be dated Friday and be queryable the following week.
- The company announcement. The press release. Sponsors usually announce quickly, often the same evening or next morning.
- The PDUFA date. The target date the FDA committed to for a decision. This is a scheduled date, known in advance, and it is disclosed by the company rather than published by the FDA in a central list.
For any analysis that touches market reaction, the action date and the announcement date are what matter, and the gap between them is usually short. For anything that touches when you could have known, the publication date is the honest one. If you backtest against the action date but your pipeline only sees the record days later, you have built a look-ahead into the results. This is the same discipline that governs any disclosure-based dataset: score against the date the information became available, not the date the event happened.
That distinction is the whole reason disclosure lag matters. Congressional trade filings have the same structure, where the transaction date and the filing date can sit weeks apart under the 45-day rule, and institutional holdings data carries an even longer reporting lag. FDA data is faster than both, but the principle is identical.
What the FDA does not publish
Knowing the gaps is as important as knowing the fields.
Complete Response Letters. When the FDA declines to approve, it issues a CRL. Historically these were not routinely published, and the company's own disclosure was the primary public signal. The FDA has moved toward releasing more of them, but you should not assume a rejection will show up in the structured data on the day it happens.
Review timelines in progress. There is no public API that tells you an application is under review and due on a specific date. That information reaches the market through company filings and presentations.
Priority review vouchers and designations. Breakthrough Therapy, Fast Track and similar designations are usually announced by sponsors. FDA publishes some aggregate data, but not a live per-application feed.
This means a complete picture requires combining FDA data with SEC filings. A biotech's 8-K, 10-K risk factors and prospectus supplements often contain the forward-looking regulatory calendar that the FDA itself does not publish. Those filings are free on EDGAR full-text search, and the standard search interface at sec.gov/edgar/search covers the same corpus.
Free alternatives worth naming
You do not need a paid data vendor to do this well.
- openFDA covers the structured application and labeling data at no cost.
- ClinicalTrials.gov, run by the National Library of Medicine, has an API and covers trial registration, phase and completion status. It is the best free source for what sits upstream of an approval.
- EDGAR covers the corporate side, including 8-K announcements that often carry the approval news before you can query it out of the FDA file.
- The Federal Register publishes certain FDA notices with a clean API and reliable timestamps.
Paid biotech databases mostly add curation, entity resolution and a calendar of expected decision dates. That curation has real value if you need it. The raw facts are public.
Building something usable
If you were to construct an FDA approval signal from scratch, the shape would be roughly this. Pull drug/drugsfda on a schedule. Key on application number plus submission number so you never double-count. Filter by application type so ANDAs sit in their own bucket. Classify submissions by class code, and put labeling and manufacturing changes in a low-weight tier. Record both the action date and the date your job first saw the record, and use the second one for any backtest. Then join to a ticker through the sponsor name, which is the genuinely hard part, because sponsor names in FDA data do not match SEC registrant names cleanly and subsidiaries are common.
That last step is where most of the engineering effort goes. It is also where most of the errors live.
The same architecture underlies every disclosure feed worth scoring: a primary source with a defined publication cadence, an event taxonomy that separates the meaningful from the routine, and honest handling of the lag between the event and its publication. The mechanics differ. The discipline does not.
If you want to see that approach applied to a dataset where the filing lag is measured in weeks rather than days, our Smart-Money 13F Consensus report scores institutional holdings changes across managers, using the published filing dates rather than the quarter-end positions they describe, so you can see exactly what was knowable and when.
Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.