API rate limits for bulk device deployment status queries

General Discussions
1

I need to retrieve deployment status for a large list of devices using the Mender API. Currently, I’m making individual calls to /api/management/v1/deployments/deployments/devices/{id} for each device, but I’m hitting the rate limiter and receiving 429 Too Many Requests errors.

Current approach limitations:

  • No bulk endpoint available for querying multiple device deployment statuses simultaneously

  • Individual API calls don’t scale well for large device lists

  • Rate limiting blocks progress without clear guidance on limits

I implemented a retry strategy that makes requests until hitting the rate limit, then waits before resuming. However, I need to understand:

  1. What are the specific rate limits for the hosted Mender v4.0.0 API?

  2. Is this information documented anywhere?

  3. Are there any recommended patterns or alternative approaches for bulk deployment status queries?

Environment: Hosted Mender v4.0.0 (Open Mender)

Any guidance on rate limits or suggestions for more efficient approaches would be greatly appreciated.

2

Any updates on that?

3

Any update from mender development team?

4

Any update? I can implement this by myself if it’s approved by the devs

5

Hi @stere-marius,

First off, my apologies — this thread sat unanswered for far too long, and that’s on us. Thank you for your patience (and for the nudges along the way). Let me give you a proper answer now.

The core of what you’re hitting is that GET /api/management/v1/deployments/deployments/devices/{id} is a per-device lookup, so across a large fleet you end up firing one request per device — which is exactly what runs into the rate limiter (429). The reassuring part is that you don’t need a new bulk endpoint at all; the deployments API already lets you query by deployment rather than by device:

  • GET /api/management/v1/deployments/deployments/{deployment_id}/statistics — gives you the aggregate status counts for the whole deployment (success, failure, pending, downloading, installing, rebooting, noartifact, already-installed, aborted, pause_before_*) in a single, lightweight call.
  • GET /api/management/v1/deployments/deployments/{deployment_id}/devices/list — gives you every device in the deployment with its individual status, paginated via page / per_page (up to 500 per page). You can also narrow it down with ?status=failure to pull just the devices you care about.

So the pattern I’d recommend is to iterate over your deployments and pull statuses in bulk per deployment, instead of iterating over devices and querying each one. I tested this against a live hosted tenant to be sure: a 20-device deployment returned the full per-device status breakdown in just 1 statistics call + 1 paginated devices/list call, rather than 20 separate requests — and it scales the same way for bigger deployments (a 500-device deployment is 1 statistics call + 1 list call at per_page=500).

If you ever do need status for an arbitrary set of devices that aren’t part of a single deployment, then the practical advice is: batch your queries, paginate with a large per_page, and on a 429 honour the Retry-After header with an exponential backoff before retrying. Polling on a sensible interval rather than in a tight loop also makes a real difference.

On the exact rate-limit numbers — these aren’t published as fixed public values and can vary by plan and configuration, so the most robust approach is to handle 429/Retry-After gracefully rather than coding against a hard threshold.

Sorry again for the wait.
Jana