EUDAMED Medical Device Lookup – UDI, SRN, Class

What does EUDAMED Medical Device Lookup do?

EUDAMED lookup for medtech regulatory affairs, distributors, hospital procurement and market analysts: look up any device in the EU medical device database by UDI-DI, Basic UDI-DI, manufacturer SRN, product name, risk class or EMDN code, and get one record with the device identification, manufacturer, authorised representative, risk class and legislation, market status, registration date, EMDN nomenclature and the notified-body certificates behind it. Switch to monitor mode and every new registration in a risk class, nomenclature branch or competitor's portfolio, and every status or certificate change of a watched device, arrives as a dataset item the day EUDAMED shows it.

Why now

Since 28 May 2026 the use of EUDAMED's Actor, UDI/Devices, Certificates and Market Surveillance modules is mandatory (Commission Decision (EU) 2025/2371): a device may only be placed on the EU market once it is registered, and legacy devices must be registered by 27 November 2026. Registrations are public and machine-readable as they are entered; the catch is that the Commission's web application answers one screen at a time.

Monitor mode: competitive intelligence from the register

Set mode to monitor, keep the same searches, schedule the task daily.

• Per manufacturer: every device a competitor registers, with class, EMDN and certificate; every device they withdraw from the market; every certificate that is suspended, withdrawn or renewed.
• Per risk class and EMDN branch: new class III vascular implants (riskClasses: ["class-iii"], emdnCodes: ["P07"]), new IVDR class D assays, new software devices in a nomenclature branch, restricted to MDR or IVDR if you wish.
• Per product name or per UDI-DI: the devices you distribute or buy, watched for status and certificate changes.

The first run delivers every watched device as a baseline record, priced as a device like a lookup, so you see what is watched. Later runs deliver only new devices (added, priced as a device) and changes (changed/removed, priced as a change, at most maxChangesPerRun per run) with a one-line summary written for an inbox: Unloader One (05690977326316) – Össur: status On the EU market → No longer placed on the EU market (since 2026-09-10); certificate C-1 Issued → Withdrawn. Every device of a watched UDI-DI, Basic UDI-DI or manufacturer is read again on each run, because EUDAMED's search does not say whether a device group changed (at most 50,000 devices read again per run, and none once the run nears its timeout: the next run reads those); product-name, risk-class and EMDN feeds read their newest pages until a page holds no new device, so a device that has slipped out of that window is not read again. Unchanged devices cost nothing, so a daily watch on a large portfolio costs the start fee when nothing happened. Wording next to a code is not compared, only the code: the labels of risk class, legislation, device status, manufacturer status, certificate type and certificate status, EMDN term names, the manufacturer's country name and notified-body names. Links, version numbers, the last-update date and the two spellings EUDAMED uses for one device status are not compared either. Adding a search to a watch, or changing its legislation or onlyOnTheMarket, starts a new baseline for the searches affected, charged per device again.

Sources

Two public interfaces of the European Commission, combined:

• API - EUDAMED Public v1.0 on the DG SANTE data lake (documentation): the Commission's documented public API, a nightly snapshot of the UDI and actor registers with exact-match filters. Used first for every UDI-DI, and for an SRN the live search does not find.
• The live EUDAMED database, through the JSON interface its own web application uses: device search newest-first, device and device-group records, version history, certificates, notified bodies and economic operators. Used for everything the snapshot lacks: details, certificates, today's registrations. It is not documented by the Commission. The Actor checks the structure of every response, and when a device or its device group cannot be read, the lookup fails and is not charged. Most fields are optional in that check, so a field EUDAMED renames arrives empty instead of failing the lookup: null, or an empty list for list fields such as certificates and emdn.

Reuse of Commission data is permitted under CC BY 4.0 (Commission Decision 2011/833/EU). Records delivered by this Actor should carry the attribution Source: EUDAMED, European Commission. Registration in EUDAMED is a manufacturer's own declaration; certificates are entered by notified bodies; neither replaces a Declaration of Conformity or an EU certificate as evidence.

Features

• EU medical device lookup by UDI-DI, Basic UDI-DI, manufacturer SRN, product name, risk class or EMDN code
• Device identification, risk class, legislation and market status in one record, with legacyDevice and special device types
• Manufacturer and authorised representative with SRN, country and EUDAMED status; the manufacturer record itself is free
• Notified-body certificates per device group and per manufacturer: number, type, status, issue and expiry dates
• EMDN nomenclature codes with names, and searches by nomenclature branch
• EUDAMED monitor: new registrations per class, branch or manufacturer, and status or certificate changes of watched devices, with a webhook
• GS1 check-digit validation of UDI-DIs before anything is searched
• Contact details are never read: the contact persons, e-mail addresses and telephone numbers EUDAMED publishes stay out of every record. The manufacturer's name and address are delivered, plus its VAT and EORI number and website in the manufacturer record, and the authorised representative's name, country and address
• Runs through the Apify API, on a schedule, or from Make, Zapier and n8n

Use cases

Regulatory affairs: competitor and portfolio watch

Watch competitor SRNs and your own: new devices, withdrawals, certificate status. A watch on ten manufacturers with 2,000 devices in total costs a baseline of $100 once (2,000 devices at $0.05 each, the same as looking them up) and then only what changes. Set Maximum devices per search to at least the device count of the largest manufacturer, because the default 100 watches only each manufacturer's newest 100. Set Maximum devices per run to 2,000 as well. Otherwise only the first 500 arrive as the baseline, and the rest arrive over the next runs, at most 500 per run, as added records that look like new registrations.

Distributors and hospital procurement: is this device on the EU market, and who stands behind it?

Look up the UDI-DIs on the quotation. deviceStatus, legislation (MDR or still a legacy directive), certificates with expiry and manufacturer.status answer the compliance part of a tender in one run; authorisedRepresentative names the EU counterpart of a non-EU manufacturer.

// npm install apify-client
import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('lwsdjfls/eudamed-device-lookup').call({ udiDis: ['05690977326316', '00733132622610'] });
const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });

for (const { payload } of items) {
    if (payload.kind !== 'device' || payload.status !== 'found') { console.warn(payload.input, payload.status, payload.statusReason); continue; }
    const certs = payload.certificates.map((c) => `${c.number} ${c.status} until ${c.expiresOn} (${c.notifiedBody.name})`).join('; ');
    console.log(`${payload.tradeName} – ${payload.manufacturer.name} (${payload.manufacturer.country}): ${payload.riskClass}, ${payload.legislation}, ${payload.deviceStatus}, registered ${payload.registeredOn}. ${certs || 'no certificate linked'}`);
}

Manufacturers and authorised representatives: the 27 November 2026 registration deadline

A device that was already on the EU market before the UDI/Devices module became mandatory on 28 May 2026 still has to be registered in EUDAMED by 27 November 2026 when further units of the same UDI-DI are placed on the market from 28 May 2026 on, and that includes legacy devices. The date is twelve months after Commission Decision (EU) 2025/2371 confirmed the module's functionality in the Official Journal of 27 November 2025, the period the European Commission's Q&A on the gradual roll-out of EUDAMED gives manufacturers. Two exceptions: a device of which no further units are placed on the market only has to be registered when a post-market surveillance or vigilance action needs it, and a legacy device needs no registration of its own when the same device is already registered under the MDR or IVDR.

A lookup by your SRN lists the devices EUDAMED holds under it today, newest first, up to Maximum devices per search (100 by default, so raise it above your number of devices). Compare the result with your own product list: the devices that are missing are the ones the deadline is about.

Market analysts: what enters the market

A daily feed of new class III vascular implants, or of every new IVDR class D assay, with manufacturer country and notified body.

Notified-body and consultancy intelligence

Manufacturer records list certificates with their notified body; a watch on manufacturers shows NB switches and certificate renewals as they are entered.

How to use it

1. Search by what you have. Put device identifiers into UDI-DIs or Basic UDI-DIs, a manufacturer's registration number into Manufacturer SRNs, or a product name into Product names. You can also sweep a whole category with Risk classes and EMDN codes, which is how procurement teams map a market rather than a device.
2. Start with a handful and look at one record. You get the manufacturer, the authorised representative, the device status, the registration date and, when Include manufacturer certificates is on, the certificates with their notified body. The devices view is the device table and manufacturers groups the same data the other way round.
3. Switch Mode to monitor with a State key and a schedule once you want to follow a market instead of check a device. The monitor reports new registrations and status changes in the categories you follow, which is the signal a competitor watch actually needs.

A category search can be enormous, so Maximum devices per search and Maximum devices per run exist to keep a run and its cost predictable. Class and EMDN sweeps can hold thousands of devices (the class III search in EMDN branch P07 returned 11,942 when it was recorded on 15 September 2026), which is why they are deliberately kept out of the small default input.

Two caveats about the source itself, not about this Actor. EUDAMED is still being filled: not every device on the European market is in it yet, so absence is not evidence that a device is unregistered. And the data is what the manufacturer registered, so treat it as the manufacturer's declaration rather than as a verified fact.

{
  "mode": "lookup",
  "udiDis": ["05690977326316", "00733132622610"],
  "manufacturerSrns": ["DE-MF-000006413"]
}

Input

Field	What it does	Example
mode	lookup delivers every device on every run; monitor delivers a baseline first (charged per device, like a lookup) and later only new devices and changes.	"lookup"
udiDis	Device identifiers, one per line: GS1 (14 digits, check-digit validated), HIBCC (+…), ICCBBA (=…) or IFA.	["05690977326316", "00733132622610"]
basicUdiDis	Device group identifiers; every UDI-DI registered under the group is delivered.	["OSSURTKVNK3ZHP9ZQ"]
manufacturerSrns	Single Registration Numbers. Delivers the manufacturer record (free) with its certificates, and every device registered under the SRN, newest first.	["DE-MF-000006413"]
productNames	Trade-name searches (contains), newest first.	["Unloader"]
riskClasses	Newest devices of a risk class (MDR I, IIa, IIb, III; IVDR A, B, C, D).	["class-iii"]
emdnCodes	EMDN codes or prefixes (P = implantable prosthetics, P07 = vascular implants and stents). Combined with every product name and risk class above.	["P07"]
legislation	Restrict searches to devices registered under one legislation. Changing it on a watch starts a new baseline for its searches.	"any"
onlyOnTheMarket	Skip devices marked as no longer placed on the EU market or not intended for it. Changing it on a watch starts a new baseline for its searches.	false
includeManufacturerCertificates	Adds the notified-body certificates issued to each manufacturer SRN (up to 300).	true
maxDevicesPerSearch	Cap per product name, risk class, EMDN code, Basic UDI-DI or manufacturer, newest first. In monitor mode it must exceed the number of new registrations between two runs.	100
maxDevicesPerRun	Caps the charged device records in one run, baseline records included; watched devices read again do not count (at most 50,000 of those per run).	500
maxChangesPerRun	Monitor mode: caps the charged changes in one run; changes above the cap are delivered by the next run.	200
maxConcurrency	Searches and lookups running at the same time; requests are paced at 8 per second overall and at 2 per second to the Commission data lake, which is hit first for every UDI-DI.	4
webhookUrl	Receives a POST with a summary after each run that delivered new devices or changes; a public URL, stored encrypted.	https://hooks.example.com/eudamed
stateKey	Separates independent monitors. Defaults to the task ID; a new key starts a new baseline.	competitors-2026

{
  "udiDis": ["05690977326316", "00733132622610"],
  "manufacturerSrns": ["DE-MF-000006413"],
  "riskClasses": ["class-iii"],
  "emdnCodes": ["P07"],
  "maxDevicesPerSearch": 100
}

UDI-DIs are check-digit validated when they are GS1 codes. Searches (product name, risk class, EMDN code, Basic UDI-DI, manufacturer) return the newest devices first, up to maxDevicesPerSearch each; legislation and onlyOnTheMarket narrow every search. EMDN codes combine with every product name and risk class given (class III × P07 = the newest vascular implants and stents); on their own they are a search per code. An EMDN code must be a letter followed by pairs of digits (P, P07, A060204). A code in another form is ignored without a message; when no valid code is left, a risk class or product name given with it is searched without the EMDN filter.

Monitor mode:

{
  "mode": "monitor",
  "manufacturerSrns": ["DE-MF-000006413", "IS-MF-000000173"],
  "riskClasses": ["class-iii"],
  "emdnCodes": ["P07"],
  "legislation": "mdr",
  "maxDevicesPerSearch": 600,
  "webhookUrl": "https://hooks.example.com/eudamed"
}

Output

One record per device (and one per manufacturer). In monitor mode, one record per new device or change with structured changes and a summary.

• status: found, not-found, invalid-identifier (wrong GS1 check digit) or lookup-failed (EUDAMED did not answer completely, or the run neared its timeout before it got to this input or device, which statusReason says; nothing charged)
• Identification: udiDi, issuingAgency (GS1, HIBCC, ICCBBA, IFA), basicUdiDi, tradeName, deviceName, model, reference, description
• Classification: riskClass (I, IIa, IIb, III; IVDR A–D), legislation (MDR, IVDR or a legacy directive) with legacyDevice, specialDeviceType (software, contact lenses…), emdn codes with names, systemOrProcedurePack
• Status: deviceStatus (on the EU market, no longer placed, not intended for the EU), statusSince, registeredOn (first version), lastUpdatedOn, versionNumber, discardedOn, placedOnTheMarketIn, availableIn (member states)
• Characteristics: sterile, singleUse, reusable, implantable, active, measuringFunction, latex, cmrSubstance
• manufacturer: SRN, name, country, EUDAMED status, address; authorisedRepresentative for non-EU manufacturers with mandate status
• certificates: every certificate EUDAMED links to the device group: number, type (MDR QMS, EU technical documentation, legacy MDD Annex II…), status with its EUDAMED code (statusCode), issue and expiry dates, and the notifiedBody (number and name); notifiedBodies as a distinct list
• sourceUrl to the record in EUDAMED, and sourceCheckedAt

Manufacturer SRNs additionally deliver a manufacturer record, free of charge: name, role, EUDAMED status, country, address, VAT and EORI numbers, website, authorised representatives with mandate dates, the number of registered devices, and the certificates issued to the SRN with their notified bodies.

Device details, certificates and searches come from the live database and are as current as EUDAMED itself; UDI-DI resolution uses the Commission's nightly snapshot first and falls back to the live search for devices registered in the last day.

{
  "envelopeVersion": 1,
  "id": "05690977326316",
  "scope": "lookup:udi:05690977326316",
  "changeType": "added",
  "sourceUrl": "https://ec.europa.eu/tools/eudamed/#/screen/search-device/4ba04706-ea39-4924-9f79-addd38aec119",
  "scrapedAt": "2026-09-15T14:00:00.000Z",
  "firstSeenAt": "2026-09-15T14:00:00.000Z",
  "hash": "e9b54bb6cfb00182cce72bdada41a8497b248f3655b97abdb8eb3d61c3d55d52",
  "previousHash": null,
  "changes": [],
  "summary": "Added: Unloader One® (05690977326316) – Össur Iceland ehf.",
  "diffText": null,
  "payload": {
    "kind": "device",
    "input": "05690977326316",
    "inputType": "udi-di",
    "status": "found",
    "statusReason": null,
    "udiDi": "05690977326316",
    "issuingAgency": "GS1",
    "basicUdiDi": "5690967BU00037NG",
    "tradeName": "Unloader One®",
    "deviceName": null,
    "model": "BU00037",
    "reference": "B-241519712",
    "description": null,
    "riskClass": "Class I",
    "riskClassCode": "refdata.risk-class.class-i",
    "legislation": "MDR (Regulation (EU) 2017/745)",
    "legislationCode": "refdata.applicable-legislation.mdr",
    "legacyDevice": false,
    "specialDeviceType": null,
    "emdn": [
      {
        "code": "Y061209",
        "name": "KNEE ORTHOSES"
      }
    ],
    "deviceStatus": "On the EU market",
    "deviceStatusCode": "refdata.device-model-status.on-the-market",
    "statusSince": "2026-05-27",
    "registeredOn": "2026-05-27",
    "lastUpdatedOn": "2026-05-27",
    "versionNumber": 1,
    "basicUdiVersionNumber": 1,
    "discardedOn": null,
    "placedOnTheMarketIn": "Netherlands",
    "availableIn": [
      "NL"
    ],
    "sterile": false,
    "singleUse": false,
    "reusable": false,
    "implantable": false,
    "active": false,
    "measuringFunction": false,
    "latex": false,
    "cmrSubstance": false,
    "systemOrProcedurePack": null,
    "manufacturer": {
      "srn": "IS-MF-000000173",
      "name": "Össur Iceland ehf.",
      "country": "Iceland",
      "countryCode": "IS",
      "status": "Active",
      "statusCode": "refdata.actor-status.active",
      "address": "5 Grjótháls 110 Reykjavík"
    },
    "authorisedRepresentative": null,
    "certificates": [],
    "notifiedBodies": [],
    "sourceUrl": "https://ec.europa.eu/tools/eudamed/#/screen/search-device/4ba04706-ea39-4924-9f79-addd38aec119",
    "sourceCheckedAt": "2026-09-15T14:00:00.000Z"
  }
}

Pricing

Event	Name	What it means	Price
apify-actor-start	Actor start	Charged by Apify when a run starts: once for a run of up to 1 GB of memory, and once more for every extra GB. It covers the first five seconds of compute.	$0.00005 per run up to 1 GB of memory ($0.05 per 1,000)
device-delivered (primary)	Device delivered	One device (UDI-DI) delivered with identification, manufacturer, authorised representative, risk class, legislation, status, registration date, EMDN code and certificates with notified body. In monitor mode: each device of the first run of a watch (baseline) and each device the watch finds later.	$0.05 per device ($50.00 per 1,000)
change-detected	Change detected	In monitor mode: a device already in your watch whose status, certificates, manufacturer, authorised representative or identification changed, or that disappeared from EUDAMED. At most "Maximum changes per run" per run.	$0.50 per change ($500.00 per 1,000)

These are list prices, which the Free plan pays. Paid Apify plans pay less for every event except the Actor start: 5% on Apify's Bronze tier, 10% on Silver and 15% on Gold and higher.

The first example input under Input (two UDI-DIs, manufacturer DE-MF-000006413 and the newest 100 class III devices in EMDN branch P07) costs $5.30005. On 15 September 2026 the manufacturer had 4 devices and the class III P07 search held 11,942, so the run delivers 2 + 4 + 100 = 106 device records at $0.05 each, which is $5.30, plus $0.00005 for the start. The manufacturer record is free. A device that two of your searches return is charged once per search: 00733132622610 is itself a class III P07 device, so on 15 September 2026 it came back from its UDI-DI and from the search, 2 records and $0.10. The input under How to use it, which the Console form also opens with (there with Maximum devices per search set to 5), delivered 6 devices on 21 September 2026: $0.30, plus $0.00005 for the start, so $0.30005 for the run.

A competitor portfolio of 500 devices costs $25 once, in a lookup or as a watch's baseline, and then $0.50 per change, with maxChangesPerRun (default 200) as the ceiling of one run. A risk-class or EMDN feed starts with a baseline of up to maxDevicesPerSearch devices ($5.00 at the default 100). After that it costs $0.05 for each new device and $0.50 for each change to a device on the newest pages it reads again. A day with neither costs only the start.

With the default limits, one run costs at most $25.00005 in lookup mode: 500 devices (maxDevicesPerRun) at $0.05 each is $25.00, plus one start event of $0.00005 at the default 512 MB of memory. In monitor mode, add 200 changes (maxChangesPerRun) at $0.50 each, which is $100.00, for at most $125.00005 per run. Raise a limit and the ceiling rises with it.

To put a hard ceiling on a run, set a maximum cost per run in the run options in Apify Console. The Actor stops delivering and charging before the next device or change would go over it, and a watch reports what was left over in its next run.

A watched device whose first lookup failed, or a watched UDI-DI that EUDAMED did not know yet, is priced as a device when it is found, not as a change.

A search that suddenly answers without a single device, while the watch knows devices from it, is treated as an outage and not as a withdrawal of everything it holds: the run reports nothing as removed, nothing is charged for that search, and the log says which search it was. The same holds for a watched UDI-DI that neither EUDAMED's public API nor its search returns any more: its last known state is kept, and the change is reported once EUDAMED answers again. EUDAMED keeps a withdrawn device with a status rather than deleting it, so a real withdrawal arrives as a changed record.

When EUDAMED does not answer, each request is tried up to four times. The requests a search, a manufacturer or a UDI-DI cannot do without (a search page, the manufacturer's register entry, public record and certificates, and the live search when it is the last source for a UDI-DI) then get one patient try per run: the run waits for EUDAMED for up to 10 minutes, and never past the time it needs to deliver, before that search or lookup fails without a charge. A run with a timeout also leaves free the time of the wait's last try and of the lookups and searches still waiting to start. It counts those at its own pace once it has read a device or a search page, but never faster than EUDAMED's usual pace of 8.5 seconds a step, and before that at six times that pace, because a server that fails tends to be slow as well. When that leaves less than a minute to wait, it does not wait, and the request fails after its four tries. A device that still cannot be read is delivered as lookup-failed, free.

Records are delivered once everything is collected, and delivering takes a tenth of a second per record. The run stops working before its timeout, keeping a fifth of the time left (at most two minutes) to save its state, and before that it sets aside the time to deliver every record it holds or will deliver: in a lookup, one for each UDI-DI, SRN or search not yet done, and in any run as many records as a search page can bring, from the moment the page is asked for. It starts no further lookup, search page or device read once the time left besides the time to deliver is shorter than a step takes in this run (the median of the last 25 device reads and search pages it has done, 8.5 seconds until it has done one) or than 15 seconds, whichever is less, and a lookup checks the same before each further step (a UDI-DI before the live search and before its device, an SRN before its operator record and before its certificates). A request keeps its usual 90 seconds and four tries while they fit before the run stops working. A try after a timeout, or after the pause a server asked for, may start until 10 seconds before that point, as long as the delivery of what the run holds fits in half of the time kept to save the state; a run that holds more starts a try only while a whole try still ends in time to deliver. Nearer the end a try gets the time left as its timeout (at least 15 seconds). A request that hangs therefore ends at most about 15 seconds late, within the time kept to save the state, and what it was for counts as left out, not as failed. A server that asks to wait more than a minute before the next try fails the request as it does without a timeout. In a lookup, each UDI-DI or SRN the run did not look up, each search it did not start and each device it found but did not read is delivered as a free lookup-failed record whose statusReason says so. A search stopped before its last page delivers what it read, and one more free lookup-failed record, in the scope lookup:not-started:…, that says after how many of its devices it stopped; a manufacturer whose devices were not searched comes without deviceCount, and its statusReason says so. Submit those again, or raise the timeout in the run options. A watch leaves what it did not reach as it was, reports none of it as removed, and checks it in the next run. A first check it could not finish, also the first after a change of legislation or onlyOnTheMarket, is not saved or charged at all, so the next run takes that baseline in full instead of reporting the devices not reached as added; a first check larger than one run can read is therefore never saved, so give it a longer timeout, or lower Maximum devices per search or Maximum devices per run, which save the part they cover. The same holds for a product-name, risk-class or EMDN feed the run could not read up to the devices the watch already knows, and for a search whose first page it did not read: a feed is read each run only until a page holds no new device, so saved in part, the new devices after the part read would never be reported. A feed with more new devices than one run can read is therefore never saved either, so give that run a longer timeout. The log says how many lookups, searches and devices were left out, and the run's status message counts the inputs not processed.

The default run timeout is 24 hours. A local test run on 15 September 2026 read 106 devices in 224.5 seconds, four at a time; at that pace the 50,000 devices one run delivers at most take about 15 hours to read with Parallel lookups at 8, and a watch that also reads 50,000 stored devices again needs more than 24 hours, so split such a watch. A caller can set another timeout in the run options.

A record that says an input was left out takes as long to deliver as any other, so a list is delivered in full only when the timeout leaves time for one record per input: 10,000 UDI-DIs need 1,000 seconds for delivery alone, and a run of 10 minutes on them ends TIMED-OUT with part of those free records delivered and nothing charged but the start. Looking them up takes longer still: the Actor asks the Commission data lake, its first source for every UDI-DI, at most 2 times a second, so 10,000 UDI-DIs need more than 6,120 seconds (5,000 for the data lake, 1,000 to deliver and two minutes to save the state). Give a long list that timeout in the run options, or split it over several runs.

Not charged: manufacturer records, devices EUDAMED does not know, invalid identifiers, lookups that failed halfway, what a run had no time left to look up, search or read, and unchanged devices in a watch, including new EUDAMED versions that change nothing a watch compares (links, the last-update date, wording next to a code).

FAQ

UDI-DI, Basic UDI-DI, SRN: which identifier do I use?

The UDI-DI is the identifier on the label of one device model (GS1 GTIN, HIBCC or ICCBBA code). The Basic UDI-DI groups models with the same intended purpose and design; certificates refer to it. The SRN identifies a manufacturer, authorised representative, importer or producer in EUDAMED (DE-MF-000006413). Any of them works; the UDI-DI is the precise one.

Why does a device I know is on the market come back as not found?

Registration is mandatory for devices placed on the market from 28 May 2026; legacy devices already on the market have until November 2026. A device may also be registered under a different issuing agency's format than the one you typed (HIBCC codes start with +, ICCBBA with =). Try the manufacturer's SRN or the trade name.

Why is a certificate missing from a device that certainly has one?

EUDAMED links certificates to the device group (Basic UDI-DI) only when the notified body entered that scope; the manufacturer record lists every certificate issued to the SRN regardless. Legacy (MDD/IVDD) devices can show no certificate at all.

Can I export a whole risk class?

Set maxDevicesPerSearch and maxDevicesPerRun high enough, at $0.05 per device. Whatever the settings, one search delivers at most 20,000 devices (the maximum of maxDevicesPerSearch, $1,000) and one run at most 50,000 (the maximum of maxDevicesPerRun, $2,500). For anything above a few thousand devices, split by EMDN branch across several runs, or give the run a longer timeout in the run options; requests are paced at 8 per second overall and at 2 per second to the Commission data lake. A run that nears its timeout stops reading and delivers what it has read, with a free record for each search it stopped (see Pricing). Monitor mode is no cheaper way to export: its baseline costs the same per device.

Is reusing EUDAMED data legal, and is it GDPR-compliant?

The registers are public information published by the European Commission under Regulation (EU) 2017/745 for exactly this transparency purpose, reusable under CC BY 4.0 with attribution. EUDAMED's public actor data includes e-mail addresses, telephone numbers and the names of the persons responsible for regulatory compliance; the Actor does not read those fields, so no contact person reaches a record. A manufacturer that is a sole trader can still have a registered name and address that belong to a natural person, so treat the output as company data rather than as data the GDPR cannot touch. It is not affiliated with the European Commission; regulatory conclusions remain yours.

Related Actors

• ECHA REACH Lookup: SVHC candidate list, Annex XIV and Annex XVII status per substance, with the same daily monitor for list additions.
• EU Company ID Resolver for manufacturers and authorised representatives: VAT, KvK, KBO, SIREN and LEI with official name and status.

Support

Found a bug or need a feature? Open an issue on the Actor page.

Last live run against EUDAMED and the DG SANTE data lake: 21 September 2026, with the input the Console form opens with.