A civic Python script will retrieve wireless health from Cisco DNA Center. How does authentication work on the constructed hops?
Select an answer to reveal the explanation.
Short Explanation
DNA Center hands out a hall pass: POST auth/token, then show X-Auth-Token on every later Intent GET—Meraki and Webex badges do not open that door.
Full Explanation
Cisco DNA Center constructed authentication for Intent APIs starts with POST /dna/system/api/v1/auth/token using basic credentials; the response token is then sent as X-Auth-Token on subsequent GETs such as client-health. That two-hop pattern is what a civic wireless-health script must implement before any assurance retrieve succeeds.
Sending a Meraki X-Cisco-Meraki-API-Key on DNA Center Intent GETs fails because Meraki’s API-key header authenticates Meraki Dashboard, not DNA Center. Attaching a Webex bot Bearer token to the DNA Center host fails by product mismatch—Webex tokens do not mint DNA Center Intent sessions. Treating browser OAuth2 authorization-code as the only DNA login path fails the constructed automation model: scripts use the token POST with basic credentials (and X-Auth-Token thereafter), not an interactive redirect dance as the sole exam answer.
Exam caveat: tokens expire; a long municipal batch that caches one token without refresh will eventually 401 on client-health even though the first calls succeeded.
Operational check: POST auth/token, store X-Auth-Token, call a simple Intent GET, and on 401 re-authenticate once before failing the job so overnight wireless-health collectors recover cleanly across token lifetimes.