A data-center team automates Catalyst Center inventory reports with Python requests. The script must authenticate over HTTPS, reuse the session token for inventory calls, and handle expiry without hardcoding passwords in code. Nightly runs fail with 401 after one hour. Which token authentication to Catalyst Center behavior should the script implement to sustain API access?
Select an answer to reveal the explanation.
Short Explanation
You can keep your nightly inventory run moving by requesting a session token over HTTPS and getting a fresh one when a call returns 401. Refreshing on demand helps you recover without putting passwords in your code.
Full Explanation
Catalyst Center’s token-authentication pattern is to POST credentials to the authentication endpoint over HTTPS, retain the returned session token, and include it in later inventory requests. When a request returns 401 because the token has expired, obtain a new token and retry the failed request. Keep credentials in a protected runtime source rather than embedding them in the script. Caching the token but aborting on 401 leaves the current run unable to recover; waiting for the next nightly run does not sustain access if the run outlasts the token. Using an OAuth refresh-token grant relies on a different authentication model: Catalyst Center’s flow uses a credential POST to obtain a session token, so you should not assume that OAuth refresh grants are supported. Renewing on a one-hour timer without retrying 401 responses also leaves a request failed if the token expires before the timer fires. Exam caveat: a 401 can also indicate invalid credentials or insufficient authorization, so bound renewal attempts rather than retrying indefinitely. Practical check: log token acquisition and renewal events without logging credentials or token values, then verify that a request succeeds after renewal and is retried.