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

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 --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

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

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.