<b>Required scope: </b><code>tasks:read</code> To mirror the functionality of the Asana web app's advanced search feature, the Asana API has a task search endpoint that allows you to build complex filters to find and retrieve the exact data you need. #### Premium access Like the Asana web product's advance search feature, this search endpoint will only be available to premium Asana users. A user is premium if any of the following is true: - The workspace in which the search is being performed is a premium workspace - The user is a member of a premium team inside the workspace Even if a user is only a member of a premium team inside a non-premium workspace, search will allow them to find data anywhere in the workspace, not just inside the premium team. Making a search request using credentials of a non-premium user will result in a `402 Payment Required` error. #### Pagination Search results are not stable; repeating the same query multiple times may return the data in a different order, even if the data do not change. Because of this, the traditional [pagination](/docs/pagination) available elsewhere in the Asana API is not available here. However, you can paginate manually by sorting the search results by their creation time and then modifying each subsequent query to exclude data you have already seen. Page sizes are limited to a maximum of 100 items, and can be specified by the `limit` query parameter. #### Eventual consistency Changes in Asana (regardless of whether they’re made though the web product or the API) are forwarded to our search infrastructure to be indexed. This process can take between 10 and 60 seconds to complete under normal operation, and longer during some production incidents. Making a change to a task that would alter its presence in a particular search query will not be reflected immediately. This is also true of the advanced search feature in the web product. Because of this delay, the search endpoint is not suited for use cases that require immediate consistency after writes. If you need read-your-write behavior or strongly consistent results, we recommend using [Get multiple tasks](/reference/gettasks) instead. #### Rate limits You may receive a `429 Too Many Requests` response if you hit any of our [rate limits](/docs/rate-limits). #### Custom field parameters | Parameter name | Custom field type | Accepted type | |---|---|---| | custom_fields.{gid}.is_set | All | Boolean | | custom_fields.{gid}.value | Text | String | | custom_fields.{gid}.value | Number | Number | | custom_fields.{gid}.value | Enum | Enum option ID | | custom_fields.{gid}.value | Date | ISO 8601 date string (yyyy-mm-dd) | | custom_fields.{gid}.starts_with | Text only | String | | custom_fields.{gid}.ends_with | Text only | String | | custom_fields.{gid}.contains | Text only | String | | custom_fields.{gid}.less_than | Number only | Number | | custom_fields.{gid}.greater_than | Number only | Number | | custom_fields.{gid}.before | Date only | ISO 8601 date string (yyyy-mm-dd) | | custom_fields.{gid}.after | Date only | ISO 8601 date string (yyyy-mm-dd) | For example, if the gid of the custom field is 12345, the query parameter to find tasks where it is set would be `custom_fields.12345.is_set=true`. To match an exact value for an enum custom field, use the gid of the desired enum option and not the name of the enum option: `custom_fields.12345.value=67890`. To find tasks with a date custom field before April 21, 2026, use `custom_fields.12345.before=2026-04-21`. **Not Supported**: searching for multiple exact matches of a custom field, searching for multi-enum custom field #### Custom task type parameters | Parameter name | Accepted type | |---|---| | custom_types.{gid}.custom_type_status_option.gid | Enum option GID | This parameter filters tasks by their custom task status option. The `{gid}` is the GID of the custom task type, and the value is the GID of a valid status option for that type's status field. **Requirements**: - `resource_subtype=custom` must be set when using this parameter. - Only one `custom_types.*` parameter may be specified per request. - The provided custom task type GID must reference a valid custom object type. - The status option GID must be a valid option for the custom type's status field. - Cannot be combined with `custom_fields.{status_field_gid}.value` when `{status_field_gid}` is the status field belonging to the same custom task type. For example, to find custom tasks of type `12345` with status option `67890`: `custom_types.12345.custom_type_status_option.gid=67890&resource_subtype=custom`. *Note: If you specify `projects.any` and `sections.any`, you will receive tasks for the project **and** tasks for the section. If you're looking for only tasks in a section, omit the `projects.any` from the request.*