Failing Callback via Oauth

Question

We are facing an Atlassian OAuth 2.0 callback issue.

The important point is that the QA callback URL itself works with one existing Atlassian OAuth app.

However, when we configure the exact same QA callback URL in other/new Atlassian OAuth apps after changing the configuarations like callback url and secret/ID but all other scopes and permission remain same as the older app, the callback fails with:

{"error":{"category":"bad-request"}}

We have tested this with 4–5 newly created apps, including apps created from a different Atlassian account, and they all fail.

So the issue does not appear to be with the QA callback URL itself. It seems specific to how newer/different Atlassian OAuth apps are handling the callback.

Could you please help us identify what configuration, app setting, or Atlassian-side difference is causing only one app to work while the others fail?

Josh · Answer

Hi Yash, your rate-limit tier finding is the strongest clue in this thread. If the working app shows a tier and every new app (including ones from a different account) shows "-", while client ID/secret validate, scopes match, and the 400 comes from Atlassian's own /oauth2/authorize/server/consent/grant call, then you've ruled out almost everything on your side. Only Atlassian can check how the app was provisioned.

To your question: yes, that's for developer support, not Community. The route is developer.atlassian.com/support (Developer and marketplace support, which now forwards into the main Atlassian support portal). To get past first-line triage quickly, include:

* The client ID of the working app and of one or two failing apps (full IDs are fine in a support ticket, just never the secrets)
* UTC timestamps of a failed and a successful consent attempt
* The request and response for the failing consent/grant call, from a HAR file or the browser network tab (redact cookies)
* The Developer Console screenshot showing Tier 1 on the working app and "-" on the failing one
* The fact that a minimal classic-only request (read:jira-work offline_access) fails too. That rules out scope mismatch straight away.

It's also worth posting the same summary (without IDs) on the developer community forum, community.developer.atlassian.com. If other vendors are seeing new 3LO apps created without a tier, you'll find out there, and Atlassian developer relations staff do read that forum.

yash.virmani · Answer

Thanks. We've checked both points:

* audience: our authorize request always sends audience=api.atlassian.com.
* Scopes: the new app has the same scopes enabled as our working app, both classic and granular, and every scope we request is added. The new app failed even with a minimal classic-only request (read:jira-work offline_access). On our working app, classic-only, mixed and granular-only (read:project:jira offline_access) requests all succeed.

yash.virmani · Answer

Thanks for the reply @Tomislav Tobijas we've checked all three: * redirect_uri: identical, character for character, to the callback URL registered on the app (https, no trailing slash, no query), and sent unchanged on both the authorize and token requests. * state: our state is a 43-char random value and is present on the authorize request. The state=undefined is on Atlassian's own consent/grant call, and our working app's flow shows exactly the same state=undefined and succeeds, so it isn't the cause. * Connected apps: the app was created by an org admin; there's no approval requirement or block on it. Also: it's an OAuth 2.0 (3LO) app, not Forge; the client ID/secret validate against the token endpoint; and scopes, sharing, owner, site and user are identical to our working app. The one difference we found: in the Developer Console, the working app's Rate limit tier is Tier 1 – Global Pool, but the failing app's tier is empty (-). Since Tier 1 is supposed to be the default for every app, this looks like the new app wasn't fully set up on Atlassian's side, which would explain POST /oauth2/authorize/server/consent/grant returning a bare 400 on Accept (the consent screen itself renders fine). Is this something the Developer Support team can fix? Client ID: iGsmve8... Failure: 2026-09-23 06:43 UTC Sanitized request below. Step 1 (as decoded from the consent context): authorize request GET https://auth.atlassian.com/authorize ?audience=api.atlassian.com &client_id=iGsmve8... &redirect_uri=https://qa.enterprise.secondbrain.global/org-settings/integrations/jira/connect/return &state=<43-char random value> &response_type=code &prompt=consent &scope=manage:jira-webhook offline_access read:audit-log:jira read:board-scope.admin:jira-software read:board-scope:jira-software read:epic:jira-software read:issue-details:jira read:jira-user read:jira-work read:jql:jira read:permission-scheme:jira read:permission:jira read:project:jira read:screen:jira read:sprint:jira-software read:user:jira → consent screen renders normally Step 2: user clicks "Accept" → Atlassian's consent page sends POST https://api.atlassian.com/oauth2/authorize/server/consent/grant ?state=undefined&auth0Url=https://auth.atlassian.com/authorize&context= -H 'content-type: application/json' -H 'origin: https://api.atlassian.com' -b '' --data-raw '{"cloudId":"","egressPermissions":[], "scopes":[], "isAccountBased":true}' → HTTP 400 "Bad Request" (no detail in the body) Failed at 2026-09-23 06:43 UTC