If Catalyst Center is the controller for the campus, SD-WAN Manager (formerly vManage) is the controller for the WAN. It orchestrates the entire Cisco Catalyst SD-WAN fabric, every edge router, every policy, every tunnel, and like every modern controller it exposes a REST API. Monitoring an SD-WAN fabric programmatically, pulling tunnel health, or automating policy changes all go through that API.
This article covers the SD-WAN Manager API for network engineers. It extends the Network Automation cluster guide and the SD-WAN cluster. As with Catalyst Center, the examples illustrate the API's shape rather than being lab captures, because the SD-WAN control stack cannot run in a standard CML environment; Cisco's DevNet sandboxes provide a live SD-WAN Manager to practice against.
What SD-WAN Manager Sees
SD-WAN Manager is the single pane of glass for a Catalyst SD-WAN fabric. Its API surfaces the things that make SD-WAN operationally different from traditional WAN:
The most valuable read for most engineers is the tunnel statistics. SD-WAN's whole premise is measuring path quality and steering applications accordingly (covered in the SD-WAN cluster); the API lets you pull those measurements into your own dashboards and alerting rather than living inside the SD-WAN Manager GUI.
Session-Based Authentication
SD-WAN Manager uses a slightly different auth model from Catalyst Center, worth noting because it trips people up. You POST credentials to a login endpoint and receive a session cookie, and (on current versions) you then fetch a CSRF token that must accompany write requests:
# 1. Log in, receive a JSESSIONID session cookie
POST https://<manager>/j_security_check
j_username=admin&j_password=<pass> (form-encoded)
# 2. Fetch a CSRF token for subsequent write calls
GET https://<manager>/dataservice/client/token
-> <csrf-token>
# 3. Use the cookie (and token for writes) on API calls
GET https://<manager>/dataservice/device
Cookie: JSESSIONID=...
X-XSRF-TOKEN: <csrf-token>The session-cookie-plus-CSRF pattern is more stateful than a bearer token; your client has to hold the cookie jar across calls. The key operational point is the same, though: authenticate once, reuse the session, and protect the credentials.
Reading Fabric State
The /dataservice/ path is the heart of the read API. Pulling the device list:
GET /dataservice/device
Cookie: JSESSIONID=...
-> 200 OK
{
"data": [
{
"host-name": "branch-edge-01",
"device-type": "vedge",
"system-ip": "10.255.0.11",
"reachability": "reachable",
"site-id": "101",
"version": "17.9.3a"
},
...
]
}And the tunnel statistics that make SD-WAN monitoring worthwhile, per device:
GET /dataservice/device/tunnel/statistics?deviceId=10.255.0.11
-> { "data": [ { "tunnel-protocol": "ipsec",
"dst-ip": "...", "loss": 0.2,
"latency": 14, "jitter": 3 }, ... ] }That loss/latency/jitter per tunnel is the same class of measurement as an IP SLA probe, but collected fabric-wide by the controller. Pulling it via the API lets you build alerting on WAN path quality that spans every site, which is exactly the kind of visibility SD-WAN promises and the API delivers.
Writing: Templates and Policies
The write side (pushing templates, changing policies) exists but demands respect. In Catalyst SD-WAN, configuration is driven by templates attached to devices, and changing a template can push config to many edges at once. An API-driven policy change is powerful and correspondingly dangerous: a mistake propagates fabric-wide. The disciplined approach is to read and validate extensively via the API, and gate writes behind change control and testing, treating an SD-WAN Manager write API the way you would treat configure replace on every router simultaneously.
FAQ
Can I lab SD-WAN Manager?
Not in a standard CML setup (the full control stack is heavy and licensed). Cisco's DevNet always-on sandboxes provide a live SD-WAN Manager with an API you can call. The examples here show the API's shape.
How is auth different from Catalyst Center?
SD-WAN Manager uses a session cookie (JSESSIONID) from a login POST, plus a CSRF token for writes, rather than a bearer token. Your client must hold the cookie across calls.
What is the most useful thing to read?
Tunnel statistics (loss, latency, jitter per path). That per-tunnel quality data is the core of SD-WAN's value and feeds real WAN monitoring.
Is it safe to change policy via the API?
It works, but a template or policy change can propagate to many edges at once. Treat write operations with the same caution as a fabric-wide config change: validate, gate behind change control, test first.
Is vManage the same as SD-WAN Manager?
Yes, renamed. The API path still contains /dataservice/. The blueprint uses the current name, SD-WAN Manager.
Key Takeaways
- SD-WAN Manager is the WAN controller; its REST API (
/dataservice/) exposes device inventory, tunnel statistics, policies, and alarms. - The highest-value read is per-tunnel loss/latency/jitter, the measurement SD-WAN steers on, pullable fabric-wide into your own tooling.
- Auth is session-cookie based (JSESSIONID from a login POST) plus a CSRF token for writes, more stateful than a bearer token.
- Writes are driven by templates and can propagate to many edges at once. Treat them like a fabric-wide config change: cautious, gated, tested.
- It cannot be labbed in standard CML; use DevNet always-on sandboxes.
Next: Python and JSON for the ENCOR exam, or the Network Automation cluster guide.
