Inconsistent Rate Limits for Netatmo Home + Control API
Hi,
I am using the Netatmo Home + Control API interface to monitor sensors on a bTicino Smarther2 thermostat (and, occasionally, control its functions). Starting from September 15th, API calls started to return rate exceeded errors at rather unexpected times. I have created this thread to gather observations on this matter.
More details:
- the API is invoked by a little piece of custom Python software which calls the
https://api.netatmo.com/api/homestatus
endpoint at regular intervals - the access token is requested by the same software (with human interaction to approve the request), and automatically refreshed as needed
- after some time since starting the Python software, I get the following error:
HTTP 429 Client Error: ConcurrencyLimitTimedOut
-
{
"error": {
"code": 11,
"message": "Failed to enter concurrency limited section"
}
} - the error has never occurred over years of running the same Python software, and no changes to its code have occurred since
- as a single user, I am invoking the API using the client_id of a single application
I am well aware of the rate limits documented in https://dev.netatmo.com/guideline:
Per application
+----------------------------+-----------------------------+
| Documented limit | Normalized max request rate |
+----------------------------+-----------------------------+
| 2 × users every 10 seconds | 1 every 5 seconds |
| 2000 every hour | 1 every 1.8 seconds |
+----------------------------+-----------------------------+
Per user
+----------------------------+-----------------------------+
| Documented limit | Normalized max request rate |
+----------------------------+-----------------------------+
| 50 every 10 seconds | 1 every 0.2 seconds |
| 500 every hour | 1 every 7.2 seconds |
+----------------------------+-----------------------------+
In fact, I have tried with several different knowingly safe request rates, yet still experiencing the same error. Here are the time windows of successful API invocations, until the first HTTP 429 error occurred (times in the UTC timezone):
+-----------------------------------+-------------------------------------+------------------------------+
| Request rate | Time window | Count of successful requests |
+-----------------------------------+-------------------------------------+------------------------------+
| 1 every 30 seconds (120 per hour) | 19/09/2025 06:35 - 19/09/2025 08:00 | 169 |
| 1 every 30 seconds (120 per hour) | 19/09/2025 21:19 - 20/09/2025 08:00 | 1295 |
| 1 every 30 seconds (120 per hour) | 21/09/2025 21:53 - 21/09/2025 23:33 | 199 |
| 1 every 60 seconds (60 per hour) | 22/09/2025 06:42 - 22/09/2025 13:21 | 397 |
| 1 every 120 seconds (30 per hour) | 23/09/2025 21:37 - 23/09/2025 23:38 | 61 |
| 1 every 240 seconds (15 per hour) | 25/09/2025 06:37 - 25/09/2025 19:26 | 193 |
| 1 every 300 seconds (12 per hour) | 28/09/2025 20:41 - 29/09/2025 00:46 | 50 |
+-----------------------------------+-------------------------------------+------------------------------+
Automatic refresh of the access token always occurred every 3 hours.
Observations:
- the count of successful requests before the first occurrence of the HTTP 429 error is variable and unpredictable
- the error occurs even with widely safe request rates (12 requests per hour)
- the Python software has worked perfectly for a long time at a rate of 240 requests per hour (i.e., one every 15 seconds)
I am aware of the change enforced in this post, incidentally dating back to one month ago, but, really, the experienced error occurrences do not match any of the documented rate limits.
Browsing the forum revealed the following related posts:
- API Rate Limit clarification request (this is where I have started my investigation from)
- Getting error 26 "User Usage exceeded " for a few hours now
- Rate limits and User limit
However, none of them seems to address the issue I am experiencing.
As a last resort, I have tried to create a fresh application, and tune the Python script to use that instead (i.e., no longer using the previous one). However, the final outcome is unchanged.
I am running out of ideas to justify this behavior: any help is welcome.
Comments
22 comments
Hello,
Thanks for this well explained feedback
This error comes from a part of a mechanism we introduced in the WAF to protect our backend when too many requests arrive at our servers on a global scale. The goal is to avoid degradation of the response times and/or shutdown of the service. In a nutshell it means "We have too many requests for now. Please retry later". It's not linked to your personal calls quota
So, it's normally not linked to a bad implementation of the API on your side. As it's a recent change, teams are monitoring this in order to see if we keep or adjust this mechanism
Have a good day,
Leslie - Community Manager
Thank you very much Leslie for your prompt clarification. I had been considering the chance of simply trying again when receiving the error, but I was afraid that this could cause further harm to the API call quota.
I have now improved my application to retry any API calls after a 30 seconds grace period in case an HTTP 429 error with application-level code 11 is received: it works perfectly even with the original 15 seconds polling rate (240 calls per hour), and such retries are indeed rarely needed.
As a side comment, while such temporary API failures are easily compensated in a status polling cycle, they might cause missed commands when a device is supposed to be controlled, especially when it is hard for the controlling application to notify the user about occurred errors (like it is in my case, since the application communicates using MQTT alone).
Thank you very much again.
Hi, I'm having the same issue and this is really frustrating because I'm supposed to control lights via API, and with this issue, sometimes they do not turn off or on......I'm not turning m'y lights on and off more than few times per hour, I have a lot of lights but I can't imagine reaching the API limit just bu thèse actions. Please fix this issue
@arno.delaunay, this is more or less in line with my last statement in this comment.
Maybe we should let Netatmo comment on this but, as far as I can understand, the Web Application Firewall they needed to introduce is there to shield from abuse of the API interface. Removing this protection might result in the API being unavailable anyway due to overload of the backend servers, regardless of any dynamic capacity scaling being enforced, and this cannot be considered a "fix". On the other hand, they said they are still adjusting the mechanism, which means that the probability of such WAF triggers occurring may vary over time.
That said, error handling is supposedly up to the client, which might notify them to the user (provided that the application has a user-side interface, which unfortunately is not my case) after possibly performing a few retries (with due care to avoid exceeding rate limits). As per the documentation, errors may occur when certain API flows are violated (example) or due to unpredictable server-side failures (example): after all, the new HTTP 429 error returned by the WAF can be easily considered a member of the latter class and should be handled as such.
Hi and thanks for your feedback. I see what you mean, and indeed, I'd rather have the API work most of time than never. Let's hope they can fine tune this a bit
This issue is extremely annoying. It effectively killed my smart home. Any simple automation, even turning on a single switch at 6am fails at a very high probability. Please fix this global WAF issue. It makes my Bticino switches very expensive stupid switches.
Trying to chime in (again) to share a quick thought: while this newly introduced behavior may sound a bit annoying, that is also the standard defense against a full denial of service, which would have a much more perceivable impact in the absence of any protection. Maybe the WAF trigger threshold will be tuned in the future, but regardless of this the following arguments apply:
This basically is Denial of Service from Netatmo. Keep it going and I’ll look for alternative provider. I understand your concerns but this is not the way. My TRV’s keep heating as they ignore the commands to shut off (by setting low temperature). This is unacceptable.
I am experiencing the same issue, with my shutters opening or closing randomly.
This situation is problematic and impacts daily use. It would be appreciated if Netatmo could ensure that its server infrastructure is properly sized so that customers are not affected by such issues. Considering the price of your products, we naturally expect a reliable and consistent service.
Ideally, providing more open or local control options that reduce dependency on external servers would be a valuable improvement and beneficial for users.
Given the current situation, I am also beginning to explore alternative solutions that may be available.
Sorry for my imperfect English.
Let me see if I understand. I have a thermostat that the manufacturer sold me as being controllable online, and now the manufacturer says it only works sometimes, and that my heating won't turn on when I need it, but only when the manufacturer decides...
I understand. This makes me very uneasy about Netatmo as a company.
Idem pour moi avant-hier et ce matin concernant une demande d’allumer un chauffe-eau à 6h00.
Voici l'erreur retournée : 429 - - Failed to enter concurrency limited section (11) when accessing 'https://api.netatmo.com/api/setstate'
Une correction a-t-elle été apportée ?
Merci
Not surprisingly, this behavior is affecting the experience of many users.
However, complaints seem to have a mixed origin: while the latest explicitly mentions API HTTP error 429, it is unclear whether the preceding ones (affecting valves, shutters, thermostats) concern failures of routines defined in the official Netatmo Home+Control app or of custom API-based integrations.
In my humble opinion, such issues would be better addressed if their origins were made clearer:
Unless differently stated, most of the issues reported here may seem related to the API interface, thus being handled by the Netatmo team in the anti-DDoS tuning campaign (i.e., not as real bugs to be fixed). Although this does not change the picture, I believe if "real" bugs (i.e., of Home+Control routines) are out there they should really be properly reported.
I agree with the complaints here. Selling more devices leads to a higher request rate per second. Your systems should scale horizontally to handle the incoming traffic. Trying to boost sales without a system that can actually support the demand isn't right for your users
When implementing a WAF you usually set a rate limit per user not a global rate limit. This make no sense...
Please fix your WAF, I should be able to turn on my heater when I want, not when YOU want.
I'm using Home Assistant and the Netatmo integration. Since months, I'm struggling with this HTTP 429 failure issue. I operate several CO2 sensors which should control the ventilation. The service is so unreliable. I tried also webhook - another nightmare which has cost me hours of trial and error.
At the end, I found another nice temperature / humidity sensor with integrated CO2 sensor. This one shares the date directly with HA. No unreliable cloud application. No fiddly setup. And the best: This solution works 100%.
Netatmo: I have loved your products but I start to replace them with other products.
Hello,
Seems like you are using Home Assistant Cloud
The Cloud part of HA is subject to per applications rate limits as they use a unique app for all users :
Application limits
Rate limit per application :
(2 * number of users in limit of 200) requests every 10 seconds
Quota per application depends on your number of users:
According to this discussion there is a workaround : https://github.com/home-assistant/core/issues/152449#issuecomment-3566898116
I invite you to test it
Please note that when using a "personal" integration (using your own application to authenticate : https://www.home-assistant.io/integrations/netatmo/), you are not subject to this common rate limit
Have a good day,
Leslie - Community Manager
Bonjour Leslie,
Pour ma part non, je n'utilise pas Home Assistant Cloud.
Bertrand
Hi Leslie,
I’m writing to inform you that none of us here are using the Cloud version. Instead, we are authenticating via OAuth through the official integration provided directly by you: https://www.home-assistant.io/integrations/netatmo/.
The funny (and sad) thing is that since this is an official integration, the rate at which requests are made to your WAT was decided by you. Furthermore, every request is authenticated and linked to a specific user profile via OAuth.
I strongly believe there are limits in place because we are all having the same experience: a 429 status code (too many requests).
@Bertrand, @Edoardo,
I see in the backoffice that you both use Home Assistant Cloud. I don't see any Netatmo developer app linked to your account (allowing to use Home Assistant with a self-hosted instance, according to the integration link you sent Edoardo : https://www.home-assistant.io/integrations/netatmo/#development--testing-with-your-own-client-id)
Also, the 429 errors generated for your accounts come from HA Cloud app (id : 5dee72048b23457bee213cce) and triggers the global quota per app policy
Netatmo only provides the open API (documentation here : https://dev.netatmo.com/apidocumentation/control). We are not linked to any 3rd party services and to their developments - including Home Assistant. We are not involved in this integration
The limits are linked to the fact that Home Assistant Cloud uses 1 common application for all their users. That's why they are limited by the per application limit and not the per user limit
Have a good day,
Leslie - Community Manager
I was still getting 429 even with dev netatmo account set in HA. So, bye bye Netatmo TRV’s after all these years, the alternative is already installed and working flawlessly.
Thanks for the information, @Leslie. I have just configured my application for personal use, and I hope this resolves the issue.
Could you please let us know what the specific rate limits are for applications set to personal use?
Per-application and per-user limits are both documented in the Rate limits section of this page: this is exactly where the values mentioned by Leslie come from.
Things should improve for you after switching to your own custom application (and you are of course encouraged to try), but HTTP error 429 is likely to stem from elsewhere: the beginning of this thread deals exactly with this mismatch (between staying within documented rate limits and still getting error 429).
Please sign in to leave a comment.