REST query parameter keeps adding %EF%BB%BF

[Jake Noyd]

I've been trying to test a REST action and I'm fighting with a query parameter. When I run the call via curl I add 'return_records=true' after the path so that it returns some actual values and that works fine. In ServiceNow I'm adding that as a query parameter with return_records as the name and true as the value. When I test this it keeps inserting %EF%BB%BF after true which is screwing up the call. I've tried moving true into an input data pill as a string boolean but it still adds %EF%BB%BF. 

Anyone have an idea why it keeps adding this extra %EF%BB%BF and how I can avoid it?

[Tony Chatfield1]

Hi, without any details of your configuration or code the forum can only guess at the cause of your issue,
do you see the same behaviour via a toolset like Postman?

[Jake Noyd]

Hey Tony, using Postman I get a 200 response code and returned json of the records that I'm looking for. It doesn't add that extra %EF%BB%BF after 'return_records=true' in the query. Below is a screengrab of what I've entered. The two data pills are just manually entered inputs with the one labeled 15 being an integer with value 15, and the one labeled true is a string boolean with value true. If I get rid of the data pills and just type the values in as strings it adds the %EF%BB%BF after both so it appears to not like strings. 

[Jake Noyd · Accepted solution]

Well this is resolved but without real answers. Our ServiceNow instance broke my test action. When I clicked on it yesterday to do some more testing it said "This action cannot be found" but it still shows up in the action list so that's fun. Anyway, I recreated the action but when I recreated it I didn't do the query parameters at all and I left off the second 'accept' header. I ran it and it worked. I don't have a clear answer as to why this worked with less data being passed. I wish ServiceNow gave me more information about what exactly it was sending like how Postman or Insomnia does. Maybe that is in there somewhere but I don't see it. Anyway, I hope this helps someone else. 

[Jake Noyd]

Also another note for anyone that ends up here with similar issues. A normal string variable seems to always end up with extra hex junk in the output path/url. If you use a String (Full UTF-8) variable it seems to work just fine.

It's still kinda stupid and non-obvious. Maybe this is all fixed in the next update but working in San Diego it still feels a bit half baked. It seems like all the pros ignore this method and just do everything via javascript which I get, but my javascript skills are noobish and there is a section for queries so why struggle...but then it's not obvious so the struggle exists anyway. Hope this helps someone.