Weather API - can't get new tokens

Tawi

February 20, 2025 09:01
23 comments

My solution has been able to handle the tokens for months. Unfortunately, there has been a problem with receiving new tokens since last night. Does anyone else have this problem? "An error occured while trying to retrieve your tokens Reason: bad request"

Comments

23 comments

mailpublic35
- February 20, 2025 16:49
Hello,
my feedback: my script is running as usual, no issue. the access_token is refreshed every three hours.
Bad request ... may be it is not enough
Is there a code?
(see the posts https://helpcenter.netatmo.com/hc/fr/community/posts/23896792864658-API-homesdata-and-homestatus)

Phil [ just a user ]

1
Tawi
- February 20, 2025 17:45
Thank you. I have already replaced everything today.
Actually something was or is wrong with my app in the dev portal.
I don't have any information yet.

0
mailpublic35
- February 20, 2025 17:56
If it can help you, I shared the php script I use to manage tokens on github
https://github.com/Phil353556/netatmo-manage-tokens
Phil

0
david.milanuncios
- February 21, 2025 10:37
I'm getting the same error:

"An error occured while trying to retrieve your tokens Reason: bad request"

since a few days... and I'm unable to retrieve any token...

0
mailpublic35
- February 21, 2025 11:03
Hello,
strange, as there is only very very low activity on https://downdetector.co.uk/status/netatmo/ or https://downdetector.fr/statut/netatmo/

May I kindly ask you to test with my php script?

Phil [ just a user ]

0
Tawi
- February 21, 2025 11:53
Try a new app (new credentials) in the dev portal. That was probably my solution yesterday after the new code didn't work either.
An active app apparently says nothing about the status.

Everything works for me again. I suspect a new “clever” logic is blocking access.

-1
Leslie Community moderator
- February 21, 2025 14:41
Hello all,

For those still having this problem : can you try to create a new developer app and use the new generated values ?

We pushed an infrastructure change on Monday, 17, but I doubt it's linked to this (you should have been blocked since Monday in this case) :

Action Required:

3rd party developers: Please ensure that there are no HTTP response IP filters on your side and that you have an up-to-date HTTP stack.

@Tawi can we continue the discussion here so that I close your ticket ?

Have a good day,

Leslie - Community Manager

2
Tawi
- February 21, 2025 17:23
@Leslie

Thanks for the update. So there have been changes after all. :D
No problem. The history also helps other users here.

1
david.milanuncios
- February 24, 2025 14:06
I've tried also with a new dev APP, reseting ID and secret...

still getting error "bad request" and can't get tokens...

also, i've tried generating manually the access & refresh tokens from the webapp and still can't use them... getting the same error "bad request"

2
hans-juergen
- February 24, 2025 15:07
Same problem with "new Tokens". The last timestamp i manage to get access to netatmo weather station was 17.2.2025 09:45:00 (i call the station every 30 minutes).

My logic is working without changes since July 2023.

@Leslie
Is there an official workaround?

0
Leslie Community moderator
- February 24, 2025 15:28
Hello,

According to the timing, I'm pretty sure it's linked to an HTTP stack not up-to-date (see my message above). Can you please check that ? Meanwhile I'll ask the question to the developers

Have a good day,

Leslie - Community Manager

0
Leslie Community moderator
- Edited February 24, 2025 15:50
Can you please write me via the API contact form and send me a precise request + exact answer to investigate ?

Have a good day,

Leslie - Community Manager

0
david.milanuncios
- February 25, 2025 15:20
The same here. Last read 2025-02-17 09:56:12, and I also refreshed tokens every hour or so...

"HTTP stack not up-to-date" is not the problem... Ask the developers because you've got something wrong since feb 17

0
Leslie Community moderator
- February 25, 2025 15:30
Same as above, I would need the exact request + response sent

Do you still use the same refresh_token value since feb 17 ? Did you try to redo an /authorize request to get a new working pair of access/refresh token ? You can also generate new values via the token generator and try to see if this value reestablishs the refresh token flow

Have a good day,

Leslie - Community Manager

1
david.milanuncios
- February 25, 2025 16:00
no. I've tried also with a new dev APP, reseting ID and secret...

still getting error "bad request" and can't get tokens...

also, i've tried generating manually the access & refresh tokens from the webapp and still can't use them... getting the same error "bad request"

0
hans-juergen
- February 25, 2025 16:34
I tried to generate new values via the token generator some days ago. I replaced my own (old) "refresh_token" with the generated one.

That produces the same error "bad request".

FYI

0
Leslie Community moderator
- February 26, 2025 15:08
Hello all,

@hans-juergen, I well received your PHP snippet (thanks for this) but it will not help teams to investigate

More precisely what we need is : the request with the full URL and parameters, as well as some details on the HTTP client used. If possible, could you reproduce it using curl or postman or similar and post the output here (http headers included ideally) ?

@all, don't hesitate to send me the needed infos for investigation

Have a good day,

Leslie - Community Manager

0
Leslie Community moderator
- February 27, 2025 08:35
Hello all,

Some "good" news : we managed to reproduce the problem while using this SDK : Pull requests · Netatmo/Netatmo-API-PHP · GitHub

Can you tell me if you use it ?

Also, do you use this Content-Type in the Header of your requests ? Content-Type: application/x-www-form-urlencoded;charset=UTF-8

Have a good day,

Leslie - Community Manager

1
Tawi
- February 27, 2025 08:45
Exactly. My previous solution was based on this until the current problem.

0
Leslie Community moderator
- Edited February 27, 2025 10:51
Re all,

And the real good news now : we found out the problem. Following the change, the SDK doesn't interpret correctly the response as we respond in http/2 now and not anymore in http/1.1

We updated the repository to show the change to perform : https://github.com/Netatmo/Netatmo-API-PHP/pull/48/files

Please make me a feedback to tell me if it's now OK

Have a good day,

Leslie - Community Manager

0
david.milanuncios
- Edited February 27, 2025 12:13
thanks!... game on...

yeah, I was using that PHP component (Netatmo-API-PHP)

Applied manually these changes:

https://github.com/Netatmo/Netatmo-API-PHP/pull/48/commits/ae64cca11eb142eefec67a59b00bf1484e15e7e3

The strange thing is that i have the old version still working flawless in another account and server...

1
hans-juergen
- February 27, 2025 15:31
Thank you! That was the solution.

I applied the 3 changes manually, too.

To be on the safe side, i manually created a new "refresh_token" with your Website and put it into my logic.

Now the old API ist working fine. I got the weather data from my station.

2
nono303
- Edited March 02, 2025 15:41
Hi @Leslie

21-02 We pushed an infrastructure change on Monday, 17, but I doubt it's linked to this

Were is the public accessible changelog concerning this change? As a registered Netatmo API end-user, I didn't received any notification (same as already asked on 19350099833490)

21-02 but I doubt it's linked to this

In fact, it's linked to this and if you have industrial observability on your API server you may have seen that after your change, 400 errors exploded

27-02 And the real good news now: we found out the problem

Wrong!
You find that someone else issue about the change (me 10 days before on #47) propose a fix and @fabienduval made the PR on the Netatmo-API-PHP project

Please be respectful of other people's work and don't take credit for the solution mentioning them at least them and reference this thread on Github PR's you mentioned!

27-02 the response as we respond in http/2 now and not anymore in http/1.1

Wrong!
Your server will respond according to the client support.

In the case of the PHP API, it will depend on cURL nghttp2 support at compile time. So, if cURL used by PHP is don't support http/2, it will request on http/1.1 protocol and your server will answer 200 with http/1.1 support. I've just checked it:
- Response through Netatmo-API-PHP wit cURL compiled USE_NGHTTP2=OFF
HTTP/1.1 200 OK
Date: Sun, 02 Mar 2025 14:22:32 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, must-revalidate
Expires: 0
X-XSS-Protection: 1; mode=block
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Powered-By: Netatmo
x-azure-ref: 20250302T142232Z-xxxxxxxxxxxxxxxxxxxxxx
X-Cache: CONFIG_NOCACHE
- Response through Netatmo-API-PHP wit cURL compiled USE_NGHTTP2=ON
```
HTTP/2 200 
date: Sun, 02 Mar 2025 14:26:21 GMT
content-type: application/json; charset=utf-8
cache-control: no-cache, must-revalidate
expires: 0
x-xss-protection: 1; mode=block
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubDomains
x-powered-by: Netatmo
x-azure-ref: 20250302T142621Z-xxxxxxxxxxxxxxxxxxxxxx
x-cache: CONFIG_NOCACHE
```
Sorry if my post seems unpleasant but since this is not the first time that users ask for traceability and transparency on your changes that impact them and make them waste too much time, it would be good to take this into account and take the necessary action plan.

If the Netatmo API is not intended to be an industrial product with a QoS (SLA) guarantee (which is currently not the case), at least give your customers the possibility to directly push the metrics of their devices to their private local server without having to use your public API.
3