Postman is just my testing environment, but I think I can assume that any OAuth2.0 library I use will retrieve the access key for me in the same way. Providing the value "email_read" in the scopes section of the Authorization tab finally gave me a 200 OK response. So I googled what scopes are needed for each endpoint, which are all listed here. It was passing the parameter but leaving the values blank, which Marketing Cloud interprets as "no scopes are allowed", not "all scopes are allowed". Since the scope parameter isn't actually required, I thought that leaving it blank would make it default to all of the scopes enabled in the component setup.īut I realized that Postman isn't actually omitting the scope parameter when I leave it blank in the Authorization tab. ![]() More googling led me to this question, where a comment by our almighty lord and savior Gortonington mentioned that this error will show up if the scope passed in the authentication call doesn't match the scope of the API component. The documentation for that error made me think that my user credentials didn't allow me to make API calls, ( this question has a helpful comment showing exactly what permission the role needs to have) so I went through my roles and permissions in my sandbox environment and enabled everything, logged out, and then back in. Does that mean that my user credentials don't have permission to call an API? Or does it mean something else about my request is failing?Īfter forking the collection posted by Aaron Cates, I was able to get the authentication to work! I was correct in my theory that the OAuth2.0 flow was making the token request for me, so I didn't need to make a call to the v2/token endpoint.Īfter securing the access key and trying the v1/validateEmail request recommended in the collection's setup instructions, I kept getting the response: "message": "Insufficient privileges to complete this action.", For my testing purposes, I've checked every box in the scope of the app setup, including offline access. But that gives me an error saying that "API permission failed". (it's also used as a Bearer token in the authorization header). In that case, the authorization code has already been exchanged for an access key, so it's no longer valid.Īssuming that's the case, I've tried using the Access Key in the header of a SOAP request. This is my first time ever using an OAuth2.0 workflow, so I'm not sure, but it occurs to me that the reason the codes are different and my token request is failing is that Postman has already made the token request using the authorization code provided to the callback URL. Both result in an "invalid authorization code" error. In the next screenshot, I use the value appended to the callback URL as the "code" parameter in my request, but I've also tried using the access code that was retrieved by Postman. Once I get the authorization code, I try to make a call to the v2/token endpoint to obtain an access key, following this documentation. Why are these values different? Where is Postman even getting this different access key information if not from the code appended to the callback URL? Last few characters of the Access Token retrieved by Postman: Last few characters of the code appended to the callback URL: ![]() If I compare the Access Token that's been received by Postman to the "code" parameter returned in the callback URL, they are not the same. When I go back to Postman, it presents me with information about the token I've just received. My browser redirects to the Callback URL for postman and tells me my call is authenticated. Then I'm taken out to my browser, where I log in to Salesforce. I have created a web app component in Salesforce Marketing Cloud, and now I'm trying to get the OAuth2.0 flow to work in Postman.įirst, I use the Authorization tab in Postman to request a token.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |