An unattended civic script retrieves Intersight inventory every night. Which authentication approach matches the classic Intersight API-key scheme candidates should recognize?
Select an answer to reveal the explanation.
Short Explanation
Intersight’s classic key is a signing pen, not a sticky note Bearer. Each call is digested and signed with the API key id and private key—copy-pasting an unsigned token is the wrong mental model.
Full Explanation
Unattended civic scripts that hit Intersight nightly should use the classic API-key request-signing scheme: each HTTP request is signed with an API key id plus private key, including a digest over the body and Date (and related signing inputs) in the signed Authorization material. That model proves possession of the private key per request rather than presenting a static opaque Bearer string copied once into a header.
Pasting a static Webex-style Bearer string with no request signature fails the Intersight key model—unsigned copy-paste tokens are the wrong mental model for this classic scheme. Completing a browser three-legged OAuth authorization-code grant for each nightly run fails unattended operation: interactive consent is not how headless inventory cron jobs authenticate. Sending X-Cisco-Meraki-API-Key to intersight.com fails cross-platform credential reuse; Meraki headers do not authorize Intersight.
Exam caveat: signature base strings are sensitive to exact header/date/body bytes—clock skew and altered JSON whitespace are common causes of 401 after “the key works in the UI.”
Operational check: use an SDK or known-good signer to GET a lightweight class, confirm 200, then run the same call from your nightly script host and compare Authorization signing inputs (API key id, Date, body digest) when debugging failures.