Pagination and filtering

List endpoints use one of four patterns, depending on how the list is consumed. Each is bounded: every paged list has a default and a maximum page size.

Pattern	Used by	How to page
Sequence	`GET /oms-ops/events`	Pass the highest `seq` you processed as `afterSeq`. Events come in ascending sequence order. Default 200, maximum 1000 per call.
Cursor	`GET /oms-ops/disruptions`	Pass the `nextCursor` of the previous page as `cursor`. Newest first. Default 50, maximum 200.
Offset	`GET /oms-ops/mass-changes`, `GET /oms-ops/mass-changes/{id}/items`, `GET /oms-ops/work-items`	`limit` and `offset`; the response carries `total`. Defaults 50 (items 200), maxima 200 (items 1000).
Bounded list	`GET /order-orchestration/trips`, `GET /order-orchestration/events`	`limit` only, newest first. Trips: default 50, maximum 200. Integration log: default 100, maximum 500.

These lists return every match without paging, because their size is bounded by the business object they belong to: the configuration views (systems, rules, event-types, status-models), a trip's lines and marks, a disruption's mass changes, a customer's service-recovery cases, group agreements, travel parties, block requests and party quotes.

Filtering

Filters are query parameters, applied on the server:

Endpoint	Filters
`GET /order-orchestration/trips`	`customerRef`
`GET /order-orchestration/events`	`tripId`, `outcome`
`GET /oms-ops/events`	`type`, `subjectRef`
`GET /oms-ops/disruptions`	`status`
`GET /oms-ops/mass-changes`	`status` (comma-separated), `disruptionId`
`GET /oms-ops/mass-changes/{id}/items`	`status`, `outcome`, `market`, `channel`
`GET /oms-ops/work-items`	`team`, `status`, `reason`, `changeId`
`GET /group-agreements`	`state`, `agreementType`, `seriesRef`, `asOf`
`GET /travel-parties`	`tripId`

Not available

Cursor pagination on every list, and paging on the trip list beyond the newest 200, are not available. See Availability.

Filtering​

Filtering