HTTP GET Calls with Headers


I'm really struggling with making HTTP GET calls.

I'm setting _url to the https URL, and _headers to a JSON object with an auth header.

If I use the following syntax:

let response := http("GET", _url, _headers);

.. Then the third argument, _headers, gets interpretted as a query string, and so the headers aren't interpretted - and I get an auth error.

If I use this syntax:

let response := http("GET", _url, _headers, null);

Then I can see that Ninox makes an OPTIONS request (which it does not do in the first example) and the server gives a 200 response. But Ninox just never actually does the GET after this. What am I doing wrong?


6replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
    • RoSoft_Steven
    • Ninox partner
    • RoSoft_Steven.1
    • 1 yr ago
    • Reported - view

    I have also experienced similar,
    I have found that when I use this it does work.

    do as server
    your code.....

    Maybe this will also work in your case?


  • Hi Steven


    Many thanks for the help! I seem to have the same thing when running on server.   I can't seem to get any error back (with either approach). Am posting here in case anyone can spot anything!


    let _api_key := """1/xxxxxxxxxxxxxxxa89""";
    let _headers := {
    Authorization: "Bearer " + _api_key
    let _project_id := "119xxxxxxxx4105";
    let _url := "https://app.asana.com/api/1.0/projects/" + _project_id + "/tasks/";
    let response := do as server
    http("GET", _url, _headers, null)
    if response.error then

    And the error I get is

    "Request failed: error -"

    • RoSoft_Steven
    • Ninox partner
    • RoSoft_Steven.1
    • 1 yr ago
    • Reported - view

    don't you need the content type also in your header?

    'Content-Type': "application/json"


  • Yes - good spot! I think it's good to have that header, too.  I took it out when debugging the OPTIONS response. But without that, Asana does still give a resonse (e.g. it does this with a simple GET in the browser, or when using curl); but there's no harm having it.

    Sadly makes no difference; doesn't look as if Ninox gets past the OPTIONS request --- it never actually seems to do a GET at all!

    If I remove the headers, then it does a GET (without bothering to do the OPTIONS); however, I then get an auth error, as expected :-(

  • I think I've identified the cause of the bug, and it was a really horrible one to spot.

    I think that Ninox fails if the header "Authorization" is used.  

    If I change that to any other word - for example, by changing the 'z' to and 's', then all works. But if I put the exact word Authorization, I get this failure without an error being given.

    I've tried this on many APIs, including PipeDream, which is for testing APIs.

    I suspect there's some filtering happening on Ninox's end, so that when it gets the response to the OPTIONS request (which also contains the word authorization), the filtering fails and causes the script to exit.

    I'm not sure how I can call any API that needs an authorization header? Has anyone else been able to? 


    Ninox's example fails in the same way, too:


  • Here's a quick video showing the issue:

Like Follow
  • 1 yr agoLast active
  • 6Replies
  • 565Views