Pagination
Bounded UUID cursors for patient, result and observation collections.
Request a page
Collection endpoints accept limit and after. Results also accept the patientId filter. Unknown or malformed query parameters return 400.
| Parameter | Meaning |
|---|---|
limit | Integer from 1 to 100; defaults to 20 |
after | UUID of the last returned resource from the previous page; omit for the first page |
Resources are ordered by immutable UUID, ascending. A response contains data and a required nextCursor that is either a UUID or null. There is no total count.
Continue until the cursor is null
The following response is an empty synthetic page, with no patient data:
{
"data": [],
"nextCursor": null
}When nextCursor contains a UUID, pass it as after in the next request. Keep your endpoint and filters unchanged. For example, this illustrative path uses a synthetic UUID:
/v1/results?limit=20&after=00000000-0000-4000-8000-000000000001The observations collection has its own cursor: use its final-row UUID, rather than the result’s UUID. Stop when nextCursor is null.
A cursor is not a snapshot
A cursor is a position in the collection, not an authorization capability or a snapshot of an export. Data can change between requests. A newly approved result can sort before a cursor that your integration has already passed. Design periodic reconciliation for your use case; cursor progression alone is not a change feed.
Every page independently validates the key, clinic and scope. Revoked or expired credentials cannot continue an earlier read.