The openFDA device/event endpoint is alive, current and unannounced for retirement. As of this writing it was last refreshed on June 2, 2026, holds roughly 25 million device adverse event records, and carries no deprecation notice anywhere in its documentation (open.fda.gov/apis/device/event/).
That matters because the FDA completed the move of device adverse event data into its new Adverse Event Monitoring System (AEMS) in May 2026. AEMS is now the system of record. openFDA is the delivery layer in front of it, and it kept serving device data through the cutover, which is why the endpoint looks unchanged even though the system behind it moved. One point vendors still get wrong in the other direction: there is no separate public AEMS API for device data, so openFDA remains the API. This article is the technical companion to our piece on whether MAUDE is going away. What does the endpoint look like now, what is changing under the hood, and how do you build a surveillance pipeline that survives a source migration already in motion?
The Endpoint Today
The device adverse event API lives at api.fda.gov/device/event.json and serves MAUDE-derived data: medical device reports submitted under 21 CFR Parts 803 and 804, with structured fields for device identification, event type, dates and patient outcome, plus the unstructured MDR narrative text where most of the clinical detail lives.
Practical characteristics worth knowing:
- Query syntax follows the standard openFDA pattern: search filters on field:value pairs, count aggregations, date-range queries on fields like date_received.
- Rate limits are 240 requests per minute and 120,000 per day with a free API key, or 40 per minute and 1,000 per day without one. For weekly surveillance pulls across a typical product code portfolio, the keyed limits are generous.
- Pagination caps at 1,000 records per request via the limit parameter, with skip for paging. Large historical pulls should iterate by date window rather than deep pagination.
- Harmonization caveats apply: openFDA enriches records with harmonized fields (openfda.device_name, openfda.product_code and friends), and that enrichment does not always succeed. Robust pipelines query both raw and harmonized fields.
None of this is new in 2026. That is the point. The endpoint behaves the way it has for years, and the FDA continues to maintain it.
The standard openFDA disclaimers still apply too: report counts cannot establish incidence rates, an MDR does not establish causation, and duplicate reports exist for single events. AEMS aims to improve the last of those through better deduplication, but the first two are properties of spontaneous reporting, not of any particular database.
The Refresh Cadence and How to Track It
The device/event dataset refreshes weekly. Two places confirm the current state:
- The openFDA updates page (open.fda.gov/about/updates/) lists each dataset with its last-updated date and record count. This is the page to check when you want to know whether data is flowing.
- The meta object in every API response includes meta.last_updated. Logging this value with each pull gives you a per-request record of exactly how fresh the data was when you queried it.
Remember that the refresh cadence is not the same as report latency. A weekly refresh moves newly processed reports into the public dataset, but reports can take 4-8 weeks from FDA receipt to public availability. Your surveillance documentation should state both numbers so reviewers understand what "current" means for your program.
A simple monitoring practice: alert if meta.last_updated ages beyond 14 days. Under normal operation it never should. If it does, either the FDA's pipeline has stalled or the cutover has started — and both are things you want to know within a week, not at the next PSUR.
What Is Changing Under the Hood
The system-of-record move is done, but the changes that reach the openFDA layer will arrive gradually (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files). None are fully documented yet, so treat this as a watch list rather than a roadmap:
Data model changes. AEMS consolidates multiple legacy systems, and a unified data model probably does not preserve every MAUDE field name and enum. Field renames, recoded event types and restructured device identification blocks are the kind of changes that silently break parsers.
Deduplication shifting record counts. Improved deduplication is a stated AEMS goal. MAUDE famously carries duplicate reports for single events when both a manufacturer and a user facility report. If AEMS consolidates those, historical counts pulled after the cutover may differ from the same query run before it. Trend baselines built on raw counts will need a bridging analysis.
New endpoints or versioning. The FDA could evolve the existing device/event endpoint in place, version it, or stand up new AEMS-native endpoints. An authenticated AEMS API with its own key issuance is possible — but despite vendor claims, no such API exists today.
Latency improvements. The FDA's August 2025 push toward real-time adverse event data suggests the 4-8 week publication lag should shrink. If it does, surveillance programs tuned to weekly cadences may find signals arriving days after the FDA does — a genuine improvement worth re-tuning for.
The common thread: every one of these changes is detectable early if you are logging meta.last_updated, record counts and schema fingerprints with each pull, and catastrophic to reconstruct after the fact if you are not.
Why Archiving Raw Responses Protects Your Audit Trail
Here is the uncomfortable scenario. In 2027, an auditor reviews a 2026 signal evaluation and asks you to reproduce the data behind it. By then the device data lives in AEMS, deduplication has consolidated records, and the query you ran in 2026 returns different numbers — or no longer runs at all. If all you kept was the spreadsheet summary, you cannot show what the source said when you made the decision.
Archiving raw API responses closes that gap. The principle comes straight from data integrity expectations: decisions should be traceable to the source data as it existed at decision time, not as it exists at audit time. MAUDE records were already mutable — reports get supplemented and amended — and a source-system migration turns slow drift into a step change.
Storage is not an argument against this. Compressed JSON for a typical product code portfolio runs to gigabytes per year, not terabytes. Against the cost of an unreproducible signal evaluation, it rounds to free.
A Minimal Archival Pattern
You do not need a data lake. For each scheduled pull, persist:
- The full request URL, including all query parameters
- The raw response body, exactly as returned, compressed
- The retrieval timestamp from your server clock, not the client
- The meta.last_updated and meta.results.total values from the response
- A SHA-256 checksum of the raw body, stored alongside it
Write once, never update. An append-only bucket with lifecycle rules aligned to your record retention schedule satisfies the intent. The checksum plus timestamp gives you a defensible claim that the archived bytes are what the FDA served on that date — which is precisely the claim you will need if the numbers shift under a migration.
How DeviceWatch Handles This
DeviceWatch's ingestion pipeline pulls from the openFDA device/event endpoint on a weekly schedule, archives every raw response before analysis, and records source metadata with each ingestion run. Our ingestion layer is abstracted from the analysis pipeline, so we followed the FDA's move into AEMS with a server-side configuration change. Customers kept their products, review history, audit trail and reports without touching anything.
Whether you build or buy, the engineering posture is the same: keep pulling from openFDA because it is the live, supported source; instrument your pipeline so any further change announces itself in your logs; and archive raw responses so the migration can never take your evidence with it.