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 has said device data will move into its new Adverse Event Monitoring System (AEMS) during 2026, and some vendors have jumped ahead of the facts — claiming MAUDE is already decommissioned and AEMS API keys are available. Neither is true. We cover the debunking in detail elsewhere; this article is the technical companion. What does the endpoint look like today, what could actually change at the cutover, and how do you build a surveillance pipeline that survives it?
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. A migration to AEMS may eventually improve the last of those, 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 Could Change When FDA Cuts Over
The FDA's MDR Data Files page commits to MAUDE data becoming available in AEMS in 2026, with no month given (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files). When that happens, several technical changes are plausible. None are announced, so treat this as a risk checklist 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 when the FDA moves device data into AEMS we update the source configuration server-side. Customers keep their products, review history, audit trail and reports without touching anything.
Whether you build or buy, the engineering posture for 2026 is the same: keep pulling from openFDA because it is the live, supported source; instrument your pipeline so a cutover announces itself in your logs; and archive raw responses so the migration can never take your evidence with it.