how to add webhook when story status changed
Hi @Harshal Bhaurao More
You can simply trigger like:
Are you using Jira Cloud or Server / Data Center version?
With Cloud, please try the Work Item Transitioned trigger: https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Work-item-transitioned
With Server / Data Center, please use Issue Transition: https://confluence.atlassian.com/automation/jira-automation-triggers-993924804.html#Jiraautomationtriggers-issuetransitioned
You may then follow that with a condition test on the work item / issue type, and the Send Web Request action.
Kind regards,Bill
Both existing answers use Automation for Jira's Send web request — that works, but there's a third approach worth knowing about that's often cleaner for "fire a webhook on a specific transition":
Native admin webhook with a JQL filter using the CHANGED operator.
In Settings → System → WebHooks, create a webhook subscribed to "Issue updated" and set the JQL filter to:
status CHANGED FROM "To Do" TO "In Progress" AND issuetype = Story
What this does: the JQL CHANGED operator matches issues at the moment their status transitions from one specific value to another. Jira evaluates the filter at the platform layer before the webhook fires — so only "Story moved from To Do → In Progress" events reach your endpoint. Nothing else triggers.
Why this is often preferable to the Automation approach:
(status CHANGED FROM "To Do" TO "In Progress" OR status CHANGED FROM "In Review" TO "Done") AND issuetype = Story
The CHANGED FROM/TO syntax is JQL's most underused operator — once you start thinking in "I want to know when X transitions to Y" terms instead of "field changed" terms, a lot of webhook and automation logic gets simpler.
Just following up to check if this answered your question. If so, please consider marking this one as "answered". That will help others with a similar need find solutions faster. If not, please let the community know what help you need with the rule.
Thanks!
I have to disagree with this approach—or at least point out a significant caveat that should be mentioned.
When you configure a webhook this way (Issue updated + JQL status CHANGED FROM "To Do" TO "In Progress"), it doesn't fire only on the transition itself. It also fires on any subsequent update to that issue after the transition has already occurred.
status CHANGED FROM "To Do" TO "In Progress"
For example: once the transition from "To Do" → "In Progress" has been executed, the issue still satisfies the CHANGED condition in its history. If you later update any other field on that issue (a custom field, a comment, assignee, etc.), the webhook will trigger again—even though no status change happened.In practice, this means:
CHANGED
changelog.items
So while this approach avoids Automation quota, it shifts complexity from Jira configuration to your webhook handler—and it's not truly "set and forget."
Hi @Harshal Bhaurao More ,
The easiest and most reliable option is to use Jira Automation:
POST
Alternatively, if you want to use a native Jira webhook, navigate to ⚙️ Settings → System → Webhooks, create a webhook with the JQL:
Plain Text issue type = Story
Then subscribe to the Issue Updated event.
That said, Jira Automation is generally the better approach because it provides greater flexibility for controlling when the webhook is triggered and allows you to customize request headers, payloads, and additional conditions without external handling.
Thanks!!
It looks like you're new here. Sign in or register to get started.
