Trouble with REST API Put Request

Hi there Apilio community,
I’m quite new to using Apilio but have found it very useful in my home automation journey. My original plan was to pair up Apilio and IFTTT (as a lot of people seem to do) but am finding things get quite complex quite quickly. I have now decided to run custom (python) programs on Raspberry Pi with calls to read inputs (control actions) from Apilio variables, and write outputs to Apilio variables (the results of the control actions). The design principal being I only want outbound traffic from my home (no open ports). Things are going well.

I’m hitting a snag with updating Apilio variable using PUT request. I consistently get status code 500 with this returned:
{“error”:“param is missing or the value is empty: boolean_variable\nDid you mean? {“boolean_variable”: {“value”:false}}\n controller\n action\n uuid”}

GET requests are working:
curl -u : --location --request GET ‘’ --header ‘Accept: application/json’

But PUT requests aren’t:
curl -u : --location --request PUT ‘’ --header ‘Accept: application/json’ --data-raw ‘{“boolean_variable”: {“value”: false}}’

I don’t expect there’s an issue, I think I’ve got some syntax wrong (or somethings else wrong). Can anyone point me in the right direction.

I get the same issue with numeric, string or boolean variables.

I appreciate any help.

1 Like

Thanks James, @pebneter (the :mage:t2:) is probably best place to help with this question. Love the architecture, sounds exciting and would be great if you could share a little more at some stage!

Thanks @DanT . Yes, I hope @pebneter can help :slight_smile:

BTW looks like my syntax curl command syntax was parsed what is should say is:

GET requests are working:
curl -u username:password --location --request GET ‘’ --header ‘Accept: application/json’

(where username, password and uuid are variables)

But PUT requests aren’t:
curl -u username:password --location --request PUT ‘’ --header ‘Accept: application/json’ --data-raw ‘{“boolean_variable”: {“value”: false}}’

(where username, password and uuid are variables)

Doesn’t seem to matter whether I use my python script, postman or curl I seem to get consistent 200 response for GET, and consistent 500 response for PUT.

Oh, BTW, I know I can update variables using web hooks but use wanted to use REST API for everything to keep it clean but will use web hooks for updates if need be.

Appreciate any help.
Thanks for responding @DanT

1 Like

Hi James,
I did a quick analysis to reproduce your problem.
I was able to do so and adding a header "–header ‘Content-Type: application/json’ " helped.
Can you try it?

In any case, we will investigate further and either fix the bug or adapt the documentation.


Thank you @pebneter !

You are spot on. The GET requests don’t require the "–header ‘Content-Type: application/json’ " BUT the PUT requests do. I have verified adding this to the header makes the PUT request work within postman, curl and my custom python program.

So for completeness for the Apilio Community this works:

curl -u username:password --location --request PUT ‘’ --header ‘Accept: application/json’ --header ‘Content-Type: application/json’ --data-raw ‘{“boolean_variable”: {“value”: false}}’

(where username, password and uuid are variables)

BTW - I really like Apilio!

Also, a bug(?) report…the successful PUT request doesn’t seem to log an event like I’d expect it to. Updating values via the Apilio Web UI does create a log record, whereas the REST PUT doesn’t. Doesn’t bother me as I’m not after that level of auditing but it looks like an omission.

Thanks for all the hard work!

1 Like

And in response to my own comment:

The GET requests don’t require the "–header ‘Content-Type: application/json’ " BUT the PUT requests do.

This is expected as the GET request doesn’t have a payload, whereas the PUT request does. So looks like not a bug at all but the doco needs to be updated.

Thanks again for the quick response.

1 Like

Hi @James ,
we are going to deploy a fix soon that changes the requirements for the requests:

  • Accept header is no longer necessary (as for now, the API will always return JSON)
  • The Content-Type header is required (and will be documented) for all requests except GET. If we can’t find it in the request, the system will respond with a more helpful error message.

I think you don’t need to update your script immediately as the supplied accept header should not cause an issue.

Thanks for reporting the issue!


No problems. Thanks.
Will you post here when the fix is deployed?

1 Like

Yes, going to be soon this afternoon.

1 Like

We deployed the fix - the documentation will be updated soon.

1 Like

@pebneter - Thanks, I tested the removeal of the Accept header just now and all is working well.

I see that you’ve fixed this too. Thank you.