Connecting n8n to the Jira REST API v3

TL;DR — Jira Cloud → Atlassian API token + email for auth. n8n’s built-in Jira node covers issue CRUD, transitions, comments. For everything else (boards, sprints, custom fields, JQL), use the HTTP node directly against https://<your>.atlassian.net/rest/api/3/.

After workflow basics, the next thing for the May theme is wiring up Jira. Jira is the most-automated tool in our stack — ticket transitions, comment posting, board moves, label updates. n8n’s built-in Jira node covers the common cases; the HTTP node handles the rest. This post is both.

Auth: API token, not password

Jira Cloud uses email + API token for REST API auth (passwords stopped working in 2019). Generate a token:

1. Go to https://id.atlassian.com/manage-profile/security/api-tokens
2. Create API token, give it a label like “n8n production”
3. Copy the token — it’s shown once

Store the token in your password manager. You can revoke + recreate later; you can’t recover it.

In n8n:

1. Workflow → Credentials → Add
2. Type: “Jira Software Cloud API”
3. Email: your Atlassian email
4. API token: paste
5. Domain: https://yourorg.atlassian.net

Test it. n8n hits a Jira endpoint and confirms.

Using the built-in Jira node

The built-in node covers what you’ll do 80% of the time. Operations available:

• Issue: get, create, update, delete, get-all, comment, attachment, transition
• User: get, get-all, search
• Project: get-all

Example — fetch a single issue:

Node: Jira
Resource: Issue
Operation: Get
Issue Key: PROJ-123

Output: the full issue JSON with all standard fields.

Example — create an issue:

Node: Jira
Resource: Issue
Operation: Create
Project: PROJ
Issue Type: Bug
Summary: {{ $json.title }}
Description: {{ $json.body }}

Output: the created issue with its assigned key.

Example — transition an issue (move to “In Review”):

Node: Jira
Resource: Issue
Operation: Transition
Issue Key: {{ $json.issue_key }}
Transition: [pick from dropdown]

n8n queries Jira at workflow-design time to populate available transitions. You pick by name; the workflow stores the transition ID.

When the built-in node isn’t enough

Common cases that need the HTTP node:

• JQL search (cross-project queries, complex filters)
• Custom field reads/writes (most non-trivial Jira setups use customfield_10001-style IDs)
• Boards & sprints (assigning issues to a sprint, fetching sprint contents)
• Workflow scheme / project config introspection
• Bulk operations (1000 issues in one call)
• Webhook registration (registering Jira webhooks programmatically)

For these, drop the HTTP Request node directly against Jira’s REST API.

Using the HTTP node for JQL

JQL (Jira Query Language) is Jira’s powerful search syntax. The endpoint:

GET https://yourorg.atlassian.net/rest/api/3/search?jql=<encoded JQL>

In n8n, HTTP node configured:

Method: GET
URL: https://yourorg.atlassian.net/rest/api/3/search
Authentication: Generic Credential Type → HTTP Basic Auth
Username: your-email@example.com
Password: <API token>

Query Parameters:
  jql: project = PROJ AND status = "In Progress" AND assignee = currentUser()
  fields: summary,status,assignee,priority
  maxResults: 50

The response includes issues[]. Pass through a Code node to extract just what you need:

const items = $input.all();
const issues = items[0].json.issues;
return issues.map(issue => ({
  json: {
    key: issue.key,
    summary: issue.fields.summary,
    status: issue.fields.status.name,
    assignee: issue.fields.assignee?.displayName ?? 'Unassigned',
    priority: issue.fields.priority?.name ?? 'None',
  },
}));

Now downstream nodes get one item per issue with a clean shape.

Custom fields

Jira’s custom fields (story points, epic link, sprint, custom dropdowns) live under customfield_<id>. To find the IDs:

GET /rest/api/3/field

Returns every field on every issue type in your instance. Find the ones you care about by name.

Example: setting story points via the HTTP node:

Method: PUT
URL: https://yourorg.atlassian.net/rest/api/3/issue/PROJ-123
Body (JSON):
{
  "fields": {
    "customfield_10016": 5
  }
}

(10016 is the typical Jira Cloud story points field; your instance may differ. Verify via the /field endpoint.)

Permissions matter

The API token inherits the permissions of the user who created it. Two common pitfalls:

• Service account vs personal token: for production workflows, create a dedicated Jira user (“n8n-bot”) with only the permissions it needs. Tokens from a personal account die with the person.
• Project permissions: the user needs “Browse projects” + relevant scheme permissions on every project the workflow touches. New projects added later → won’t be accessible until permissions are granted.

Webhooks the other direction

Jira can fire webhooks at n8n on issue events:

1. In n8n, create a workflow with a Webhook trigger. Copy the production webhook URL.
2. In Jira: System → WebHooks (admin only) → Create webhook
3. URL: paste the n8n webhook URL
4. Events: Issue created, updated, deleted (whichever you need)
5. JQL: optionally scope to specific projects

The webhook fires with full issue payload. The n8n workflow handles it.

Webhook + API combo is the most common pattern: Jira tells n8n something happened; n8n makes additional API calls to act on it.

Rate limits

Jira Cloud’s rate limits as of 2022:

• 10 requests/second per user (rolling)
• Burst tolerance ~100 requests
• HTTP 429 on exceeded; Retry-After header

For most workflows you’ll never hit this. Bulk operations (assigning labels to 1000 issues) need throttling. n8n’s built-in Wait node + the HTTP node’s retry logic handle it; cover more in the error handling post.

Common Pitfalls

Using your password instead of an API token. Doesn’t work anymore. Token only.

Forgetting URL escaping in JQL. JQL with spaces, quotes, special chars must be URL-encoded. n8n’s HTTP node handles this if you put JQL in the “Query Parameters” section, not the URL string.

Treating the built-in node’s dropdowns as live. They populate at edit time, not runtime. Renaming a transition in Jira can silently break the workflow.

Hardcoding custom field IDs. They differ per Jira instance. Store in env vars or a config workflow.

Service-account permissions drift. Quarterly audit: confirm the n8n bot user still has access to all projects that workflows touch.

Bulk loops without throttling. Loop over 500 issues with no delay → rate limit. Add a 100ms wait node between calls, or batch.

Logging the API token. Don’t. n8n’s credentials system encrypts; raw HTTP nodes that show full URLs in logs can leak.

Wrapping Up

n8n’s built-in Jira node + HTTP fallback gives you full access to Jira’s API. With this in place, every “manually move ticket” workflow becomes automatable. Wednesday: a concrete one — auto-assigning Jira tickets when GitHub PRs open.