A Cisco SD-WAN API login appears to work, but the next request returns 403 Forbidden. Copying a token into another script may not fix it because the request also depends on the correct session, role and API endpoint.
Lab status: This is a proposed exercise, not a completed device test or client case study. Code examples require validation against your image and dependency versions. Controller/fabric platform access is not confirmed; offline samples demonstrate report logic only. My documented background is NOC/data center operations, multi-vendor Netmiko workflows and Python/Flask integration.
Offline example checks: October 20, 2026: the added helper/demo block executed with local fixtures, and related negative cases were checked offline. No live device, controller, fabric or service behavior was validated.
Which version, role and endpoint checks come before code changes?
Identify the SD-WAN Manager release and use its authentication documentation. Cisco’s documented session flow uses authentication cookies and an X-XSRF-TOKEN for applicable requests. A successful HTTP exchange alone is not sufficient: a client may receive login-page content instead of the JSON resource it expected.
Use the installed release’s authentication flow and API role. The example below is scoped to the documented SD-WAN Manager 20.16 session flow. SSO or another authentication policy may need a different supported integration; do not automate browser-token copying as a service design.
Why can a valid login be followed by a 403 response?
A cookie and XSRF token must belong to the same session. A 200 HTML login page is not a successful API login; an invalidated session may redirect. A valid pair can still receive 403 because the role cannot perform the operation. Preserve that distinction rather than reauthenticating on every denial.
Proposed controller lab: keep session testing within scope
Offline tests should emulate empty successful login body, returned cookie, token retrieval, HTML rejection and missing cookie. Live authentication needs authorized Manager access beyond the confirmed virtual-router lab. Credentials and tokens must not enter fixtures, source control or ordinary logs.
Python: inspect session headers without exposing tokens
The new function performs session creation and token retrieval when explicitly called with an approved requests.Session. Set session.verify to a trusted CA bundle, use a prompt/secret manager for credentials, and restrict the origin to the approved Manager inventory. It does not make a configuration change or print token values. A caller must close the session and use the release-documented logout operation after work.
import requests
with requests.Session() as session:
session.cookies.set("JSESSIONID", "synthetic-session")
session.headers["X-XSRF-TOKEN"] = "synthetic-token"
request = requests.Request("GET", "https://manager.example.test/dataservice/device")
prepared = session.prepare_request(request)
print({
"has_cookie": "Cookie" in prepared.headers,
"has_xsrf": "X-XSRF-TOKEN" in prepared.headers,
})
Worked Python example and input contract
def sdwan_login(session, origin, username, password):
# Review against the documented 20.16 session-authentication flow.
if not origin.startswith('https://'):
raise ValueError('https_required')
session.headers.pop('X-XSRF-TOKEN', None)
session.cookies.clear()
login = session.post(origin.rstrip('/')+'/j_security_check',
data={'j_username': username, 'j_password': password},
timeout=(5,15), allow_redirects=False)
if login.status_code != 200 or login.text.strip() or not session.cookies.get('JSESSIONID'):
raise RuntimeError('login_not_accepted')
token = session.get(origin.rstrip('/')+'/dataservice/client/token',
timeout=(5,15), allow_redirects=False)
value = token.text.strip()
if token.status_code != 200 or not value or '<' in value or any(c.isspace() for c in value):
raise RuntimeError('token_not_accepted')
session.headers['X-XSRF-TOKEN'] = value
return session # Same Session retains the cookie; never print it or the token.
# Explicit live call only after configuring the approved Session CA policy:
# sdwan_login(session, approved_origin, username, password)
# Use the returned same Session; do not print cookies or token headers.
How should a client recover from an expired session?
On confirmed expiry, recreate the cookie/token pair once and retry only a safe read. Do not replay an uncertain POST automatically. On 403 with a still-valid session, check role and endpoint policy. Stop after bounded recovery and preserve an unresolved job rather than repeatedly consuming controller sessions.
Which connectivity problems can resemble API failures?
Distinguish TCP/TLS failure, proxy redirect, HTML response and JSON authorization error. Compare the same source and Manager hostname. A device-side data-plane problem does not explain a server-issued HTTP denial by itself.
What should a session-aware integration deliver?
Scope a service around safe session lifecycle, inventory-backed reads and a permission-aware error report. Add role tests and live session cleanup to acceptance before calling the integration deployable. No tested customer or controller authentication is claimed by the offline checks.
Related troubleshooting and implementation
Explore the network automation troubleshooting collection to connect this issue to adjacent workflows. The Netmiko, NETCONF and RESTCONF comparison helps when you are choosing an interface rather than fixing an existing implementation.