Has the rate limit on /v3/device_tag POST/PATCH requests been dropped recently? We have a script which executes on startup to set tags for properties such as the device serial number and LTE modem identifiers for later use, this previously worked fine, but recently I’m seeing a “Too many requests” response after the first 3 pieces of metadata are reported.
I thought that maybe this was just to discourage repeatedly updating the same values, but despite having updated the script to only do an update if the value has changed I’m still seeing this behaviour. Adding a sleep 60 before making calls to these endpoints results in successful updates, but this does mean it takes a full five minutes to get data from a freshly booted device, which is clearly not ideal.
Devices in question are using their own device key for updates as provided by the Balena Supervisor when io.balena.features.balena-api is active for the container.
Hi,
We have recently indeed introduced a new ratelimiting mechanism for requests originating from device api keys,
Can you clarify how many tags are you setting and how often? Is it just on boot?
Can you also clarify whether you are making the API calls directly or whether you are using our node or python SDK?
In case you are using the python balena-sdk I would recommend updating to the latest version, since we have reduced the number of requests that it does when setting tags.
With regards to your new approach of updating only tags what you can tell are changed, this is indeed the suggested approach.
More specifically fetching all the device tags of the given device that you plan to set in one request and then setting the ones that are missing or different.
Kind regards,
Thodoris
Yup, we’re setting tags when the device boots, and are taking the approach you’ve suggested of pulling down all tags and only updating ones that need it, we’re just using a fairly dumb wrapper around curl for this. No issues since, just wanted to flag this really.