API, SDKs & AI assistants

Pagination is endpoint-specific. Follow the pagination model documented for each endpoint; do not send page to a cursor- or offset-based endpoint.

Page-based lists such as GET /v1/services use page and limit, with page, pageSize, total and pages in the response. Example: GET /v1/services?page=2&limit=50. Stop when page >= pages or items is empty.

Cursor-based lists such as GET /v1/api-credentials use limit and cursor. Pass the returned next_cursor unchanged on the next request; null means finished.

Offset-based lists such as GET /v1/products and GET /v1/dns/zones?view=summary use limit and offset. Use the returned next_offset; null means finished. DNS zone summary has its own default limit, while the default legacy view is not paginated.

limit is the canonical page-size parameter. Deprecated page_size and pageSize request aliases are retained only on endpoints that explicitly document them; supplied size values must match. Defaults and maximum sizes are endpoint-specific. Page-based responses retain pageSize for compatibility.

GET /v1/services applies ownership, status, type, search, external_id and label filters server-side before pagination and counts. Default states are active and suspended; historical services require an explicit status selection. group_by=type groups only the current page. GET /v1/services/grouped returns the complete inventory under its documented status/type filters, without pagination; its legacy compatibility default is active only; MCP/automation clients should pass status explicitly and prefer the paginated service endpoint with statuses=active,suspended.