🤖 Automating with the Jira REST API

Automating with the Jira REST API: Jira's web interface is a shop window: tidy, safe and ideal for buying one item at a time.

Jira's web interface is a shop window: tidy, safe and ideal for buying one item at a time. The REST API is the back door of the warehouse -- through it you move a pallet, not a single box. The question worth pausing on: why learn an API for a bug you can file by hand in thirty seconds? The answer is not in one record but in three hundred: pushing a regression suite's results into Jira, filing records for runs that broke overnight, or pulling a report every morning are not jobs done by hand. Compare: instead of twenty clicks through the interface, you set up the user and the cart with a single API call when preparing test data. The reason is the same: the interface runs at human speed, the API at machine speed -- and while your automation breaks when the interface changes, the API contract changes far more slowly. One warning is due for QA as well: the API also produces mistakes you could never make by hand, at a speed you could never reach by hand. One wrong loop can create three hundred duplicate records. So every write operation is first tried in a test project, the rate limit is respected, and the returned error codes are told apart (401 identity, 403 permission, 429 too many requests).

🧭 What You Will Learn in This Tab

We will cover authenticating with an API token; the issue-creation and JQL-search endpoints; the Java and Python equivalents of the same calls; sending events out of Jira with webhooks; and rate limits plus what the error codes (401 / 403 / 429) actually tell you.

🎬 A REST API Call Filing a Bug in Jira

POST /rest/api/3/issue

Identity + Permission Check

401: Identity Rejected

An automation script needs to create three hundred test data records -- doing it by hand would take hours. In this film you will watch what a single API call experiences on the Jira server.

Step 1 -- The script puts an API token generated in account settings, together with the email, into the Authorization header. A password is NOT used -- a token is a credential separate from the password that can be revoked if leaked.

Step 2 -- The request reaches the Jira server. The server first verifies IDENTITY (is this token valid), then checks PERMISSION (does this user have rights to create issues in the SHOP project). Two separate checks, two separate error codes possible.

Step 3a -- If the token is invalid (mistyped, expired) the server returns `401 Unauthorized` -- meaning "I do not know who you are". The request is treated as never having ENTERED Jira at all.

Finale -- If both identity AND permission are valid, Jira creates a new issue and returns the key SHOP-143 in the response body. This single call takes an operation that manually takes thirty seconds down to a fraction of a second -- and repeated three hundred times, makes possible a job that could never be done by hand.

1️⃣ J1. Authentication and Creating an Issue

Every request to the Jira REST API carries an Authorization header -- the base64-encoded email and API token. A password is NOT used: the token is a separate credential and, if leaked, can be revoked without changing the password. The `curl` example below shows the most basic call.