Querying
List endpoints support pagination and, where documented, filters, sorting and field selection. Each endpoint's Query Parameters section defines the parameters it accepts, their defaults and any company or agency restrictions.
Pagination
| Parameter | Purpose | Default | Allowed values |
|---|---|---|---|
page | Page number, starting at 1 | 1 | Positive integer |
limit | Records per page | 50 | Positive integer, capped at 200 |
Paginated responses include meta.page, meta.limit and meta.total. To retrieve the next page, increment page and keep the filters, page size and sort settings unchanged. Stop when the page is empty or page × limit reaches meta.total.
Pagination is not a snapshot. Records created or updated during a multi-page fetch can affect page boundaries. List queries use record IDs to break ties between equal sort values, but your integration should still handle repeated records when refreshing a changing dataset.
Summary endpoints use a group limit rather than list pagination: they return at most 500 groups, without a page or continuation token. See the relevant summary reference for its meta.total meaning and aggregation rules.
Filters
Only send filters documented by the endpoint. Filters such as status, query, from and to have resource-specific meanings; they are not a universal set of supported parameters.
Company access
On endpoints that support company, omitting it queries the companies available to the API key. Specifying it narrows that access. Agency-scoped keys remain restricted to their agencies and connected companies.
Company identifiers can be 24-character hexadecimal IDs or 10-character IDs containing letters, numbers, _ or -. Malformed company identifiers return 400 BAD_REQUEST. Valid identifiers that do not exist or are outside the key's access return 404 NOT_FOUND.
Multiple IDs
Where an endpoint supports multiple IDs, use comma-separated values, repeated parameters, or both:
project=<PROJECT_ID_1>,<PROJECT_ID_2>&project=<PROJECT_ID_3>
Duplicate IDs are ignored. Structured values such as project[id]=<PROJECT_ID> are rejected with 400 BAD_REQUEST. Do not repeat parameters documented as accepting a single value.
Dates
Date filters use real calendar dates in YYYY-MM-DD format. Impossible dates return 400 BAD_REQUEST; leap days are accepted only in leap years. The endpoint defines which record date is filtered and whether a dateField selector is available.
Sorting
Use the endpoint's supported sortBy values and set sortOrder to asc or desc. Defaults vary by resource. Specify both explicitly when your integration depends on an ordering, and preserve them while paging.
For incremental polling, use updatedAt filters only on endpoints that document support for them. Creation-date filters do not identify subsequent changes to existing records.
Field selection
Where supported, fields accepts a comma-separated list of response fields or dot paths:
fields=id,name,code
Omit fields to use the endpoint's default response. Selecting fields reduces the returned payload; it does not change which records the key can access.
Nested selections preserve array structure, element order, empty arrays and null values. Selecting an entire field includes it in full even when a nested field is also requested. Check the endpoint reference for supported fields and any additional validation rules.
Request example
This request lists active projects created in January 2026, sorted by name, with three selected fields. It requires a company-scoped key with read:projects.
curl --get 'https://api.requidex.com/api/open/v1/projects' \
--header "Authorization: Bearer ${REQUIDEX_API_KEY}" \
--header 'Accept: application/json' \
--data-urlencode 'status=active' \
--data-urlencode 'from=2026-01-01' \
--data-urlencode 'to=2026-01-31' \
--data-urlencode 'sortBy=name' \
--data-urlencode 'sortOrder=asc' \
--data-urlencode 'page=1' \
--data-urlencode 'limit=50' \
--data-urlencode 'fields=id,name,code' \
--max-time 30
See List Projects for the full parameter and response definitions, and Rate Limits when scheduling multi-page requests.