# API rate limits for bulk device deployment status queries **URL:** \ **Category:** General Discussions\ **Tags:** api\ **Created:** [September 25, 2025, 7:21am UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014 "2025-09-25T07:21:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![stere-marius](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/stere-marius/32/2569_2.png) [@stere-marius](https://hub.mender.io/u/stere-marius)\ **Post date:** [September 25, 2025, 7:21am UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014/1 "2025-09-25T07:21:48Z")
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. ---
**Author:** ![seva.gribov](https://avatars.discourse-cdn.com/v4/letter/s/57b2e6/32.png) [@seva.gribov](https://hub.mender.io/u/seva.gribov)\ **Post date:** [November 21, 2025, 12:18pm UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014/2 "2025-11-21T12:18:47Z")
Any updates on that? ---
**Author:** ![stere-marius](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/stere-marius/32/2569_2.png) [@stere-marius](https://hub.mender.io/u/stere-marius)\ **Post date:** [January 13, 2026, 10:26am UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014/3 "2026-01-13T10:26:58Z")
Any update from mender development team? ---
**Author:** ![stere-marius](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/stere-marius/32/2569_2.png) [@stere-marius](https://hub.mender.io/u/stere-marius)\ **Post date:** [March 24, 2026, 9:43am UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014/4 "2026-03-24T09:43:39Z")
Any update? I can implement this by myself if it’s approved by the devs ---
**Author:** ![janaperic](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/janaperic/32/1608_2.png) [@janaperic](https://hub.mender.io/u/janaperic)\ **Post date:** [June 5, 2026, 10:22am UTC](https://hub.mender.io/t/api-rate-limits-for-bulk-device-deployment-status-queries/8014/5 "2026-06-05T10:22:08Z")
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