I have a Salesforce sandbox Connected App configured for OAuth 2.0 Client Credentials (Basic Auth header + grant type=client credentials) with a “Run As” Integration user. In Postman I set up a Collection-level OAuth2 auth, hit Get New Access Token and define variables. My GET and POST calls succeed
I then exported the Collection and sent it to a colleague.
She imported it and retrieved a valid token, but every request returns:
{ “errorCode”:“NOT_FOUND”, “message”:“The requested resource does not exist” }
It means that you are hitting the server, but that resource is not available.
First thing to check is that the URL and paths are correct. Get your colleague to check the console logs to see what was actually sent.
When you export a collection, it will only include the initial values. If you are reliant on information in the current values, then this won’t exist and your colleague will have to enter those details again.
Thank you very much for your answer! Now I tried importing the same collection again and I got the same error. Also, if I create a new collection and use the token from the previously imported one, the same error occurs again. And also the same if I create a new collection and generate a new token. Is there a possibility that there are some settings when the token is generated multiple times?
How does it compare to your original working request.
Invalid tokens would usually return an authentication error. 403 or a 401 instead of a 404 not found. Check the body and headers and ensure they are the same.
Client Credentials is fairly common and the authentication helper (aka the authentication tab) should just work.
However, you can also replicate that functionality by creating a standalone request to retrieve the token, using a post response script to save the token to an environment or collection variable to be used in the subsequent requests.
This can help sometimes in troubleshooting.
You would have to check the SalesForce documentation to see if there are any limits on the token usage but again I would expect a different response status code if the token was the issue.
Can you share the documentation from SalesForce that you are following alongside a screenshot of the failing request? (Redacted as appropriate).
Where are the variables in the URL being set? {{sf_api}} and {{integration_event}}
Collection variable, Environment variable?
When you look at the console logs for both requests, are they being transposed corrected into their respective values?
Your second basic example is another issue in that its not liking the query and producing a 404 bad request.
This is a client error, as in the client is sending the bad request. In this case, its doesn’t seem to allow you access to the accounts table. Does the particular token that is failing have access to that table. This is being pretty specific. It’s telling you that the account table is the issue. This isn’t an authentication error on face value.
Clone the working request (so hopefully you don’t break the working request).
Send the cloned request to check that it works.
If it works, then update the authentication header with the updated token and see if it works.
All the variables are set in Collection variable, I didn’t create Environment.
Yes, that token also has access.
I think there are some issues with the token. It can successfully authorize, but it is not working properly. Now my token that was working before has expired and after refreshing it is not working anymore. I get the same error as before for other tokens. Also, when I open the authorization in the collection, it was not written that my token expired, nor was it written when my token will expire.
And for the token that I have for the other system, it is written.
Client Credentials doesn’t requires user interaction, so you can craft a straight up request in the GUI to the token end point to retrieve a token.
You can then create a post response script to save the token in the JSON response to a collection variable.
Now that you can use external libraries in Postman more easily, you also might want to consider taking the token, and then pulling it apart to view the claims to ensure they look correct.
It will be something like.. (Untested as I don’t have a current token to play with).