.list endpoints accept an optional filters array in the JSON request body to narrow down the returned results. Each endpoint declares its own set of filters — the available keys and their expected value types are listed on the endpoint’s API Reference page. Like every tipee API call, the examples below are POST requests with a JSON body (see First steps).
Basic syntax
Every filter is an object with two required fields: akey identifying the filter, and a value. The filter keys declared by an endpoint follow the <entity>.<field> naming convention; the composite keys or and and described in Combining filters are the only exception:
/api/directory/tags.list:
Combining filters
Filters at the top level of thefilters array are combined with a logical AND. The same key may appear multiple times; each occurrence adds another condition.
To express alternatives, use the composite keys or and and, available on every endpoint that supports filters. Their value is an array of nested filters, and they can be nested inside each other without depth limit:
Value shapes
The shape ofvalue depends on the filter — the endpoint’s API Reference documents the exact type for each key.
Duplicate array values are ignored, and some array filters accept
null as an element to match entries without a value — for example resources not assigned to any project.Operator objects
Some filters take an object asvalue, letting you choose the comparison operator explicitly. The most common case is the attribute filters of /api/directory/resources.list, which target the configured attributes of a directory kind:
The
none operator matches entries where the attribute has no value at all. Omit the value property when using it — with any other operator, value is required.resources.list, the available attribute names come from /api/directory/kinds.show, which also indicates whether each attribute can be filtered or ordered.
Data formats
Common errors
The response body contains a message describing the problem — see Error Handling for the general error format.