Webhook never fires


I’m having a problem where a webhook I’ve created via POST /rest/api/3/webhook (from a Connect app) is never fired. I can successfully register this webhook, I can query webhooks and get it back, I can extend and deleted it, but no matter what I do I can’t get any events actually sent to it.

I’ve checked the GET /rest/api/3/webhook/failed endpoint and it always returns no results, so it seems Jira is not event attempting to send me any events.

I want all events for all issues (that is, I don’t want to use a JQL filter, which is mandatory for some reason) so I’m requesting all possible events using the filter: status = Done OR status != Done, which I believe should match all issues. However testing a more specific filter (such as project = XYZ) just to rule that out doesn’t change anything.

(I should also mention, if I configure this same webhook using the Jira settings admin interface, it works just fine.)

Has anybody encountered this? Is there anywhere to see logs of what Jira is doing relating to webhooks? It seems to be a total black box.

Best regards,

Hi @BWW,

I haven’t heard of any issues in this area (excuse the pun).

How do you validate your webhook was registered successfully? Is it by (a) the existence of a webhook ID in the returned response, (b) lack of errors in the returned response, © a GET request to /rest/api/3/webhook, (d) some other means, (e) some combination of these.

In addition, does you app have visibility to see the issue(s) you’re expecting to receive webhooks for?


Hi @dmorrow,

Thanks for your response. I’m validating the creation of a webhook by: checking for errors in the response, storing the returned webhook identifier, and (later) fetching that webhook back from the service and querying for failures on it.

I do have visibility to see the issues I expect to produce webhook events. In testing, I make edits to them in order to attempt to trigger the webhook.

Best regards,

Hi @BWW,

I’m not able to reproduce this. I created a test app which dynamically registers a webhook for jira:issue_updated events and the app is called when issues are updated.

What type(s) of events are you registering for?


Hi @dmorrow,

That’s interesting. I’m looking to receive any change that happens to an issue plus comments, so I am registering for the following events:

jira:issue_created, jira:issue_updated, jira:issue_deleted, issue_property_set, issue_property_deleted, comment_created, comment_updated, comment_deleted

More specifically, I’m making this request:

POST https://redacted.atlassian.net/rest/api/3/webhook
Accept: application/json
Authorization: JWT <token>
Content-Type: application/json

{"url":"https://redacted.ngrok.io/path-to-webhook","webhooks":[{"jqlFilter":"status = Done or status != Done","events":["comment_created","comment_deleted","comment_updated","issue_property_deleted","issue_property_set","jira:issue_created","jira:issue_deleted","jira:issue_updated"]}]}

In response I get a 200 with this body:


If I curl my webhook endpoint URL I can trace the request. However making changes to issues in Jira never triggers it. I’m pretty confident this is all as expected and I should be getting events, but maybe I’m missing something.

I should also mention that if I copy that same URL from that request and use it to create a webhook manually in the Jira settings interface, I do receive events just fine. So it seems to be something specifically related to creating a webhook dynamically.

Best regards,

Hi @BWW,

mmm Your registration response is the same as what I get (apart from the ID). I tried with the combination of events you have and I still get notifications. I registered for these events twice each - once in the descriptor and once with an API call - an I get two notifications for each event. I used two URLs to distinguish whether the event corresponded to a static vs dynamic webhook registration. I can’t see the problem, but I’ll try to find time to investigate further. Until then, perhaps you might try your code in a separate tenant.


Thanks @dmorrow,

I had tried this in one other tenant (which I’m understanding to mean, basically, a different domain; as in <tenant>.atlassian.net) but it had the same behavior. Is it possible there’s something about the scopes I’ve requested or the way the app descriptor is configured that could affect this?

Best regards,

Hi @BWW,

You app will need the READ scope although I think we established it does after I asked:

does you app have visibility to see the issue(s) you’re expecting to receive webhooks for?


I don’t think this is the problem because your app receives webhook events when statically registered by its Connect descriptor.

Could it be possible that your app server is receiving the webhook at a different location than what you are expecting? May your server has some kind of catch all end point which is consuming the webhook events?

Maybe you could trying configuring a webhook manually by visiting https://yourtenant.atlassian.net/plugins/servlet/webhooks and make sure you provide the same webhook URL that you’re dynamically registering.

FYI, https://yourtenant.atlassian.net/plugins/servlet/webhooks only shows manually configured webhooks - not those created by your app.

It wouldn’t be the ‘or’ in your jqlFilter would it? I note that webhooks support only a subset of JQL operators: =, !=, IN, NOT IN. Is ‘or’ an operator? Just a stab in the dark.

Hi @BWW,

Another stab in the dark, but are you using Atlassian Connect Express? The first time, I set up a webhook with ACE, it took me days to realize that the frameworks sets up a route for the endpoint automatically which took precedent over my endpoint.

To me, it felt like my route was never called, so your problem rings familiar. In the end, looking at ngrok and seeing an actual request coming in and being answered made me look in the right direction.

Hope you find the problem!

Best regards,

1 Like

Also FYI, if the webhook client is running any JDK earlier than 11.0.8 (very latest) you’re likely to get hung webhooks to TLSv1.3 servers. See https://jira.atlassian.com/browse/JRASERVER-70780.

Thanks for your suggestion. Unfortunately a simpler JQL expression (status != Done) didn’t help things.

Thanks for your suggestion. I’m not using Java, though, so this issue probably wouldn’t apply.

Thanks for your suggestion. I’m not using Atlassian Connect Express and I don’t have any static webhooks in the app descriptor, so I don’t think this would be the issue.

(I have tried registering a static webhook, and oddly enough this does work just fine. Unfortunately this will complicate my use case, but I may resort to it out of frustration.)

We had the exact same issue. In our case, we were registering our webhook to an external server, not the Atlassian Connect one (using Atlassian Connect Express).

Finally, we tried adding a /webhook-received route to our ACE server and then register our webhook using the same URL as our ACE server by registering a dynamic webhook as follow :

var fullUrl = 'https://' + req.get('host');
let body = `{
  "webhooks": [
      "jqlFilter": "project = test",
      "events": [
  "url":` + `"` + fullUrl + `/webhook-received"

This worked like a charm.

But we would like to understand why the same webhook doesn’t work when the specified URL is different than the ACE server one. Is it a known restriction/limitation ?

Thank you

Hello @BWW,
From where do you try the REST API call?
I have a nodejs connect app, and trying to call “/rest/api/3/webhook” via AP.request but I get the error “Only apps can access this resource” but it is from within the app frontend…

Thank you!

Hi @BWW , I experienced same issue with you and it brought me to here. After investigating for a while, I realized that my webhook url is incorrect because missing a part of base url. My base url that is configured in connector descriptor is: https://ngrokurl.io/jiracloud, and my webhook url is https://ngrokurl.io//webhook. Jira requires to use base url for webhook url so it should be …/jiracloud/webhook
It doesn’t throw any error with incorrect url though.
Hopefully it can help you.