OAuth setup help

Issue :
Setting up OAuth on jira cloud for a specific user based on documentation online.

reproduce steps for our current setup:
steps 1-4 summary under the user we have created the OAuth app,

Step 5 We are not sure about the Callback URL (currently set to The jira CLOUD insance )

added API = Jira platform REST API–> read:jira-work

In the documentation step called “1–direct-the-user-to-the-authorization-url-to-get-an-authorization-code”

we have set the following: (the state option is unclear)


The user is able to log in manually via web and see data.

Expected Outcome:
is able to make successful secure API calls e.g. via postman towards Cloud Instance with OAUTH

Welcome to the Atlassian developer community @MartinStrm,

The callback URL (aka the redirect_uri) is an essential part of the OAuth 2.0 authorization code flow. It cannot be your Jira instance. In a real OAuth 2.0 app, there would be a special path for accepting the authorization code and exchanging it for an authorization token. As the docs explain:

If successful, the user will be redirected to the app’s callback URL, with an authorization code provided as a query parameter called code . This code can be exchanged for an access token, as described in step 2.

When all you want to do is use Postman, then you have to make a “fake” callback URL and you will need to perform the code exchange as a manual step in Postman. You need a website that won’t strip URL parameters. I recommend using https://httpbin.org/anything. This value must be set in both the developer console and changed in your authorization request URL (what you provided as example). You will want to execute this URL in a browser, not Postman.

For your scenario, state really won’t matter. Whatever you provide, will be sent back to the callback URL. A real app should confirm this value, but you can do that by eye. Personally, I like to send a generated UUID4 when using simple HTTP clients like Postman, but any string will do.

Pro-tip: For Postman, I recommend using the offline_access and read:me scopes too. The offline_access will let you use a refresh token and will save some tedious steps. And read:me is just a useful way to check the user associated with your token (it can get confusing sometimes, even if you are the only one performing the “OAuth dance”).