A school district script fails against vManage because each request looks unauthenticated after the first call. Which practice correctly handles API authentication/session behavior?
Select an answer to reveal the explanation.
Short Explanation
vManage is a nightclub with a wristband: you check in once, wear the token/session on every request, and check out when done. Showing up bare-armed after the first song gets you bounced—and sticking enable secrets in headers is worse.
Full Explanation
School-district scripts that appear unauthenticated against vManage after the first call usually failed to handle session/token lifecycle. The correct practice is to obtain a session/token via the authenticated login API and send that token (or session cookie) on subsequent requests until logout or expiry. Controllers expect explicit session continuity, not anonymous follow-on GETs.
Embedding an enable secret from a random vEdge in every HTTP header is not vManage API auth. Disabling HTTPS and putting credentials in cleartext query strings is insecure. Skipping login and trusting source IP alone because the NOC VLAN is trusted ignores how the API is designed and audited.
Exam caveat: handle 401 by re-login/refresh rather than dumping credentials on every request in clear logs. Operational check: script login, store token, call a monitoring GET with the token, confirm success, then logout or allow expiry cleanly. Rotate district service accounts independently of human admins. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that counters, logs, and failover behavior still match the documented design intent.