This is a standard ApplicationSearch method which will let you list, query, or search for objects. For documentation on these endpoints, see Conduit API: Using Search Endpoints.
maniphest.search
API Method: maniphest.search
- Returns
- map<string, wild>
- Errors
- ERR-CONDUIT-CORE: See error message for details.
- OAuth Scope
- OAuth clients may never call this method.
Method Description
Prebuilt Queries
You can choose a builtin or saved query as a starting point for filtering results by selecting it with queryKey. If you don't specify a queryKey, the query will start with no constraints.
For example, many applications have builtin queries like "active" or "open" to find only active or enabled results. To use a queryKey, specify it like this:
{ ... "queryKey": "active", ... }
The table below shows the keys to use to select builtin queries and your saved queries, but you can also use any query you run via the web UI as a starting point. You can find the key for a query by examining the URI after running a normal search.
You can use these keys to select builtin queries and your configured saved queries:
Query Key | Name | Builtin |
---|---|---|
open | Open Tasks | Builtin |
all | All Tasks | Builtin |
Constraints
You can apply custom constraints by passing a dictionary in constraints. This will let you search for specific sets of results (for example, you may want show only results with a certain state, status, or owner).
If you specify both a queryKey and constraints, the builtin or saved query will be applied first as a starting point, then any additional values in constraints will be applied, overwriting the defaults from the original query.
Different endpoints support different constraints. The constraints this method supports are detailed below. As an example, you might specify constraints like this:
{ ... "constraints": { "authorPHIDs": ["PHID-USER-1111", "PHID-USER-2222"], "flavors": ["cherry", "orange"], ... }, ... }
This API endpoint supports these constraints:
Key | Label | Type | Description |
---|---|---|---|
ids | IDs | list<int> | Search for objects with specific IDs. |
phids | PHIDs | list<phid> | Search for objects with specific PHIDs. |
assigned | Assigned To | list<user> | Search for tasks owned by a user from a list. |
authorPHIDs | Authors | list<user> | Search for tasks with given authors. |
statuses | Statuses | list<string> | Search for tasks with given statuses. |
priorities | Priorities | list<int> | Search for tasks with given priorities. |
subtypes | Subtypes | list<string> | Search for tasks with given subtypes. |
columnPHIDs | Columns | list<phid> | |
hasParents | Open Parents | bool | |
hasSubtasks | Open Subtasks | bool | |
parentIDs | Parent IDs | list<int> | |
subtaskIDs | Subtask IDs | list<int> | |
group | Group By | Not supported. | |
createdStart | Created After | epoch | |
createdEnd | Created Before | epoch | |
modifiedStart | Updated After | epoch | |
modifiedEnd | Updated Before | epoch | |
closedStart | Closed After | epoch | |
closedEnd | Closed Before | epoch | |
closerPHIDs | Closed By | list<user> | Search for tasks closed by certain users. |
query | Query | string | Find objects matching a fulltext search query. See "Search User Guide" in the documentation for details. |
subscribers | Subscribers | list<user> | Search for objects with certain subscribers. |
projects | Tags | list<project> | Search for objects tagged with given projects. |
spaces | Spaces | list<phid> | Search for objects in certain spaces. |
custom.stwalkerster:date | Date | Not supported. |
Result Ordering
Use order to choose an ordering for the results.
Either specify a single key from the builtin orders (these are a set of meaningful, high-level, human-readable orders) or specify a custom list of low-level columns.
To use a high-level order, choose a builtin order from the table below and specify it like this:
{ ... "order": "newest", ... }
These builtin orders are available:
Key | Description | Columns |
---|---|---|
priority | Priority | priority, id |
updated | Date Updated (Latest First) | updated, id |
outdated | Date Updated (Oldest First) | -updated, -id |
newest | Creation (Newest First) | id |
oldest | Creation (Oldest First) | -id |
closed | Date Closed (Latest First) | closed, id |
title | Title | title, id |
custom.stwalkerster:date | Date | custom.stwalkerster:date, id |
-custom.stwalkerster:date | Date (Reversed) | -custom.stwalkerster:date, -id |
relevance | Relevance | rank, fulltext-modified, id |
You can choose a low-level column order instead. To do this, provide a list of columns instead of a single key. This is an advanced feature.
In a custom column order:
- each column may only be specified once;
- each column may be prefixed with - to invert the order;
- the last column must be a unique column, usually id; and
- no column other than the last may be unique.
To use a low-level order, choose a sequence of columns and specify them like this:
{ ... "order": ["color", "-name", "id"], ... }
These low-level columns are available:
Key | Unique |
---|---|
id | Yes |
custom.stwalkerster:date | No |
rank | No |
fulltext-created | No |
fulltext-modified | No |
priority | No |
owner | No |
status | No |
project | No |
title | No |
updated | No |
closed | No |
Object Fields
Objects matching your query are returned as a list of dictionaries in the data property of the results. Each dictionary has some metadata and a fields key, which contains the information about the object that most callers will be interested in.
For example, the results may look something like this:
{ ... "data": [ { "id": 123, "phid": "PHID-WXYZ-1111", "fields": { "name": "First Example Object", "authorPHID": "PHID-USER-2222" } }, { "id": 124, "phid": "PHID-WXYZ-3333", "fields": { "name": "Second Example Object", "authorPHID": "PHID-USER-4444" } }, ... ] ... }
This result structure is standardized across all search methods, but the available fields differ from application to application.
These are the fields available on this object type:
Key | Type | Description |
---|---|---|
title | string | The title of the task. |
description | remarkup | The task description. |
authorPHID | phid | Original task author. |
ownerPHID | phid? | Current task owner, if task is assigned. |
status | map<string, wild> | Information about task status. |
priority | map<string, wild> | Information about task priority. |
points | points | Point value of the task. |
subtype | string | Subtype of the task. |
closerPHID | phid? | User who closed the task, if the task is closed. |
dateClosed | int? | Epoch timestamp when the task was closed. |
spacePHID | phid? | PHID of the policy space this object is part of. |
dateCreated | int | Epoch timestamp when the object was created. |
dateModified | int | Epoch timestamp when the object was last updated. |
policy | map<string, wild> | Map of capabilities to current policies. |
custom.stwalkerster:external-ref | wild | |
custom.stwalkerster:date | wild |
Attachments
By default, only basic information about objects is returned. If you want more extensive information, you can use available attachments to get more information in the results (like subscribers and projects).
Generally, requesting more information means the query executes more slowly and returns more data (in some cases, much more data). You should normally request only the data you need.
To request extra data, specify which attachments you want in the attachments parameter:
{ ... "attachments": { "subscribers": true }, ... }
This example specifies that results should include information about subscribers. In the return value, each object will now have this information filled out in the corresponding attachments value:
{ ... "data": [ { ... "attachments": { "subscribers": { "subscriberPHIDs": [ "PHID-WXYZ-2222", ], "subscriberCount": 1, "viewerIsSubscribed": false } }, ... }, ... ], ... }
These attachments are available:
Key | Name | Description |
---|---|---|
columns | Workboard Columns | Get the workboard columns where an object appears. |
subscribers | Subscribers | Get information about subscribers. |
projects | Projects | Get information about projects. |
Paging and Limits
Queries are limited to returning 100 results at a time. If you want fewer results than this, you can use limit to specify a smaller limit.
If you want more results, you'll need to make additional queries to retrieve more pages of results.
The result structure contains a cursor key with information you'll need in order to fetch the next page of results. After an initial query, it will usually look something like this:
{ ... "cursor": { "limit": 100, "after": "1234", "before": null, "order": null } ... }
The limit and order fields are describing the effective limit and order the query was executed with, and are usually not of much interest. The after and before fields give you cursors which you can pass when making another API call in order to get the next (or previous) page of results.
To get the next page of results, repeat your API call with all the same parameters as the original call, but pass the after cursor you received from the first call in the after parameter when making the second call.
If you do things correctly, you should get the second page of results, and a cursor structure like this:
{ ... "cursor": { "limit": 5, "after": "4567", "before": "7890", "order": null } ... }
You can now continue to the third page of results by passing the new after cursor to the after parameter in your third call, or return to the previous page of results by passing the before cursor to the before parameter. This might be useful if you are rendering a web UI for a user and want to provide "Next Page" and "Previous Page" links.
If after is null, there is no next page of results available. Likewise, if before is null, there are no previous results available.
Call Method
Examples
- Use the Conduit API Tokens panel in Settings to generate or manage API tokens.
- If you submit parameters, these examples will update to show exactly how to encode the parameters you submit.
-d api.token=api-token \
-d param=value \
...