j_quelly
j_quelly

Reputation: 1449

Salesforce Integration INVALID_SESSION_ID using Postman

When hitting https://login.salesforce.com/services/oauth2/token, using Postman.

POST https://login.salesforce.com/services/oauth2/token

enter image description here

Response:

enter image description here

I receive a token, but when I try to do something as simple as GET /limits,

GET https://na73.salesforce.com/services/data/v45.0/limits

enter image description here

the response is:

[
    {
        "message": "Session expired or invalid",
        "errorCode": "INVALID_SESSION_ID"
    }
]

The strange thing is that when I change all my credentials to a free "developer account" created with a different email address, everything works fine. All requests and headers are the exact same, with the exception of the values from either account.

After digging through a lot of threads on here I thought that maybe my production account (the one I'm posting from now) was not API ENABLED. It turns out my production account is API ENABLED.

I also tried changing https://login.salesforce.com/services/oauth2/token to https://na73.salesforce.com/services/oauth2/token as some threads have suggested, but that just times out.

When comparing both account permissions, they seem identical and I've confirmed I have no issues with the credentials (client id, client secret, security token, access-token), all of them seem to be copied in correctly.

Any ideas for a salesforce noob?

Upvotes: 17

Views: 30264

Answers (7)

jschleicher
jschleicher

Reputation: 73

if trying to complete the "Set Up and Connect Postman" trail and using a playground ( scratch org) or trying to hit any scratch org i believe we will need the "Get New Token" step to leverage the "{{_endpoint}}" variable and not the default "{{url}}.

The url environment variable is set to the standard "login.salesforce.com" .... which wont do much for orgs with custom domains setup. I'm pretty sure custom domains are standard with playgrounds and scratch orgs. I think that is what is being said here:

https://trailhead.salesforce.com/content/learn/modules/identity_login/identity_login_my_domain#:~:text=Because%20having%20a%20My%20Domain,your%20internal%20Salesforce%20org%20ID.

With this step I did not need the to make any adjustments to the GET Limits rest api settings in postman like "Follow Authorization Header"

enter image description here

Upvotes: 0

Nikitha Rangineni
Nikitha Rangineni

Reputation: 1

The problem here is, it is not validating the access token properly.

So, In postman go to Authorization section and select "Bearer Token" option and paste the token over there. It works

Upvotes: 0

Bloke
Bloke

Reputation: 2469

In my case, the _endpoint variable was not getting set after successfully authorising via the browser (should that not happen automatically?), so I had to set it manually -- but, I put the wrong URL for it (
https://whatever.lightning.force.com instead of
https://whatever.my.salesforce.com),
so I would get a 302 redirect to the correct URL, but then that one would return this message.

So changing the _endpoint variable to the correct URL fixed it for me.

Upvotes: 3

Apocawaka
Apocawaka

Reputation: 354

I actually fixed this after banging my head on it forever. You need to go into the settings tab and turn on the Follow Authorization Header setting.

Follow Authorization Header Setting

Upvotes: 33

lekant
lekant

Reputation: 1002

I had the same issue, even when activating the Follow Authorization Header

Basically, the Authorisation Bearer is not set directly, so I added it in the Pre-request script tab

pm.request.headers.add({key: 'Authorization', value: 'Bearer {{_accessToken}}' });

Works like a charm now.

Upvotes: 1

b2f
b2f

Reputation: 349

I'm here in 2021 and for me the solution was not 'Follow Authorization Header', but the access token had a different instance_url than expected. Use this instance_url value in _endpoint and you are fine.

Upvotes: 3

j_quelly
j_quelly

Reputation: 1449

After fighting with this for a few days, I've ruled out this is an issue with Postman. What garbage. Just follow https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/quickstart_code.htm and use curl commands instead. If I copy a raw curl command into postman then run, it continues to fail with INVALID_SESSION_ID, but works fine in ZSH

So much for a useful GUI

Upvotes: 1

Related Questions