Salesforce Integration INVALID_SESSION_ID using Postman

Question

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

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

Response:

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

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?

Edit the question and post your whole "GET limits" request. I mean especially the "Authorization" HTTP header, I want to see in there the "Bearer sessionidgoeshere" (you can truncate/obfuscate the id if you're paranoid). "/limits" is not a right endpoint, it'd be something like "/services/data/v45.0/limits" unless you just typed it here in a hurry. Using My Domain vs login.salesforce.com matters only when logging in. Past that you should use the endpoint (and session id) that was returned to you from the login call. — eyescream, May 13 '19 at 21:17
`instance_url` you got back says "na73", you sent GET to "mi73". Typo here in stackoverflow or really in Postman? Otherwise all looks good — eyescream, May 14 '19 at 05:02
Running out of ideas here. If you logged in all right it should all "just work". Try GET'ing the url you got back in the login's response under `id` parameter, it should return some info about your own user. Try another URL like `/services/data/v45.0/query?q=SELECT+id,name+FROM+user+LIMIT+5`. Try in another app like https://workbench.developerforce.com -> utilities -> REST explorer? Maybe something in Postman doesn't pass the variables right / mangles the session id (unnecessary urlencoding maybe?) — eyescream, May 14 '19 at 16:23
I agree, it should "just work", but it doesn't. I GET `https://login.salesforce.com/id/00D1I000000kiBrUAI/0051I000004VGU1QAO` and it returns some information about my account. I doubt it's postman. As I mentioned in the post, this works fine with another free "developer" account. When I try to hit `{{instance-url}}/services/data/v45.0/query?q=SELECT+id,name+FROM+user+LIMIT+5` as suggested, I still get `INVALID_SESSION_ID`. Workbench seems to work, but nothing via Postman. POS — j_quelly, May 14 '19 at 16:59

score 28 · Accepted Answer · edited Aug 09 '22 at 21:17

28

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

edited Aug 09 '22 at 21:17

isherwood

58,414
16
114
157

answered Oct 18 '19 at 14:40

Apocawaka

304
3
3

I just had the same issue, and whilst this half-fixed the issue for me, it wasn't right. Eg. when creating a record using this method, it didn't actually create the record. However, this gave me a clue - and if I turned off "Automatically follow redirects" in Postman, then the 'Location' in the response header told me what my domain name _should_ have been. Fixing this in my initial request, fixed the issue. 'Follow Auth Header' option no longer required and can use Postman defaults - and it also successfully created the record. – Dan Jun 14 '21 at 15:17
Just wanted to note that when I used "bearer token" and Postman's "use token" button, it pasted the id_token in the authorization header. Make sure you are passing the access token. – Cleverlemming Oct 29 '21 at 04:16

score 3 · Answer 2 · answered Jun 21 '21 at 13:43

3

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.

answered Jun 21 '21 at 13:43

b2f

196
2
10

score 1 · Answer 3 · answered May 14 '19 at 17:19

1

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

answered May 14 '19 at 17:19

j_quelly

1,399
4
16
37

Did you try @Apocawaka solution to modify the setting on Postman? It resolved for me after making the `Follow Authorization Header` change – usernameabc Apr 13 '20 at 18:00
1

Your opening rant is contradictory. Either you've ruled out the possibility that the problem was Postman (meaning it _isn't_), or you've determined that it _is_ a problem with Postman. Please revise to clarify. – isherwood Aug 09 '22 at 21:19

score 1 · Answer 4 · answered Mar 17 '22 at 11:45

1

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.

answered Mar 17 '22 at 11:45

lekant

992
9
14

1

Surprising that no one selected this answer. This is it. I wonder how did it work without it. Took me hours of googling and I was about to add the header manually. Thanks @lekant – Tauqir Feb 23 '23 at 07:14

score 1 · Answer 5 · answered Nov 01 '22 at 18:34

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.

Nikitha Rangineni · Answer 6 · 2023-03-25T18:55:03.153

0

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

edited Mar 25 '23 at 18:55

answered Mar 25 '23 at 18:53

Nikitha Rangineni

1
1

Salesforce Integration INVALID_SESSION_ID using Postman

6 Answers6