Sending query through automation

Hi,

I’m trying to send a query through our automation software, VisualCron. I understand that this is a ShipHero support site (i.e. not a VisualCron support site), but I thought I’d ask here anyway just in case someone else is using the same tool.

I got an access token, and a query that works fine when run in the Altair chrome extension. When I choose the option “Copy as cURL”, I get this:

curl 'https://public-api.shiphero.com/graphql' -H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'Connection: keep-alive' -H 'Origin: chrome-extension://sdfijasdghsdifwfasdf' -H 'Authorization: Bearer MY_ACCESS_TOKEN' --data-binary '{"query":"query { \n user_quota { \n is_expired \n expiration_date \n time_remaining \n credits_remaining\n }\n}","variables":{}}' --compressed

Those are the parameters I’ve mimicked in my automation.

But it’s giving me this error:

All it says is “bad request”, but it doesn’t bother to tell me what’s “bad” about it. Looking at the “data-binary” parameter that shows up in the cURL, I see that it added more to my query, so I tried sending that:

This gave me the same error. Also, noting that apparently the data it’s sending is binary based on the parameter name, I tried putting my query in a text file and sending that, but still got the same error.

So I guess my question is, how do I tell why the request is “bad”?

@jrtwynam looks like the value of the token has some extra data, check it out those {TASK{ and }|StdOut)}. The bearer token is the value in between cc456022......2227

Yeah, that {TASK{ and }|StdOut)} part is a VisualCron variable that contains my access token. It gets substituted with the actual access token before sending the request, but I’ve also tried pasting the entire token in there instead and still got the same error.

The data sent to graphql needs to be formatted in a very specific way, you can see in the curl copy yo have, is sending it as --data-binary and using some quoting and some \n. I would try to reproduce exactly that payload, or maybe check how the graphql clients are actually encoding the payload to be able to reproduce it.

It seems you were right about the formatting. I took the “proper-looking” code and “uglified” it, and this version worked:

The problem now is that editing such ugly code is challenging, so I’ll need to figure out a way to allow me to paste the properly-formatted (i.e. human-readable) code and convert it to something like above before sending the request.