A network team is writing a Python service that polls SD-WAN Manager for tunnel statistics every five minutes and also posts a small configuration change on each run. The tool must authenticate once and carry that identity through both the reads and the writes. Which authentication flow matches how the Manager API issues and reuses sessions?

The Manager API’s session flow begins with a login request carrying credentials as form data. The response establishes a session identified by a cookie, which you resend on later calls to preserve the authenticated identity across polling and configuration changes. A configuration write also requires the CSRF token, so the correct flow uses both the session cookie and that token. Logging in with form-encoded credentials and reusing the cookie but omitting the CSRF token establishes the session, yet the write may fail or be rejected because an authenticated cookie alone does not meet the write requirement. Sending credentials as JSON and then using a cookie and CSRF token has the right session-and-write pattern, but the login endpoint expects form-encoded credentials, so JSON may not establish the required session. Obtaining an OAuth access token and using it as a bearer token describes a common OAuth pattern, but that token is not the Manager-issued session cookie and does not match this API’s session flow; adding a CSRF header does not make it equivalent. Exam caveat: endpoint behavior can vary across Manager releases, so verify the documented login path and token handling for your deployed version rather than assuming another Cisco API’s conventions apply. Practical check: inspect a successful login response, confirm that a subsequent read sends its session cookie and that a write sends the required CSRF token, then test both with the service’s actual credentials.