All list endpoints use cursor-based pagination. This is more reliable than offset-based pagination: insertions and deletions don’t cause skipped or duplicated records.Documentation Index
Fetch the complete documentation index at: https://docs.propal.io/llms.txt
Use this file to discover all available pages before exploring further.
Request parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
limit | integer | 25 | Number of items to return. Min: 1, max: 100. |
after | string | — | Cursor from a previous response. Fetch the next page starting after this cursor. |
Response format
Every list endpoint returns the same pagination structure:| Field | Type | Description |
|---|---|---|
has_more | boolean | true if there are more items after this page. |
next_cursor | string | null | Opaque cursor to pass as the after parameter for the next page. null when on the last page. |
total_count | integer | Total number of items matching your query (across all pages). |
Paginating through all results
Filtering and sorting
List endpoints support filters via query parameters. Filters are combined with pagination:Cursors are opaque strings. Don’t try to decode, modify, or construct them manually. Always use the
next_cursor value returned by the API.Best practices
- Use the largest
limityou need. Fewer requests = fewer rate limit tokens consumed. Uselimit=100for bulk operations. - Stop when
has_moreisfalse. Don’t make an extra request — the API tells you when you’ve reached the end. - Use
total_countfor progress. Display progress bars or “showing X of Y” indicators usingtotal_count.