My educated guess is yes, use the first option. Indeed the Access Token expires, and the first one should go through the process or requesting access token with the provided credentials, use the renew token if the access token is expired, and add the tokens in the requests. Should make your life much easier. Please try.
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check
for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 06, 2026 09:06 AM
From: cauliflower
Subject: Classic Central API hitting rate limit
Thanks Herman,
That makes sense. I'm just a bit confused by the docs. I'm looking at:
It lists a few approaches. My assumption was that for Classic Central API the only approach that will work is the full OAuth cycle, so:
-
get X-CSRF token (login using username and password)
-
get auth token by using X-CSRF token
-
get access token by using auth token
-
refresh access token where necessary using refresh token
For this it says I can create a YAML file that looks like:
central_info: username: "<aruba-central-account-username>" password: "<aruba-central-account-password>" client_id: "<api-gateway-client-id>" client_secret: "<api-gateway-client-secret>" customer_id: "<aruba-central-customer-id>" base_url: "<api-gateway-domain-url>" token_store: type: "local" path: "temp" ssl_verify: true
But it also talks about the access token approach where you just provide the access token in a YAML file:
central_info: base_url: "<api-gateway-domain-url>" token: access_token: "<api-gateway-access-token>" ssl_verify: true
Obviously that method assumes an access token has been generated. My desired approach is that the scripts I write will generate/refresh access tokens for me as part of the script, so I was expecting something like the first version of central_info above.
So perhaps I need to play with the first of these versions. The docs then show two methods of making a call. One using pycentral base and one using pycentral modules. In both cases it only shows central_info as being the latter token method. So I guess the question I have is if I make a call with central_info defined with all the extra details (username, password, client_id.... etc) will it just do all the token shizzle under the hood for me when I make an API call?
I hope that makes sense
Guy
Original Message:
Sent: 5/6/2026 6:11:00 AM
From: Herman Robers
Subject: RE: Classic Central API hitting rate limit
I believe that exactly is the purpose of using an SDK, to take care of token request,refreshing, etc... all the standard/low level things that you don't want to worry about, so you can focus on functionality.
For migration of AOS8 to AOS10 (and New Central configuration) there is quite good guides available as Validated Solution Guide.
If you work for a partner, you can click on the 'VSG Content for HPE Partners' on the VSG page and get even more detail. And you can get access to the VALID8 tool that can analyze your current config, and help migrating it to AOS10 in New Central configuration. And I know that VALID8 is expanded every now and then to support new use cases.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 05, 2026 11:32 AM
From: cauliflower
Subject: Classic Central API hitting rate limit
Thanks Herman,
Do you know if Classic PyCentral offers any automation of token generation/refresh (ie management of tokens)? I've written a script now that will probably do the job of checking if a token is still valid and refreshing it if needed but it's not very pretty!
In general the jobs we are concerned about all relate to our migration from AOS 8, eg recreating the 300+ AP groups we have which I think currently can only be done via Classic Central. And things like pre-provisioning devices for when we start switching APs over to Central. I think we also need to configuire the AOS gateway firewall using API though I'm not sure if that is Classic Central or New Central.
I'm sure the list of things we need to do in bulk as part of the migration that would benefit from the API (Classic & New) will only grow.
Guy
Original Message:
Sent: May 04, 2026 08:06 AM
From: Herman Robers
Subject: Classic Central API hitting rate limit
There is pycentral for Classic Central; and pycentral v2 for New Central.
While I have not played with it, pycentral v2 is supposed to be API compatible, so if you create your scripts now in pycentral, you should be able to migrate quite fast to the new Central.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 01, 2026 04:26 AM
From: cauliflower
Subject: Classic Central API hitting rate limit
Hello,
I understand better now that the calls for the initial authentication to create a session, and then the call to obtain an auth code, are rate limited. So once I manage to get my access token I just need to keep refreshing that (at least once every 15 days I think?).
I did look at PyCentral, but I think that is for New Central only? Or have I got that wrong? I am trying to use the Classic Central API (we are actually on New Central but I believe there are certain API calls that can only be made to Classic that we will probably need to use when we start migrating to AOS 10).
Guy
Original Message:
Sent: Apr 29, 2026 02:36 PM
From: alagoutte
Subject: Classic Central API hitting rate limit
Hi Guy,
Do you have found your solution ? the code look...
do you have look pycentral (v1 ?) already make this stuff
------------------------------
PowerArubaSW : Powershell Module to use Aruba Switch API for Vlan, VlanPorts, LACP, LLDP...
PowerArubaCP: Powershell Module to use ClearPass API (create NAD, Guest...)
PowerArubaCL: Powershell Module to use Aruba Central
PowerArubaCX: Powershell Module to use ArubaCX API (get interface/vlan/ports info)..
ACEP / ACMX #107 / ACDX #1281
Original Message:
Sent: Apr 17, 2026 07:44 AM
From: cauliflower
Subject: Classic Central API hitting rate limit
Hello,
I'm sure this must be something I'm doing wrong, but I can't figure out what. I am trying to work out the authentication/authorization process to use the Classic Central API. If I use cURL it works fine as per the online instructions, so I am now trying to turn that into a Python script. But after very few attempts (like 2 or 3 it seems) at running the script I get a rate limit exceeded message. This is my script so far (with contributions from ChatGPT! Needs must!):
def get_auth_classic(cust_id,client_id,api_url,username,pwd): headers = { "Content-Type": "application/json" } payload = { "username": username, "password": pwd } params = { "client_id": client_id } url = "https://apigw-ukwest2.central.arubanetworks.com/oauth2/authorize/central/api/login" # Session object can deal with cookies (equivalent to cURL --cookie-jar) session = requests.Session() response = session.post( url, params=params, headers=headers, json=payload, allow_redirects=True # ? ) print(f"response = {response.text}") # Extract cookies cookies = session.cookies.get_dict() print("Cookies:", cookies) # Extract CSRF token csrf_token = cookies.get("csrftoken") # Extract session ID session_id = cookies.get("session") if not csrf_token: raise Exception("CSRF token not found in cookies") print("CSRF Token:", csrf_token) token_url = f"{api_url}/oauth2/authorize/central/api" params = { "client_id": client_id, "response_type": "code", "scope": "all" } data = { #"grant_type": "authorization_code", "customer_id": cust_id } headers = { "Content-Type": "application/json", "X-CSRF-Token": csrf_token } token_response = session.post( token_url, params=params, json=data, headers=headers, allow_redirects=False # ? ) print("\nToken status:", token_response.status_code) print("Token response:", token_response.text) return token_response
The first login part seems to work, I get back the csrf token and session ID, but as I say, when I tweak the script to try to get the second part to work (obtain the actual re-useable token) I'm constantly blocked by having hit the rate limit and having to wait for that to clear, so testing is taking a long time! I _think_ it's the login action which is hitting that limit.
Is there something I'm doing wrong here that is causing this? I couldn't find Python examples for the auth process online.
Guy
-------------------------------------------