---
description: "Use CakePHP page parameters and the supported resource filters."
group: "API fundamentals"
order: 8
---

# Pagination and filtering

Use CakePHP page parameters and the supported resource filters.

The ordinary order and attendee lists use CakePHP page parameters. Bulk snapshot resources use fixed row limits and do not provide cursor pagination.

## Request another page {#request-another-page}

Supply the standard `page` query parameter. Start at page 1, process all returned records, and move to the next page. Orders normally return up to 50 rows; attendees return up to 100.

```curl
curl --user "$PAYDRO_EMAIL:$PAYDRO_PASSWORD" \
  --header 'Accept: application/json' \
  "$PAYDRO_ORIGIN/$EVENT_ID/orders/index/all.json?page=2"
```

Stop after a short page. A page beyond the last available page can produce a legacy redirect/error instead of a clean empty array. If the final page is exactly full, handle that response explicitly. These lists do not include a standardized total or next cursor envelope.

## Choose a filter {#choose-a-filter}

Order filters in the path include `all`, `recent`, `failed`, `pi` (paid invoices), `upi` (unpaid invoices), `op` (online payments), `nco` (not cancelled), `co` (cancelled), `unfinished`, and `reservation`.

Attendee filters include `index`, `recent`, and `deleted`. Add `include=scan` for scan status. Product and promocode filters require a second ID segment; use the exact operation path when your integration needs them.

## Know the bulk limits {#know-the-bulk-limits}

Order snapshots cap the combined accessible order history at 75,000 rows, ordered by order creation descending. Attendee snapshots cap each event at 10,000 rows. These responses have no next cursor. Use paginated reads for larger datasets and contact support before relying on a snapshot near its cap.