Pagination
Management list endpoints use cursor pagination. A list response has a data
array and a next_cursor value. Pass next_cursor back as cursor to fetch the
next page.
| Operation | operationId | Query params | Response fields |
|---|---|---|---|
| GET /v1/classes | managementListClasses | cursor, limit |
data, next_cursor |
| GET /v1/members | managementListMembers | cursor, limit |
data, next_cursor |
| GET /v1/schedule | managementListSchedule | cursor, limit |
data, next_cursor |
Request parameters
GET /v1/classes?limit=50&cursor=eyJpZCI6...
limit controls page size. The service clamps invalid or oversized values. The
current implementation defaults to 25 and caps pages at 100.
cursor is opaque. Do not parse it, persist assumptions about its format, or
modify it. Store it only as a string and send it back exactly as received.
Response shape
{
"data": [],
"next_cursor": null
}
When next_cursor is null, there are no more pages. New or changed records may
appear between requests, so sync jobs should process records idempotently on their
own side as well.