Include issue key/id in new webhook events


Hi team,

I'm revisiting the new webhooks that will be replacing existing webhooks according to

What I've found is that comment_created, comment_updated and comment_deleted doesn't have any reference to the issue. ideally in our case will be that the webhook contains the full issue information like the old jira:issue_updated webhook, but I can settle with at least the issue key or issue id so I can look up (extra cost) for the issue when webhooks are being processed.

This is how a comment_created webhook looks like

it doesn't contain any reference to the issue. Without the reference to the issue or (performant) workaround we cannot upgrade our addon.

worklog_created, worklog_updated and worklog_deleted do contain an issue id.


As written in the Webhooks documentation page:

Variable substitution in the webhook URL

You can append variables to the webhook URL when creating or updating a webhook. The variables are listed below:

  • ${}

  • ${}

  • ${issue.key}

  • ${}

  • ${modifiedUser.key}

  • ${}

  • ${}

  • ${project.key}

  • ${}

  • ${}

You can use these variables to dynamically insert the value of the current issue key, sprint ID, project key, etc, into the webhook URL when it is triggered. Consider the following example:




Chris Waters
December 20, 2017, 10:47 PM

Thanks for adding the additional issue info the comments.

Note that this change is not applicable to worklog_* webhook events, and at this moment we do not plan to add issue details to those webhooks.

It would be extremely helpful if the worklog webhooks included the same information about issues as comments. Symmetry in the API makes it significantly easier to deal with. We can share code much more when the same information is in each webhook. In addition, using the URL based parameters in the webhook configuration is extremely difficult and error prone for our users. We would prefer not to need to do that because we think it will result in a lot of misconfigured webhooks,

Zenix (Han-sheng Huang)
December 21, 2017, 2:01 AM

if possible, wish there could be more examples or documentation related to the changes in this ticket for the following pages:

Fernando Boucquez (PPL)
December 21, 2017, 10:34 AM

Hi Eve, this how it broke yesterday. We managed to release a hotfix and now it's fine.

Our addon sends notifications when issue_, comment_ and worklog_* events occur. It bases the notification on the webhook and issue data. If the event doesn't have the issue's data (the issue field), the addon pull the information from JIRA and add it to the payload.

In the last JIRA upgrade, the addon assumed that the comment_* events already contain the issue information so it didn't have to pull the issue data. But the problem was that the issue data was incomplete where must-have information like issue creation field was missing (among others).

The fix we released yesterday ignores issue data from the event if the created field is missing and reload the issue from JIRA.

Your assumtion that adding more information to a payload won't break existing dependencies is fine. I think in real word it works 95% of the time! It may also break if your json parser is in 'strict' mode, but I would not do that when data comes from a third party system. It was a bit of bad luck!

Andy Czerwonka
January 9, 2018, 3:14 PM

Where are the resolution notes? What context has been added? I understand from that the existing functionality will be removed, so as users we need to start the migration process.

Eve Stankiewicz
January 9, 2018, 8:42 PM

, at this moment we do not provide documentation for any of webhook's payload, and comment webhooks are also not covered. Arguably there is room for improvement when it comes to webhooks documentation, however at this moment we do not have a timeline for such work. So far Jira app developers discovered the structure of webhooks by testing them, using developer instances.



Eve Stankiewicz


Fernando Boucquez (PPL)