Paginate a Result Set
Walk through multi-page results using page and size parameters
The GET /events endpoint (and other list endpoints) supports pagination via the size parameter. The effective maximum page size is 2000 records.
Until 1 November 2026, an oversized size is silently capped — after that it is rejected.
Today a size larger than 2000 is not rejected: the request returns 200 OK with only the first 2000 items — no error, no truncation flag. A single size=999999 call therefore silently drops everything past the first 2000, and you cannot tell from the response that data is missing.
From 1 November 2026 the same request is rejected with 400 Bad Request instead of being silently truncated (see below). Either way the fix is the same: paginate through the full result set with size ≤ 2000 — never rely on one huge request.
Maximum page size and the 400 cutover
The maximum page size is 2000. It applies to the root collection endpoints:
GET /events, GET /locations, GET /routes, GET /eventgroups, and GET /venues.
From 1 November 2026 (Europe/Amsterdam), a request to one of these endpoints with size greater than 2000 is rejected:
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"status": 400,
"error": "Bad Request",
"message": "size must not exceed 2000 (requested: 999999)"
}Before that date the request still returns 200 OK capped to the first 2000 items (the silent behaviour above), so you can fix integrations ahead of the cutover without anything breaking yet.
Detail reads such as GET /events/{id} are unaffected — the limit applies only to the list endpoints above. The limit is not applied to the internal export endpoints.
What to do: page through results with size ≤ 2000 (see below), or — if you are keeping your own datastore in step — switch to an incremental lastupdated sync, which pulls only what changed in small pages and never needs a large size.
Basic Pagination
Use size to control how many results are returned per request. To walk through pages, combine size with an offset or page-based approach depending on your needs.
# First page: 20 results
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
"https://app.eventconnectors.nl/api/events?size=20&published=true"async function fetchEvents(page, pageSize = 20) {
const params = new URLSearchParams({
size: String(pageSize),
published: "true",
});
const response = await fetch(
`https://app.eventconnectors.nl/api/events?${params}`,
{ headers: { Authorization: "Bearer YOUR_API_TOKEN" } }
);
return response.json();
}
// Fetch the first page
const firstPage = await fetchEvents(1);Walking Through All Results
To iterate through all events, fetch pages until you receive fewer results than your page size:
# Page through with size parameter
# Adjust sortField to ensure consistent ordering
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
"https://app.eventconnectors.nl/api/events?size=100&sortField=lastupdated&sortOrder=DESC&published=true"async function fetchAllEvents(pageSize = 100) {
const allEvents = [];
let lastUpdated = null;
while (true) {
const params = new URLSearchParams({
size: String(pageSize),
sortField: "lastupdated",
sortOrder: "DESC",
published: "true",
});
if (lastUpdated) {
params.set("lastupdated", lastUpdated);
}
const response = await fetch(
`https://app.eventconnectors.nl/api/events?${params}`,
{ headers: { Authorization: "Bearer YOUR_API_TOKEN" } }
);
const events = await response.json();
if (!Array.isArray(events) || events.length === 0) break;
allEvents.push(...events);
if (events.length < pageSize) break;
// Use the last event's timestamp for the next page
lastUpdated = events[events.length - 1].lastupdated;
}
return allEvents;
}Sorting
Use sortField and sortOrder to control result ordering:
| Parameter | Values | Default |
|---|---|---|
sortField | Any root-level field (e.g., lastupdated, creationdate, title) | lastupdated |
sortOrder | ASC, DESC | DESC |
Consistent sorting is important for reliable pagination — always specify a sort field when paginating.
See the API Reference for the full list of query parameters.