List Custom API Entries
GET/v2/settings/extensions/custom-apis/:custom-api-id/entries
Retrieves a list of Custom API Entries
Filtering
The following operators and attributes are available for filtering all Custom API Entries:
| Attribute | Operators | Example |
|---|---|---|
id | lt,le,eq,gt,ge,in | eq(id,859aeba1-03c2-4822-bd4c-89afce93d7eb) |
created_at | lt,le,eq,gt,ge | ge(created_at,2024-04-29T00:00:00.000Z) |
updated_at | lt,le,eq,gt,ge | le(updated_at,2024-04-29T00:00:00.000Z) |
The following operators and attributes may be available for filtering Custom API Entries depending on how the Custom Fields for that Custom API are configured.
| Field type | Operators |
|---|---|
string | lt,le,eq,gt,ge,in,is_null,like |
integer | lt,le,eq,gt,ge,in,is_null |
float | lt,le,gt,ge,in,is_null |
boolean | eq,is_null |
list | contains,contains_any,is_null,contains_all(typed) |
Given there is a Custom Field with "slug": "name" and "field_type": "string".
When you get all Custom API Entries with query parameter: ?filter=like(name,*wish*).
Then you will get all Custom API Entries where name contains the string wish.
For performance reasons, the is_null search operator will NOT match entries for a custom_field where the custom_entry was last updated before the custom_field existed. Updating the entry will cause the field to exist and match properly.
Sorting
The following attributes are available for sorting. When specified, the results are sorted in ascending order based on the value of the field. To sort in descending order, prefix the attribute with -, for example, -updated_at. The default sort order is created_at in descending order.
idcreated_atupdated_at
Query Optimization
When working with large data sets, the following practices help reduce query latency and avoid timeouts.
Choose the right page[total_method]
By default, every list request calculates a lower_bound total, which counts up to 10,000 matching records. If you only need to know whether a next page exists (for example, in an infinite-scroll UI), set page[total_method]=observed. This skips the full count and only checks for one record beyond the current page, which can significantly reduce response times on large data sets.
| Method | Behavior | Best for |
|---|---|---|
lower_bound | Counts up to 10,000 records; reports exact total or indicates lower bound | Displaying a total count to users |
observed | Checks only if a next page exists beyond the current offset and limit | Infinite scroll, cursor-style pagination |
Skip sorting when order doesn't matter
Setting sort=null disables sorting entirely. If your use case does not require a specific order (for example, background sync jobs), this avoids the overhead of ordering results and can improve throughput.
Narrow your filters
Queries that filter on Custom Fields are more efficient when the filter is selective. Prefer exact-match operators (eq, in) over range or wildcard operators (like, lt/le/gt/ge) where possible, and combine multiple filters to reduce the result set early.
Request
Responses
- 200
- 400
- 403
- 422
- 500
List of Custom API Entries
Bad request. The request failed validation.
Forbidden. You do not have permission to access this resource.
Unprocessable Content. The server couldn't satisfy your request, most likely due to a timeout.
Internal server error. There was a system failure in the platform.