I want to manage webhooks through Jira Cloud API (create, delete and refresh it).
I have an external application to which I want Jira to send updates when tickets are updated. This app is not a Forge app nor a Connect app and I do not want to have to create one of these app only to be able to manage my webhooks.
Thus, we created a service account with OAuth 2.0 that has the following scopes : `manage:jira-webhook` `read:jira-user` `read:jira-work` `read:servicedesk-request` `write:jira-work`.
With its Bearer token I am able to request this route `https://api.atlassian.com/ex/jira/{my-cloud-id}/rest/api/3/webhook/failed\` but all other routes regarding webhooks simply return a 500 error.
Is it not possible to request those routes using a service account with OAuth 2.0 or am I missing something?
I’m fairly sure it’s because Service Accounts are just OAuth based user accounts that are pre-scoped and they not OAuth apps (something registered with Atlassian that have an owner and an app ID), and the Webhook endpoints are expecting a request to come from one of those OAuth apps. (IE. a request from something that can manage and refresh dynamic webhooks that belong to it).
Thanks a lot for your answer and trying to reproduce it.
I would think it should be in the scope of Service Accounts’ activities to handle webhooks, especially as a standard user authenticated with OAuth can do it. Otherwise it means that only Forge and Connect apps can handle webhooks without needing manual intervention. It leaves out all other kind of apps, which does not seem right to me. I do not think I should have to dev a Forge app just to be able to handle my webhooks.
Is there somewhere I could open a ticket to ask for this feature?
I think you have not properly read and understood what the Webhooks endpoints documentation says about what can create and manage dynamic webhooks. It says:
“Only Connect andOAuth 2.0apps can register and manage webhooks”
it does not say:
“Only Connect and Forge apps can register and manage webhooks”
Any ‘generic’ OAuth 2.0 app you register via the Developer Portal can be used to manage dynamic webhooks using that app’s OAuth 2.0 credentials; those dynamic webhooks are then owned by that app and that app alone. This is fundamental to the whole concept of dynamic webhooks versus ‘normal’ webhooks that belong to users and which are created using Jira’s GUI.
I get the feeling that you’re confusing the two webhook types and you think those API endpoints are for managing those ‘normal’ webhooks, and you’ve also falsely assumed that, just because Service Accounts use OAuth 2.0 for their auth method to the REST API, that gives them identical functionality as registered OAuth 2.0 apps to manage dynamic webhooks too.
I think this is about all the advice I can provide on this topic. Maybe spend some time reading more about dynamic webhooks and the distinct differences between them and the other type.
I apologize if my previous message was not very clear. I am new to atlassian environment.
I wrote “only Forge and Connect apps can handle webhooks without needing manual intervention” because from what I have understood, OAuth 2.0 apps require a three-legged authentication which means a user has to log in manually at some point, which I do not want. I want to handle those webhooks without any manual intervention needed. I do not want to have to ask my user to fill in his credentials each time we will have to refresh the webhooks.
That was the first reason why I stopped looking into OAuth 2.0 apps and started looking into service account as I found it allowed to authenticate in OAuth 2.0 without needing three-legged. I also saw that Forge and Connect Apps can authenticate without three-legged. That is the reason why I mentioned service accounts, Forge and Connect apps as from what I understood those are the only options to request those webhook endpoints without requiring a user to register his credentials at some point.
If there is any way to have a “generic” OAuth 2.0 app that does not require three-legged authentication that would be perfect for me. But I have not found anything about this being an option.