Reputation: 1449
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?
Upvotes: 17
Views: 30264
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:
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"
Upvotes: 0
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
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
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.
Upvotes: 33
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
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
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