POST /rest/api/3/webhook returns HTTP 500 (FAILURE_ORIGIN) for OAuth 2.0 service-account (2LO / clie

Osama Sayed_eil4jx

Summary

Registering a dynamic webhook via POST /rest/api/3/webhook returns an unhandled HTTP 500 (x-failure-category: FAILURE_ORIGIN, text/html, empty body) when the request is authenticated with an OAuth 2.0 service-account access token obtained via the client_credentials (2LO) grant; even though the token carries the required manage:jira-webhook scope. The identical request with a 3LO (user-authorized) OAuth 2.0 token succeeds. Either service-account tokens should be supported for this endpoint, or the API should return a documented 4xx (as it already does for other unsupported credential types) instead of a 500.

Environment

• App: OAuth 2.0 integration (not Connect/Forge).
• Credential under test: 2LO service account; token minted via POST <a href="https://auth.atlassian.com/oauth/token" rel="noopener nofollow noreferrer" target="_blank">https://auth.atlassian.com/oauth/token</a> with grant_type=client_credentials, audience=api.atlassian.com.
• Access-token claims (decoded): "<a href="https://atlassian.com/3lo" rel="noopener noreferrer" target="_blank">https://atlassian.com/3lo</a>": false, "<a href="https://atlassian.com/authProfile" rel="noopener noreferrer" target="_blank">https://atlassian.com/authProfile</a>": "oauth.adminhub.serviceAccount2LO", sub: "<client_id>@clients", scope: "manage:jira-webhook read:field:jira read:jira-user read:jira-work write:jira-work".

Steps to reproduce

1. Mint a service-account token:
   curl -X POST https://auth.atlassian.com/oauth/token \

   -H 'Content-Type: application/json' \

   -d '{"grant_type":"client_credentials","client_id":"<SERVICE_ACCOUNT_CLIENT_ID>","client_secret":"<SECRET>","audience":"api.atlassian.com"}'
   (Returns an access token with manage:jira-webhook, 3lo=false, authProfile=oauth.adminhub.serviceAccount2LO.)
2. Register a webhook with that token:
   curl -i -X POST \

   'https://api.atlassian.com/ex/jira/<CLOUD_ID >/rest/api/3/webhook' \

   -H 'Authorization: Bearer <SERVICE_ACCOUNT_ACCESS_TOKEN>' \

   -H 'Accept: application/json' \

   -H 'Content-Type: application/json' \

   -d '{"url":"https://<your-allowlisted-callback-host>/webhook","webhooks":[{"events":["jira:issue_updated"],"jqlFilter":"project = \"OT2\""}]}'

Expected
Either (a) the webhook is registered and webhookRegistrationResult[].createdWebhookId is returned, or (b) a documented 4xx explaining the credential type isn't supported — e.g. the way a scoped/API-token request returns 403 {"errorMessages":["Only Connect and OAuth 2.0 apps can use this operation"]}.

Actual

HTTP/1.1 500

content-type: text/html;charset=UTF-8

x-failure-category: FAILURE_ORIGIN

x-arequestid: dfe789acfec52b94a3a0fda99caab303

(empty body)

No JSON error, no errorMessages; impossible to handle programmatically. Please check the origin logs for request id dfe789acfec52b94a3a0fda99caab303.

Behaviour across credential types on the same endpoint (this is the core of the report)

Credential	Result
OAuth 2.0 3LO (user-authorized), manage:jira-webhook	✅ 200, createdWebhookId returned
Scoped API token	⛔ 403 — clean, documented (Only Connect and OAuth 2.0 apps…)
OAuth 2.0 2LO service account (client_credentials), manage:jira-webhook	❌ 500 FAILURE_ORIGIN, empty HTML body

Questions / ask

1. Are dynamic webhooks (/rest/api/3/webhook) supported for OAuth 2.0 service-account (client_credentials) tokens? Service accounts are offered as a way for apps to act without a user, yet dynamic webhooks appear to require a per-user owner ("N webhooks per app per user").
2. If supported → the 500 is a server-side bug; please investigate via the request id above.
3. If not supported → please return a documented 4xx (like the scoped-token case) and note the limitation in the webhooks docs, so integrators can detect it and guide users to a 3LO connection instead of hitting an opaque 500.

Germán Morales

Hi @Osama Sayed , confirmed: registering dynamic webhooks via POST /rest/api/3/webhook is designed around a 3LO (user-authorized) context, not client_credentials. The Webhooks docs state the registration limit as "5 webhooks per app per user on a tenant", so the endpoint expects a user to be attached to the webhook. A 2LO service-account token has no user, which is why you get an unhandled 500 instead of the clean 403 a scoped API token gets on the same endpoint.

This isn't a one-off bug on your account: JRACLOUD-79108, the request to let OAuth 2.0 apps act "asApp" with client_credentials (webhook registration was explicitly one of the use cases), was closed as "Timed out" in November 2024. It was never built.

Practically: keep registering dynamic webhooks with your 3LO token, that's the only supported path today. The 500 itself (instead of a documented 4xx) is a separate, legitimate bug to raise, since JRACLOUD-79108 only covers the missing feature, not the broken error handling. Include your request id when you file it.