A Python service lists managed devices in Catalyst Center every ten minutes using one shared controller account. The engineer wants the API session to reuse a single issued token instead of attaching credentials to every call, and the service must survive the token aging out. How should the service obtain and attach the Catalyst Center token?
Select an answer to reveal the explanation.
Short Explanation
Catalyst Center hands you a token after one Basic-auth call, and every later request just carries that token in a header. Re-sending the password on every call works elsewhere, but this API won't take it on management endpoints. When it ages out, you simply ask for a new token and carry on as before.
Full Explanation
Catalyst Center (formerly DNA Center) issues a short-lived token when you call its authentication endpoint with an Authorization Basic header built from the controller credentials, and the response carries that value in a Token field. Every management request must then present it in an X-Auth-Token header, and because the token expires, the service has to request a fresh one instead of failing its device inventory. Sending username and password on every call fails the token-reuse requirement outright, because each management request is expected to carry an issued token rather than the account password. Reusing a login cookie fails because the REST API authenticates with the token header rather than browser-style sessions, so the cookie is ignored and the calls come back unauthorized. Presenting the token as an Authorization Bearer header fails on the header name alone, since the platform expects X-Auth-Token and does not read the bearer scheme. Exam caveat: the token endpoint path carries an API version, so treat the header name as the stable part of the contract. Practical check: open your browser's developer tools on the Catalyst Center dashboard and copy the request headers the console itself sends.