Decreased rate limit on `/v3/device_tag` POST/PATCH

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.