GET in the API is a paginated list endpoint. They all behave the
same way: cursor and limit go in as query parameters, a
{ data, next_cursor } envelope comes back.
The envelope
data— the items on this page, at mostlimitof them.next_cursor— pass it back ascursorto get the next page. It isnullon the last page, and that is the only reliable end-of-collection signal: a page can be full and still be the last one.
Walking a collection
Request the first page without acursor, then keep feeding next_cursor back
until it comes back null:
limit and any filters identical across the pages of one walk. A cursor
belongs to the query that produced it; changing the query mid-walk gives you
undefined coverage.
Parameters
A
cursor the API cannot decode, or a limit out of range, is rejected with
422 (err_not_valid). See Errors.
Ordering
Items come back in a stable order, so walking a collection that is not changing underneath you visits every item exactly once. The order is an implementation detail — it is not a meaningful sort, so do not rely on it to present data or to infer recency. Entities created or deleted while a walk is in progress may or may not appear in it.Filtering by your own codes
Each list endpoint takes an optionalexternal_id filter. This is how you resolve
one of your own codes to an Emidat id:
external_id is unique per entity type within your manufacturer, so data
holds at most one item; an empty data means no active entity carries that code.
See External IDs.