Pagination

List endpoints (GET /api/v1/orders, GET /api/v1/subscriptions, GET /api/v1/payments, GET /api/v1/webhooks, GET /api/v1/accounts/{id}/invoices, GET /api/v1/accounts/{id}/subscriptions, GET /api/v1/accounts/{id}/payment-methods) return arrays inside the data field together with a nextActions array.

{
  "data": [ /* items */ ],
  "nextActions": [ /* ... */ ]
}

Current behavior

The Agent API returns the full result set scoped to your tenant in a single response. There is no limit/cursor query parameter today and no meta.nextCursor in the response — list calls are intended for modest catalogs and short operational windows.

If a list endpoint accepts filters (for example, accountId on GET /api/v1/subscriptions), use them to narrow the result set before paging is needed.

Recommendations for large tenants

• Use filters on list endpoints whenever possible to keep responses focused (e.g. ?status=active, ?accountId=...).

• For point-in-time work, fetch a list once and process the array client-side rather than re-fetching frequently.

• For change-detection, prefer webhooks over polling — they push events as soon as they happen.

Heads up: explicit cursor pagination is on the roadmap. When it ships, list endpoints will start accepting limit/cursor parameters and will return a meta.nextCursor field — both additive changes that won't break clients written against today's response shape.

Ordering

Items are generally returned ordered by createdAt descending (newest first). Items with identical timestamps may appear in any order between calls, so don't rely on a strict tiebreaker — use the resource id if you need a stable client-side sort.

Related

• Errors

• Rate limits

• Webhooks