Hi,
I'm working with a graphql resource with oauth2 (client_credentials) authentication. I can set things up in Postman and properly interface with the resource but I'm having issues in Retool. The weirdest issue I'm seeing is that if I have:
{
Authorization: Bearer OAUTH2_TOKEN
}
In the resource headers, I see the following in the actual request:
{
"Content-Type": "application/json",
"Authorization": "Bearer OAUTH2_TOKEN"
}
If I add content-type: application/json to the headers section, I see this in the request:
{
"Authorization": "<actual token>",
"Content-Type": "application/json",
"content-type": "application/json"
}
Any idea why the OAUTH2_TOKEN variable isn't being resolved in the former case but it is in the later? FYI, if I take the stored token from Postman (or from the later case) and change the header to just be:
{
Authorization: Bearer <actual token>
}
Everything works.
Thanks,
Andrew
Hey Andrew! Would you mind sharing a screenshot of your resource setup page? Definitely curious that Authorization: Bearer <actual token> works in Postman and Retool, but passing in a dynamic token requires you to set the Content-Type. Do you know if this is a limitation on your API's side by any chance?
Hi Victoria,
Thanks for the response. I've attached my setup. However, I just tried changing the Authorization URL to Nexar - Reinventing the Business of Electronics (even though it's not used in client credentials I don't believe), it now works. Not sure why the Authorize URL would cause those issues but it seems to be resolved, thanks.
Andrew
I also removed the content-type: application/json.
That is super strange! Well, either way, glad it's working for you now and thank you for sharing the fix in case any other users run into something similar. 
Hello, just to say we have exactly the same use case are seeing exactly the same problem in some of our calls.
We're going to try adding in the content-type to see if it resolves the problem for us as well.
