Web Request Node & Content-Type application/x-www-form-urlencoded Header in Automator

Looks like you need to sort out the authentication..

Authentication type “basic”

Then you’ll need your ID you are using, (we use a service account in the system and use the API Key from that.)

Password can be just ‘X’

Also you have not selected an orchestration server, have you set this up? - https://support.freshservice.com/en/support/solutions/articles/50000003259-setting-up-the-orchestration-server

I too am also having frustrating issues with this - did you ever find the solution?

I’m able to get a token in Postman with these identical settings in Postman (ID values redacted), but get the same error as Celliott with the following settings in a Web Request node:

For the API key you’re referring to, that seems to be the Freshservice API key - I didn’t think that would be needed in this case, as we’re calling an external API? As for authentication in getting an access token, I think that’s handled by the Application ClientID and Secret.

Also, does it absolutely need an Orchestration server? We get the response errors fine, so in theory we could get any successful response, but I could be wrong!

Cody

Ahh this may be the issue for us:
 

• Integrate SharePoint with Web Requests

The Web Request body text box mentions entering JSON data, which supports what SuperDOS writes.

@cody.pieper do you know if there is a way to convert from application/x-www-form-urlencoded to JSON?

In Freshservice, I don’t think so unfortunately.

You can of course get application/x-www-form-urlencoded to JSON in terms of data, it’s just a different format. The problem is that if you need to send a web request using a application/x-www-form-urlencoded body, it will still try to use JSON, even if you use a header ‘Content-Type’ = application/x-www-form-urlencoded.

Touch wood it’s implemented in the future!

Any news on this? I also need it to access the Graph API.

Hi @celliott and @pproost 

Microsoft Graph API calls the requires the parameters to be sent in urlencoded format, while FreshService body requires to be in JSON format. As of now, we support only JSON content-type parameters in the Web Request node, and we don't support if the URL is in an encoded format.

However, we do have a feature request for this and it would be available in our future releases. I apologize for not being of much help right now!

Cheers and Happy Holidays!😊

@Ammar KB I see you replied regarding the lack of application/x-www-form-urlencoded support in automation Web Request. Do you know if the work to add this feature has been scheduled for development? Thanks

Hi @Ammar KB,

Same question as Ben. Is there any information on the feature request being worked on already as it is quite important for us.

Thank you

Hi @Ammar KB,

After spending far too much time trying to figure out why our http post wasn’t working, I came across this thread as well.  A formal update on this issue or feature request would be appreciated so we can appropriately decide to wait or plan a workaround for MS graph api authorization.

I landed on to this thread spending hours trying to figure this out. I managed to get it working by adding some buffer before and after body within quotes. Like this:
 

I created an account on these forums specifically to thank you for finding this. 

Can you please share how/why “null&” for the beginning and end of this seems to work? I’m not too familiar with URL coding

Wow! It seems like (please correct me if I am wrong) that the null& trick forces freshservice to process the payload as a raw url encoded string. Then on the azure end, the parameters are ignored because they are invalid! That is pretty cool if it is the case. Not 100% sure about that though

I have tested this with Azure Runbooks and that seems correct. Since using this bit in any code that previously didn’t pass through, we’ve been able to use Azure Runbooks in conjunction with FreshService to make a LOT more progress on our org’s automations. 

Thanks again!

It looks like you're missing the "grant_type" parameter in your request body. Adding that should fix the issue, much like how Brits always make sure their tea is steeped just right in any situation, even tech ones! xxbrits

I had “grant_type” declared as well and still had the issue. Indeed the trick mentioned is what resolves the issue (until freshworks adds support)!

Hey All,

I encountered this issue as well, but I went further and played around with different formatting styles for the request body. Eventually, this also worked:

"&grant_type=client_credentials&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&"

Also, I tested with the buffer only at the beginning or end. I found that if I placed the buffer at the beginning, I got a different error:

AADSTS1002012: The provided value for scope https://graph.microsoft.com/.default\" is not valid. Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI).

So, I think the reason it’s failing is because the FS workflow automator is inserting escape characters behind the quotes. Thus, when you don’t have a buffer at the beginning, it’s picking up the first parameter name as \”grant_type instead of just grant_type, throwing the original error someone referenced. Once I put the ampersand at the beginning but not the end, it properly picked up the first parameter, but the value of the last parameter got the \” stuck at the tail end (as seen in the error message). MS servers are just splitting on the ampersand and then the equal to generate a little hash table of all the param names and values. It probably doesn’t matter that you pass it nonsense (I also tried beep=boop& and it worked), because it just never references those values.

I have a ticket in with them about this, as originally I was using their credential store for this so I don’t have to build the auth flow every time I need it, and it randomly stopped working entirely. It won’t generate a token at all.

Anyway, I hope that’s useful to someone out there. Hopefully, they resolve this.