The Jira REST API enables you to interact with Jira programmatically. Use this API to build apps, script interactions with Jira, or develop any other type of integration. This page documents the REST resources available in Jira Cloud, including the HTTP response codes and example requests and responses.
This documentation is for version 2 of the Jira Cloud platform REST API.
The latest version of the Jira Cloud platform REST API is version 3, which is in beta. Version 2 and 3 of the API offer the same collection of operations. However, version 3 provides support for the Atlassian Document Format (ADF). The ADF features in version 3 are under development.
For Forge apps, REST API scopes are used when authenticating with Jira Cloud platform. See Add scopes to call an Atlassian REST API for more details.
The URIs for Forge app REST API calls have this structure:
/rest/api/3/<resource-name>
For example, /rest/api/3/issue/DEMO-1
For Connect apps, authentication (JWT-based) is built into the Connect libraries. Authorization is implemented using either scopes (shown as App scope required for operations on this page) or user impersonation. See Security for Connect apps for details.
The URIs for Connect app REST API calls have this structure:
https://<site-url>/rest/api/3/<resource-name>
For example, https://your-domain.atlassian.net/rest/api/3/issue/DEMO-1
For integrations that are not Forge or Connect apps, use OAuth 2.0 authorization code grants (3LO) for security (3LO scopes are shown as for operations OAuth scopes required). See OAuth 2.0 (3LO) apps for details.
The URIs for OAuth 2.0 (3LO) app REST API calls have this structure:
https://api.atlassian.com/ex/jira/<cloudId>/rest/api/3/<resource-name>
For example, https://api.atlassian.com/ex/jira/35273b54-3f06-40d2-880f-dd28cf8daafa/rest/api/3/issue/DEMO-1
For personal scripts, bots, and ad-hoc execution of the REST APIs use basic authentication. See Basic auth for REST APIs for details.
The URIs for basic authentication REST API calls have this structure:
https://<site-url>/rest/api/3/<resource-name>
For example, https://your-domain.atlassian.net/rest/api/3/issue/DEMO-1
Most operations in this API require permissions. The calling user must have the required permissions for an operation to use it. Note that for Connect apps, the app user must have the required permissions for the operation and the app must have scopes that permit the operation.
A permission can be granted to a group, project role, or issue role that the user is a member of, or granted directly to a user. See Permissions overview for details. The most common permissions are:
Some operations provide support for anonymous access. However, anonymous access is only available if the Jira permission needed to access the object or records returned by the operation is granted to the Public group. See Allowing anonymous access to your project for details.
If an operation is called anonymously and anonymous access is not available, the operation will return an error. Note that not all operations that correspond to objects that can be given public access provide for anonymous access.
The Jira REST API uses resource expansion, which means that some parts of a resource are not returned unless specified in the request. This simplifies responses and minimizes network traffic.
To expand part of a resource in a request, use the expand query parameter and specify the object(s) to be expanded.
If you need to expand nested objects, use the . dot notation. If you need to expand multiple objects, use a
comma-separated list.
For example, the following request expands the names and renderedFields properties for the JRACLOUD-34423 issue:
GET issue/JRACLOUD-34423?expand=names,renderedFields
To discover which object can be expanded, refer to the expand property in the object.
In the JSON example below, the resource declares widgets as expandable.
1 2{ "expand": "widgets", "self": "https://your-domain.atlassian.net/rest/api/3/resource/KEY-1", "widgets": { "widgets": [], "size": 5 } }
The Jira REST API uses pagination to improve performance. Pagination is enforced for operations that could return a large collection of items. When you make a request to a paginated resource, the response wraps the returned array of values in a JSON object with paging metadata. For example:
1 2{ "startAt" : 0, "maxResults" : 10, "total": 200, "isLast": false, "values": [ { /* result 0 */ }, { /* result 1 */ }, { /* result 2 */ } ] }
startAt is the index of the first item returned in the page.maxResults is the maximum number of items that a page can return. Each operation can have a different limit for
the number of items returned, and these limits may change without notice. To find the maximum number of items
that an operation could return, set maxResults to a large number—for example, over 1000—and if the returned value of maxResults is less than the requested value, the returned value is the maximum.total is the total number of items contained in all pages. This number may change as the client
requests the subsequent pages, therefore the client should always assume that the requested page can be empty. Note
that this property is not returned for all operations.isLast indicates whether the page returned is the last one. Note that this property is not returned for all operations.Some operations support ordering the elements of a response by a field. Check the documentation for the operation to
confirm whether ordering of a response is supported and which fields can be used. Responses are listed in ascending order
by default. You can change the order using the orderby query parameter with a - or + symbol. For example:
?orderBy=name to order by name field ascending.?orderBy=+name to order by name field ascending.?orderBy=-name to order by name field descending.By default, top-level timestamps (e.g. updated and created) are returned in ISO 8601 format, in the system default user time zone.
To return date time data in the logged in user's timezone, please refer to renderedFields property under the expand query parameter in relevant APIs.
The following request and response headers define important metadata for the Jira Cloud REST API resources.
X-Atlassian-Token (request): Operations that accept multipart/form-data must include the X-Atlassian-Token: no-check
header in requests. Otherwise the request is blocked by cross-site request forgery (CSRF/XSRF) protection.X-Force-Accept-Language (request): controls how the standard HTTP Accept-Language header is processed.
By default Accept-Language is ignored and the response is in the language configured in the user's profile or,
when no language is configured for the user, the default Jira instance language. For the response to recognize
Accept-Language send X-Force-Accept-Language = true as well. If Accept-Language requests a language that Jira
can return the response is in that language, otherwise Jira returns the response in the default language. If
Accept-Language is not specified the response is in the default language.X-AAccountId (response): This response header contains the Atlassian account ID of the authenticated user.Jira provides for all permissions, except the global permission Administer Jira, to be assigned to Anyone. Once a permission is assigned to Anyone, anyone knowing a project's URL is able to use the features in Jira enabled by the permission. However, the Jira REST API does not enable anonymous access for operations by default. This means that an anonymous user who may be able to perform an action through Jira, may not be able to perform the same action where it's enabled by the REST API.
The operations that provide anonymous access are annotated "This operation can be accessed anonymously."
Some Jira REST API operations may trigger long-running or computationally expensive tasks. In these cases, the operation
will schedule an asynchronous task and return a 303 (See Other) response, indicating the location of the queued task
in the Location header. You can query this task to get progress updates.
When the task finishes, the response object will contain the result field. The content of the field is specific to the
operation that created the task. Refer to the operation’s documentation for more information.
Note that asynchronous tasks are not guaranteed to be run in order. In other words, if you need your tasks to execute in a certain order, you should start a task only after the prerequisite task(s) have finished.
Features and methods marked as experimental may change without notice. Feedback on experimental functionality is welcome. Report your suggestions and bugs in the ACJIRA project (preferred) or use the Give docs feedback link at the top of this page.
The Jira Cloud platform REST API uses the standard HTTP status codes.
Operations that return an error status code may also return a response body containing details of the error or errors. The schema for the response body is shown below:
1 2{ "id": "https://docs.atlassian.com/jira/REST/schema/error-collection#", "title": "Error Collection", "type": "object", "properties": { "errorMessages": { "type": "array", "items": { "type": "string" } }, "errors": { "type": "object", "patternProperties": { ".+": { "type": "string" } }, "additionalProperties": false }, "status": { "type": "integer" } }, "additionalProperties": false }
Rate this page: