[solved] Long-used API call coming back as unauthorized


I have a shell script with an invocation of curl to make a REST request (PUT) that I was using for many months. Its purpose is to toggle the is_streaming flag for a Camera.

But recently when I tried it, I get back an authorization problem:

I thought that access tokens were “effectively non-expiring”. Although I also find it strange that they have a specific expiration time set when they are created of 315360000 which I believe is 10 years. It certainly hasn’t been 10 years, and I’m not sure if that 10 years is even enforced given the “effectively non-expiring” documentation. It has been about 13 months.

So what caused this?
The application/project still shows up in the “Works with Nest” section in the corresponding user account as having permission to turn camera on/off.

What is the workaround here? Just go through the process to get a new auth code and then use it to get a new token?

My code does this:
curl -L -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer REDACTED" -d '{"devices": {"cameras": {"REDACTED": {"is_streaming": false}}}}' 'https://developer-api.nest.com/'

Edit: The solution is to add the --location-trusted option to curl to force it to pass such a header in redirects.


Hi @scooter,
That is definitely very odd behavior. The token should be active unless there was a deauth call.
Can you please try generating a new access token and see if this happens again for your client?

Meanwhile, I am testing this on our end.


Thanks @Luva. I figured it out. curl was not passing the Authorization header after it got a 307 Temporary Redirect initially. There is a warning about this here.

But I had checked this in the curl man page where it said:
WARNING: headers set with this option will be set in all requests - even after redirects are followed, like when told with -L, --location.

However, it seems that in curl 7.58.0 from January 24 2018, this was purposely changed to fix a security issue.

My situation was just complicated a bit by the fact that I was reading an outdated man page AND although my curl is before that version, the fix must have been backported for security. The original version of curl that I was using when I first wrote the script did not have this security fix, so it worked.

The solution is to add the --location-trusted option to curl to force it to pass such a header in redirects.


@scooter - I was having an similar issue with a virtual machine. After hours of pulling my hair out, this fixed the issue. Thanks for posting an update!