Short Answer: There's No Single Call for This
Unfortunately, New Central doesn't currently expose a "max concurrent users" or "unique devices for a school year" metric as a direct report or single API call. Others in the community have run into the same wall - one engineer confirmed that the List Unified Clients endpoint ( /network-monitoring/v1alpha1/clients or its older /monitoring/v1/clients counterpart) only returns currently connected clients regardless of what you set the timerange parameter to, even when trying values like "1M". They also tried /monitoring/v1/clients/count , and that endpoint ignores the from_timestamp and to_timestamp query parameters entirely, even for date ranges less than a month back. So don't waste time expecting historical filtering to "just work" on those count/list endpoints - it doesn't, in my experience either.
You could build your own polling pipeline. Since Central won't aggregate this for you, the practical (and honestly, only reliable) approach is:
• Poll the clients endpoint on a schedule (I run mine every 5–15 minutes) and log a timestamped snapshot of the connected count.
• Paginate through the next cursor if you're above the 1000-record limit per call, so you don't undercount during peak hours.
• Store the timestamp + count (and MAC/client identifiers if you want unique-device tracking) in something simple like SQLite, InfluxDB, or even a flat CSV.
• For unique devices, track distinct MAC addresses seen across your snapshots rather than relying on any built-in dedup from Central, since the API returns whoever is connected at query time, not a rolling unique count.
This is essentially the same workaround pattern Aruba's own PyCentral team ships for connected-client statistics - their sample script pulls per-site client data across preset "last connected" windows (3h, 24h, 1 week, 1 month) and writes results out for later analysis, because there's no native long-range historical query. I adapted a similar script for our environment and it's been solid for building daily/weekly/term-long peak reports.
Timeframe and Rate Limits to Plan Around
A few practical constraints I've run into that will affect your design:
• API calls are capped at 10 requests per second per Central account, so batch your polling logic and don't hammer it across multiple sites simultaneously.
• The limit parameter on client-list endpoints tops out at 1000 records per call - larger campuses need pagination via the next cursor, not a single call.
• Since there's no server-side historical rollup, your "school year" max concurrent and unique-device counts are only as granular as your own polling interval and storage retention - plan disk/DB retention accordingly if you want a full academic year of data.
My Recommendation
Build a lightweight scheduled job (cron, Task Scheduler, or a small daemon) using PyCentral or plain REST calls against network-monitoring/v1alpha1/clients , log every poll to a time-series store, then run your own aggregation queries (MAX for concurrent peak, COUNT DISTINCT MAC for unique devices) over whatever window you need - day, week, term, or full year. It's more setup than a single API call, but it's the only way to get accurate historical peaks given the current API limitations, and once it's running it's basically maintenance-free.
Hope that saves you some of the trial-and-error I went through!
------------------------------
Dustin Burns
Lead Mobility Engineer @Worldcom Exchange, Inc.
ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------