The Endpoint
EUDAMED exposes actor data, meaning manufacturers, authorised representatives, importers and other economic operators registered in the system, through a public REST endpoint that needs no authentication:
https://api.datalake.sante.service.ec.europa.eu/eudamed/actors?format=json&api-version=v1.0
Filters are added as extra query parameters on top of that base URL, for example a NAME, an ACTOR_ID, or an ACT_COUNTRY_ISO2_CODE. The examples below all query that same live endpoint.
A note on the examples. They use real entries because a claim you cannot re-run is not evidence, and every query below can be repeated against the live endpoint by anyone. Each one describes how the interface behaves, not how any company keeps its data. Nothing here is a statement about the registrations, the compliance or the data quality of the organisations whose public records the queries happen to return, and the names of individuals the endpoint publishes are deliberately not reproduced.
A Row Is Not a Company
The most common mistake is treating one row in the actors response as one company. It is not. EUDAMED denormalises the actor record: the response holds one row per person responsible for regulatory compliance named against that actor, not one row per legal entity.
Querying ACTOR_ID=US-MF-000019977 returns 14 rows. Every one of them carries VERSION 27.0, and every one of them describes the same company. The 14 rows are not 14 different actors; they are 14 different named contacts attached to one manufacturer.
This is easy to miss on a small sample. Pull an unfiltered page of 1,000 rows and it holds 999 distinct ACTOR_ID values, close enough to one row per company that a quick sanity check passes. The distortion only shows up on manufacturers large enough to have several people named against their compliance contact, and those are exactly the manufacturers a portfolio-wide count is trying to measure.
Name Search Is Exact, and a Miss Looks Like Success
The second behavior is in how the NAME filter matches. It requires the exact, full registered name, not a partial or fuzzy match, and a query that does not match still returns an ordinary HTTP 200 response with zero rows, the same status code a successful query gets.
NAME=Medtronic returns zero rows. NAME=Medtronic, Inc., the exact registered name including the comma and the suffix, returns 17. ABBREVIATED_NAME=Medtronic also returns zero. So does ACTOR_TYPE=MF used on its own as a filter, which suggests that parameter does not narrow results the way its name implies on this endpoint.
The public EUDAMED website, by contrast, does substring matching on actor name: typing "Medtronic" into the search box there finds the company. The API and the website are two official interfaces to the same register, and they disagree with each other on how a name search behaves.
A Hard Cap of 1,000 Rows, No Paging
The third behavior is a row limit with no way past it on this endpoint. ACT_COUNTRY_ISO2_CODE=DE returns exactly 1,000 rows, the ceiling, not the true count of German actor records. There is no paging parameter on this endpoint to retrieve row 1,001 onward.
That makes any attempt to enumerate a full country, or any filter broad enough to match more than 1,000 rows, silently truncated. The response looks complete: well-formed JSON, HTTP 200, and nothing in the payload flags that more rows exist beyond the cap. A count or export claiming to cover "all devices" or "all actors" in a broad category built on this endpoint is only as complete as 1,000 rows allow.
Named Individuals in an Anonymous Endpoint
One more property of this dataset is worth stating plainly. The rows returned by this endpoint carry the first and last name of the person responsible for regulatory compliance at each actor, and no account, login, or API key is required to query it. Named individuals are published through what is otherwise an anonymous, unauthenticated endpoint.
What to Do With This
None of the three behaviors above is likely to change on request, since each one follows from how the underlying data is modeled and exposed. What a reader, or a tool built on this endpoint, can control is how the response gets read:
- Collapse rows on
ACTOR_IDbefore counting anything. A row count and a company count are two different numbers on this endpoint. - Treat an empty
NAMEresult as no exact match for that string, not as proof the actor is not registered. Retry with the exact registered name, including punctuation and legal suffix, before concluding it is missing. - Check whether a response landed exactly on 1,000 rows. If it did, the true count is unknown, not 1,000.
- Re-verify periodically. These are properties of a server the European Commission operates, not of EUDAMate, and they can change without notice.
EUDAMate applies these same checks internally when it looks up whether a customer's SRN is registered, rather than trusting a raw row count or an empty name match at face value.
How This Was Verified
Every behavior above was re-verified live against the endpoint on September 17, 2026, by a script in EUDAMate's backend repository, scripts/verify-eudamed-actors.mjs. All six checks in that script, covering the queries listed below, held on that date.
| Query | Result |
|---|---|
ACTOR_ID=US-MF-000019977 | 14 rows, all VERSION 27.0, one company |
NAME=Medtronic | 0 rows, HTTP 200 |
NAME=Medtronic, Inc. | 17 rows |
ABBREVIATED_NAME=Medtronic | 0 rows |
ACTOR_TYPE=MF | 0 rows |
ACT_COUNTRY_ISO2_CODE=DE | 1,000 rows, the cap |
This is not a one-time finding. The endpoint belongs to the European Commission, not to EUDAMate, and its behavior can change the next time EUDAMED ships a release. The verification script gets re-run rather than trusted from memory, and this page will be updated if a future run finds a different result.
The three behaviors above come from the endpoint's actual responses, not from documentation describing what it should do. A tool that queries this API, or a person reading its output by hand, gets a correct answer only by accounting for how EUDAMED denormalises rows, matches names, and caps page size, not by trusting the field names at face value.
Frequently Asked Questions
Does one row in the EUDAMED actors API response equal one company?
No. The endpoint returns one row per person responsible for regulatory compliance named against an actor, not one row per legal entity. Querying ACTOR_ID=US-MF-000019977 returns 14 rows, all VERSION 27.0, all describing the same company. An unfiltered 1,000-row page holds 999 distinct ACTOR_ID values, which is why a quick test can look close to one row per company when it is not.
Why does a NAME search on the API return zero results for a company that is definitely registered?
The NAME filter on this endpoint requires an exact match to the registered name, not a partial one, and a query that finds nothing still returns an ordinary HTTP 200 response with zero rows. NAME=Medtronic returns 0 rows; NAME=Medtronic, Inc., the exact registered name, returns 17. ABBREVIATED_NAME=Medtronic and ACTOR_TYPE=MF used alone both return 0 as well. The public EUDAMED website search does substring matching on the same underlying data, so the two official interfaces behave differently on the same query.
How many rows can this endpoint return in one response?
1,000, with no paging parameter on this endpoint to retrieve rows beyond that. ACT_COUNTRY_ISO2_CODE=DE returns exactly 1,000 rows. A response that lands exactly on 1,000 has been truncated at the cap, not completed.
Does the EUDAMED actors API require authentication?
No. The endpoint is public and needs no login or API key, and its rows carry the first and last name of the person responsible for regulatory compliance at each actor, so those names are published through an unauthenticated public endpoint.
When was this checked, and could it change?
All six behaviors described on this page were re-verified live against the endpoint on September 17, 2026, using a script in EUDAMate's own backend repository. The endpoint belongs to the European Commission, not to EUDAMate, so its behavior can change without notice; this page reflects a specific verification date and is checked again periodically rather than assumed to hold indefinitely.