Connect Jira to coding agents

1. Create a Jira API token

In Atlassian:

1. Open Atlassian account security.
2. Select Create API token.
3. Name it Denly, create it, and copy it immediately. Jira shows it only once.

Use the token with the email address of the Jira account. Do not paste the token into a webhook payload.

2. Create the Denly connection

Open Workspace → Integrations → Connect → Jira.

• External workspace or repository: your Jira project key, such as ENG.
• API base URL: your Jira site, such as https://acme.atlassian.net.
• Account email and API token: the Jira account's email address and the token from step 1.
• Trigger tag: denly; keep Trigger on create disabled for the first test.
• Initial Denly stage: Plan first. Enable Post worklogs to have Denly log time against the issue.

Routing is optional. Leave Default Denly assignee blank for unassigned tasks, or choose one workspace member to own everything from this connection.

For per-person routing use Route by external assignee: each row pairs one person in the provider (left) with a workspace member (right), and + adds another row. Routing follows the item's assignee in the provider, not whoever created it, and a matching row beats the default above.

The left-hand value must be the identifier the provider actually sends, which the field's placeholder names for you. Matching ignores surrounding spaces and letter case, but nothing else: a near-miss routes nothing and looks the same as a broken integration.

Read Jira webhook documentation.

3. Register the Jira webhook

In Jira open Settings → System → Webhooks → Create webhook. Set the generated Denly URL, subscribe to issue-created/updated and issue-comment events, and leave the JQL filter matching the issues you want Denly to see.

Authenticate the webhook. Jira Cloud has no custom-header field, so paste the Denly inbound secret into the webhook’s Secret box. Jira then signs each delivery and sends X-Hub-Signature: sha256=…, which Denly verifies against the same secret. Save the webhook.

Jira Data Center has no Secret box but does allow headers: send the inbound secret as X-Denly-Token instead. Denly accepts either scheme. The same applies to a Jira Automation rule using Send web request, which supports custom headers but does not sign.

A self-managed Jira server must be publicly reachable over HTTPS. Jira’s webhook delivery log is the first place to check.

4. Test and troubleshoot

1. Create an issue in the connected project and add the denly label.
2. Open Workspace → Integrations → Jira → Recent events.
3. Processed means a task was created; Skipped means the label, assignee, project or create rule declined it, and the Diagnostic column says which.

Nothing at all, and the card still on Awaiting first event, means every delivery is being rejected before the queue: re-check the webhook Secret, or the X-Denly-Token header, against the inbound secret. The secret is shown only once, so replace it on both sides rather than guessing. Jira's own webhook delivery log is where those rejected attempts are recorded.

Status mappings move the Jira issue as the task progresses. The setting appears once the connection is saved, not while you are creating it: the dropdown is read live from your project's workflow, which needs the credentials to be stored first. Until you set it, the defaults apply. Reopen the connection and each row offers your project's real statuses – so there is no name to spell. Leave a stage on Default to keep the value shown in the option, or set it to No change to leave the issue where it is. If Denly cannot read your workflow – the stored credentials have lapsed, or Jira is having a bad minute – the rows fall back to a text box plus a No change box, so the mapping stays editable rather than blocking the rest of the form. Jira transitions are edges rather than states, so a status that is not reachable from the issue's current one is skipped rather than forced.

Comments containing #denly on linked issues become revision work.