> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # SD-WAN Manager (vManage) API: Monitoring Catalyst SD-WAN Programmatically - URL: https://www.pinglabz.com/sd-wan-manager-api/ - Published: 2026-07-12T02:58:39.000Z - Updated: 2026-08-24T05:13:28.000Z - Description: SD-WAN Manager (vManage) exposes a REST API for the entire Catalyst SD-WAN fabric. This article walks the API's shape for network engineers: monitoring the fabric, pulling tunnel health, and automating policy changes. - Author: Jaime - Tags: Network Automation, SD-WAN, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/network-automation/) and the [SD-WAN cluster](https://www.pinglabz.com/sd-wan/). 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: Device inventory Every edge (WAN Edge), controller, and validator in the fabric, with status. Tunnel / BFD statistics The health of every overlay tunnel: loss, latency, jitter per path. The data SD-WAN uses to steer traffic. Policies Application-aware routing, data, and control policies. Read and, with care, modify them. Alarms / events Fabric-wide alarms and events, for feeding into your own monitoring. 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](https://www.pinglabz.com/sd-wan/)); 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:///j_security_check j_username=admin&j_password= (form-encoded) # 2. Fetch a CSRF token for subsequent write calls GET https:///dataservice/client/token -> # 3. Use the cookie (and token for writes) on API calls GET https:///dataservice/device Cookie: JSESSIONID=... X-XSRF-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](https://www.pinglabz.com/ip-sla-cisco-ios-xe/) 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](https://www.pinglabz.com/python-json-encor-exam/), or the [Network Automation cluster guide](https://www.pinglabz.com/network-automation/).