Cisco CCNA Automation course – 035 – Describe the capabilities of Cisco network management platforms and APIs (Cisco Catalyst SD-WAN)
Watch Full Demo on YouTube:
Introduction
In this post, we are going to continue with Chapter 3.0 of the CCNA Automation / DevNet Associate course, which focuses on Cisco platforms and development. This time, we are looking at Cisco Catalyst SD-WAN and the capabilities it provides from a network management and API point of view.
When you first hear the term SD-WAN, it can sound like a completely separate networking world. However, the main idea is actually very simple. Traditional WAN networks are usually built and managed device by device. Each branch router may need routing configuration, VPN configuration, security rules, QoS, and troubleshooting commands applied locally or through separate tools. That approach can work, but as the number of sites grows, it becomes harder to manage, harder to troubleshoot, and harder to keep consistent.
Cisco Catalyst SD-WAN solves this problem by giving you a centralised way to build, manage, monitor, secure, and automate the WAN. Instead of treating every branch router as an isolated device, Catalyst SD-WAN treats the WAN as a fabric. You manage the fabric from Cisco Catalyst SD-WAN Manager, and the platform takes care of pushing configuration, applying policy, monitoring device health, collecting operational data, and exposing APIs that you can use for automation.
From a CCNA Automation point of view, the most important thing to understand is not every deep SD-WAN design detail. The main goal is to understand what the platform does, why it exists, how it is managed, and how you can interact with it using REST APIs. This is very similar to the way we looked at other Cisco platforms such as Meraki, Catalyst Center, and ACI. Each platform provides a dashboard, but more importantly for automation, each platform exposes APIs that allow external scripts, tools, and systems to interact with the network programmatically.
By the end of this post, you should understand what Cisco Catalyst SD-WAN is, what problems it solves, what the main components are, what capabilities Cisco Catalyst SD-WAN Manager provides, and how to use Python to retrieve a list of devices from the Catalyst SD-WAN Manager API.
What Is Cisco Catalyst SD-WAN?
Cisco Catalyst SD-WAN is Cisco’s software-defined WAN solution. It allows organisations to build a secure WAN overlay across different types of transport networks such as MPLS, broadband internet, 4G, 5G, and other WAN circuits.
The important word here is overlay. In traditional WAN designs, the physical or service-provider network underneath often has a major impact on how the WAN is designed. With SD-WAN, the underlay still exists, but the SD-WAN overlay sits on top of it and provides the logical WAN fabric.
The underlay is the real transport network. This could be MPLS, broadband, LTE, or another WAN service. The overlay is the logical SD-WAN fabric that connects sites together securely over those transports. This means the business can use different WAN links from different providers while still managing the WAN centrally.
Cisco Catalyst SD-WAN gives you centralised control, centralised policy, secure encrypted tunnels, application-aware routing, segmentation, monitoring, troubleshooting tools, and automation through APIs. Instead of manually configuring every WAN router one by one, you use the SD-WAN platform to define how the WAN should behave, and the platform helps apply that intent across the fabric.
Why Do We Need SD-WAN?
To understand why SD-WAN is important, it helps to think about how WAN networks have changed.
In the past, many organisations had most of their applications hosted in a central data centre. Branches connected back to the data centre using private WAN circuits such as MPLS. Internet access was often centralised as well, meaning branch traffic would go back to the data centre before going out to the internet.
That model is not always ideal today. Many applications are now hosted in public cloud platforms, SaaS services, and distributed environments. Users in branch offices may need direct access to Microsoft 365, Salesforce, cloud-hosted applications, video conferencing, voice services, or other internet-based platforms.
If all of that traffic has to go back to the data centre first, the result can be poor performance, higher cost, and inefficient routing. At the same time, businesses still need security, visibility, consistency, and control.
This is where SD-WAN becomes useful. SD-WAN allows the network to make smarter decisions about which path traffic should take. For example, business-critical traffic can use the best-performing path, voice traffic can avoid links with high loss or jitter, and internet/SaaS traffic can exit locally from a branch when appropriate.
The key point is that SD-WAN is not just about connecting sites. It is about centralised WAN control, secure connectivity, policy-based forwarding, better application experience, and operational simplicity.
Traditional WAN vs Cisco Catalyst SD-WAN
In a traditional WAN, you usually configure routers individually. You may use CLI, templates, scripts, or network management tools, but the WAN logic often still lives across many devices. Routing, VPNs, access control, QoS, and troubleshooting can become complex as the number of sites increases.
In Cisco Catalyst SD-WAN, you manage the WAN from a central platform. You define templates, policies, security settings, and application-aware routing rules from Cisco Catalyst SD-WAN Manager. The SD-WAN controllers and edge devices then work together to build and maintain the overlay network.
A traditional WAN normally depends heavily on static designs and service-provider circuits. Cisco Catalyst SD-WAN is transport independent, meaning it can use different types of WAN transport links. This gives organisations more flexibility when connecting branches, data centres, cloud environments, and remote sites.
Another major difference is visibility. In many traditional WAN environments, troubleshooting requires logging into multiple routers, checking routing tables, verifying tunnels, looking at interface statistics, and collecting logs from different places. In Catalyst SD-WAN, the management platform gives you central visibility into the fabric, device health, tunnel status, control connections, application performance, and operational statistics.
For automation, this is very important. When the platform has central visibility and exposes that data through APIs, you can write scripts that retrieve inventory, monitor health, check status, generate reports, integrate with other tools, or even trigger automated workflows.
Main Cisco Catalyst SD-WAN Components
Cisco Catalyst SD-WAN is made up of several main components. Older documentation and many labs still use the original Viptela-based names such as vManage, vSmart, vBond, and vEdge. Current Cisco terminology uses names such as Cisco Catalyst SD-WAN Manager, Cisco Catalyst SD-WAN Controller, Cisco Catalyst SD-WAN Validator, and SD-WAN edge devices.
You should understand both naming styles because you may see both in Cisco documentation, DevNet labs, older books, API examples, and real customer environments.
Cisco Catalyst SD-WAN Manager
Cisco Catalyst SD-WAN Manager, previously known as vManage, is the central management platform for the SD-WAN fabric.
This is the component you interact with when you use the web dashboard. It is also the component you interact with when you use the REST API. From SD-WAN Manager, you can onboard devices, create templates, configure policies, monitor the fabric, troubleshoot issues, view alarms, check device status, and retrieve operational data.
For CCNA Automation, this is the most important component from an API perspective. Your Python script does not normally connect to every WAN edge router individually. Instead, your script connects to Cisco Catalyst SD-WAN Manager and asks the platform for information.
For example, if you want to retrieve a list of devices in the SD-WAN fabric, you can send a GET request to the SD-WAN Manager API endpoint:
/dataservice/device
Cisco Catalyst SD-WAN Manager then returns device inventory information in JSON format.
Cisco Catalyst SD-WAN Controller
Cisco Catalyst SD-WAN Controller, previously known as vSmart, provides the centralised control plane for the SD-WAN overlay.
In a traditional network, routers usually exchange routing information directly with each other. In Catalyst SD-WAN, the controller plays a major role in distributing routing and policy information across the fabric. It uses Overlay Management Protocol, or OMP, to exchange control-plane information.
OMP is often compared to BGP because it distributes routing information, reachability information, and policy-related information. The controller learns routes and policies and then helps distribute the correct information to the correct edge devices.
The important thing to remember is that the controller is not normally forwarding user data traffic. It is part of the control plane. It helps the fabric understand how traffic should move, but the actual user traffic is forwarded by the edge devices.
Cisco Catalyst SD-WAN Validator
Cisco Catalyst SD-WAN Validator, previously known as vBond, is responsible for orchestration and initial connectivity.
When SD-WAN edge devices join the fabric, they need to discover and connect to the correct controllers and management components. The validator helps with this initial onboarding process. It authenticates devices, helps them discover the correct control components, and assists with NAT traversal when devices are behind NAT.
This is why the validator is very important during fabric bring-up. It helps new devices safely and correctly join the SD-WAN overlay.
Cisco SD-WAN Edge Devices
The SD-WAN edge devices are the routers located at branches, campuses, data centres, cloud edges, or other sites. These devices form the data plane of the SD-WAN fabric.
They establish secure tunnels across the available transport networks and forward traffic between sites. They also apply policy, participate in the SD-WAN overlay, and provide local connectivity to users, servers, applications, and services.
In older documentation, you may see the term vEdge. In modern Cisco environments, you may also see Cisco IOS XE Catalyst SD-WAN routers, Catalyst 8000 platforms, virtual edge devices, and other supported WAN edge platforms.
The simple way to remember it is this:
Cisco Catalyst SD-WAN Manager manages the fabric.
Cisco Catalyst SD-WAN Controller controls the overlay routing and policy.
Cisco Catalyst SD-WAN Validator helps devices join the fabric.
SD-WAN edge devices forward the actual user traffic.
The Role of Cisco Catalyst SD-WAN Manager
Cisco Catalyst SD-WAN Manager is the main platform we care about in this post because it provides both the graphical interface and the API interface.
From the GUI, you can manage and monitor the SD-WAN fabric visually. From the API, you can do many of the same things programmatically.
The platform provides capabilities in several areas.
Centralised Management
Instead of logging in to every WAN router manually, you manage the SD-WAN fabric centrally. This includes device onboarding, templates, configuration, software maintenance, certificates, policies, monitoring, troubleshooting, and reporting.
This centralised model helps reduce configuration drift. If every router is configured manually, it is easy for one device to be slightly different from another. With templates and central policy, you can create a more consistent WAN design.
Device Inventory
Cisco Catalyst SD-WAN Manager keeps inventory information about the devices in the fabric. This includes details such as hostname, device ID, system IP, device type, platform, version, site ID, reachability, status, certificate state, and other operational values.
This is useful because inventory is one of the first things you normally automate. Before you can automate configuration, compliance, monitoring, or reporting, you need to know what devices exist and what state they are in.
For example, a Python script can call the API and retrieve all devices from the fabric. You can then use that data to create a report, check reachability, compare software versions, or feed another system.
Configuration Templates
One of the major capabilities of Catalyst SD-WAN Manager is template-based configuration.
Templates allow you to define reusable configuration building blocks. Instead of manually configuring every interface, VPN, routing setting, or system parameter on every device, you use templates to apply consistent configuration across multiple devices.
This is important in large environments because branches often share similar design patterns. For example, many branches may have similar WAN links, LAN interfaces, routing settings, security requirements, or application policies. Templates allow you to standardise those configurations while still allowing device-specific values where needed.
From an automation point of view, templates are powerful because they allow you to separate intent from device-level configuration. You define the desired design centrally, and the platform helps apply it to the correct devices.
Policy Management
Cisco Catalyst SD-WAN allows you to define centralised policies that control how traffic moves across the WAN.
This can include routing policy, data policy, application-aware routing policy, segmentation policy, security policy, and traffic engineering decisions. For example, you may want voice traffic to use the path with the lowest latency and jitter, while bulk backup traffic uses a cheaper broadband link.
The power of SD-WAN is that policies can be applied centrally rather than manually configured on every router. This makes the WAN easier to manage and easier to change.
Monitoring and Visibility
Cisco Catalyst SD-WAN Manager provides visibility into the state of the overlay network. You can monitor devices, tunnels, control connections, interfaces, application performance, alarms, events, and statistics.
This is valuable for operations teams because it gives them a central place to understand the health of the WAN. Instead of checking many routers individually, they can use the dashboard or API to retrieve operational information from the platform.
For automation, monitoring APIs are extremely useful. You can use them to build reports, integrate with monitoring platforms, check device reachability, or create scripts that alert when something changes.
Troubleshooting Tools
Catalyst SD-WAN Manager also provides troubleshooting capabilities. Troubleshooting in SD-WAN can involve checking device status, control connections, tunnel state, routing information, policy behaviour, software versions, alarms, and performance statistics.
The API makes this even more powerful because troubleshooting data can be collected automatically. For example, instead of asking an engineer to manually log in and gather information, a script can retrieve the relevant API data and present it in a readable format.
This is one of the reasons APIs are so important in network operations. APIs allow you to move from manual troubleshooting to repeatable troubleshooting workflows.
Cisco Catalyst SD-WAN APIs
Cisco Catalyst SD-WAN Manager exposes a REST API. This means external tools and scripts can interact with the SD-WAN platform using standard HTTP methods such as GET, POST, PUT, and DELETE.
For CCNA Automation, you do not need to memorise every endpoint. What matters is understanding how the API fits into the platform and what kinds of tasks it can support.
The API can be used for areas such as:
- Administration
- Certificate management
- Configuration
- Device inventory
- Monitoring
- Real-time monitoring
- Troubleshooting
- Software maintenance
- Policy workflows
- Integration with third-party tools
The API is useful because it allows you to automate tasks that would otherwise be performed manually in the GUI. For example, you can retrieve device inventory, check device health, view templates, monitor statistics, collect troubleshooting data, or integrate SD-WAN information with another system.
A very common API endpoint for learning and demonstrations is:
GET /dataservice/device
This endpoint retrieves devices from the SD-WAN fabric. It is a great example because it uses a simple GET request, does not modify the network, and returns useful JSON data.
API Documentation
Cisco Catalyst SD-WAN Manager includes API documentation that can be accessed from the platform. In many environments, the API documentation is available from a URL similar to:
https://<sdwan-manager-ip-or-hostname>:8443/apidocs
This documentation is based on OpenAPI-style documentation and allows you to explore available API resources, request methods, parameters, and response models.
This is very important when learning network automation. You should not guess API endpoints. You should always check the documentation, understand the method, understand the required authentication, check the required headers, review the request body if one is needed, and study the response structure.
This is exactly the process we follow throughout the CCNA Automation course:
First, we identify what we want to do.
Next, we find the correct API endpoint in the documentation.
Then, we check the authentication requirements.
After that, we send the request using a tool such as Postman, curl, or Python.
Finally, we read the JSON response and extract the data we need.
Authentication Options
Before you can use the Cisco Catalyst SD-WAN Manager API, you need to authenticate.
There are two authentication concepts you are likely to see.
Session-Based Authentication
Traditional Cisco SD-WAN API examples use session-based authentication. In this method, the script sends a username and password to:
/j_security_check
The request uses form-encoded data with the fields:
j_username
j_password
If authentication is successful, SD-WAN Manager returns a session cookie called JSESSIONID. The script then uses that session cookie in later API requests.
For GET requests, the session cookie is usually enough. For POST, PUT, and DELETE operations, newer releases may also require an XSRF token. The XSRF token can be retrieved from:
/dataservice/client/token
Even though our example in this post only performs a GET request, the script will still try to retrieve the token so you can understand the complete workflow.
JWT-Based Authentication
Newer Cisco Catalyst SD-WAN Manager releases support JWT-based authentication. JWT stands for JSON Web Token. With this method, an API token can be used as a bearer token in the HTTP Authorization header.
The idea is that instead of relying only on a session cookie, an external application can use a token that represents the user’s role and permissions. This is useful for automation tools and integrations because the API token can be used by an external system to authenticate and access the API.
For this post, we will use session-based authentication because it is still widely seen in Cisco SD-WAN labs, examples, and backward-compatible API workflows. It is also a useful method to understand for the exam because many SD-WAN API examples still show the JSESSIONID workflow.
Python Example: Retrieve a List of Devices from Cisco Catalyst SD-WAN Manager
In this example, we will create a Python script that connects to Cisco Catalyst SD-WAN Manager, authenticates using session-based authentication, retrieves the list of devices, and prints useful information about each device.
The script uses the Python requests library.
Before running the script, install the required library:
pip install requests
For security, the script reads the username and password from environment variables. This is better than hardcoding credentials directly inside the script.
On Windows PowerShell, you can set the variables like this:
$env:SDWAN_MANAGER="https://sandbox-sdwan-manager.example.com"
$env:SDWAN_USERNAME="your-username"
$env:SDWAN_PASSWORD="your-password"
On Linux or macOS, you can set them like this:
export SDWAN_MANAGER="https://sandbox-sdwan-manager.example.com"
export SDWAN_USERNAME="your-username"
export SDWAN_PASSWORD="your-password"
Now create a Python file called:
get_sdwan_devices.py
Add the following code:
import os
import sys
import requests
from requests.exceptions import RequestException
import urllib3
# Disable warnings only for lab environments that use self-signed certificates.
# In production, you should use a trusted certificate and keep SSL verification enabled.
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
SDWAN_MANAGER = os.getenv("SDWAN_MANAGER")
SDWAN_USERNAME = os.getenv("SDWAN_USERNAME")
SDWAN_PASSWORD = os.getenv("SDWAN_PASSWORD")
def validate_environment_variables():
"""
Make sure the required environment variables exist before running the script.
"""
missing_variables = []
if not SDWAN_MANAGER:
missing_variables.append("SDWAN_MANAGER")
if not SDWAN_USERNAME:
missing_variables.append("SDWAN_USERNAME")
if not SDWAN_PASSWORD:
missing_variables.append("SDWAN_PASSWORD")
if missing_variables:
print("The following environment variables are missing:")
for variable in missing_variables:
print(f"- {variable}")
print("\nPlease set the missing variables and run the script again.")
sys.exit(1)
def login_to_sdwan_manager(session):
"""
Authenticate to Cisco Catalyst SD-WAN Manager using session-based authentication.
A successful login returns a JSESSIONID cookie, which is stored automatically
inside the requests Session object.
"""
login_url = f"{SDWAN_MANAGER}/j_security_check"
login_payload = {
"j_username": SDWAN_USERNAME,
"j_password": SDWAN_PASSWORD,
}
headers = {
"Content-Type": "application/x-www-form-urlencoded"
}
try:
response = session.post(
url=login_url,
data=login_payload,
headers=headers,
verify=False,
timeout=30,
)
# If authentication fails, some SD-WAN Manager versions return an HTML login page.
if "<html" in response.text.lower():
print("Login failed. Please check your username and password.")
sys.exit(1)
if response.status_code not in [200, 302]:
print(f"Login failed with status code: {response.status_code}")
print(response.text)
sys.exit(1)
print("Login successful.")
except RequestException as error:
print(f"Unable to connect to Cisco Catalyst SD-WAN Manager: {error}")
sys.exit(1)
def get_xsrf_token(session):
"""
Retrieve the XSRF token.
The XSRF token is mainly required for POST, PUT, and DELETE requests.
For this script, we only perform a GET request, but retrieving the token
helps demonstrate the common SD-WAN API workflow.
"""
token_url = f"{SDWAN_MANAGER}/dataservice/client/token"
try:
response = session.get(
url=token_url,
verify=False,
timeout=30,
)
if response.status_code == 200 and response.text:
return response.text
return None
except RequestException:
return None
def get_devices(session, xsrf_token=None):
"""
Retrieve all devices from Cisco Catalyst SD-WAN Manager.
"""
devices_url = f"{SDWAN_MANAGER}/dataservice/device"
headers = {
"Accept": "application/json",
"Content-Type": "application/json",
}
if xsrf_token:
headers["X-XSRF-TOKEN"] = xsrf_token
try:
response = session.get(
url=devices_url,
headers=headers,
verify=False,
timeout=30,
)
if response.status_code != 200:
print(f"Failed to retrieve devices. Status code: {response.status_code}")
print(response.text)
sys.exit(1)
response_data = response.json()
# Many SD-WAN Manager responses return device data under the "data" key.
# Some API documentation examples may show a list directly.
if isinstance(response_data, dict):
return response_data.get("data", [])
if isinstance(response_data, list):
return response_data
return []
except RequestException as error:
print(f"API request failed: {error}")
sys.exit(1)
except ValueError:
print("The response was not valid JSON.")
sys.exit(1)
def print_devices(devices):
"""
Print useful device information in a readable format.
"""
print(f"\nNumber of devices in Cisco Catalyst SD-WAN Manager: {len(devices)}\n")
for device in devices:
hostname = device.get("host-name", "N/A")
device_type = device.get("device-type", "N/A")
system_ip = device.get("system-ip", device.get("deviceId", "N/A"))
reachability = device.get("reachability", "N/A")
status = device.get("status", "N/A")
site_id = device.get("site-id", "N/A")
version = device.get("version", "N/A")
print(f"Hostname : {hostname}")
print(f"Device Type : {device_type}")
print(f"System IP : {system_ip}")
print(f"Reachability : {reachability}")
print(f"Status : {status}")
print(f"Site ID : {site_id}")
print(f"Version : {version}")
print("-" * 50)
def logout_from_sdwan_manager(session):
"""
Log out from Cisco Catalyst SD-WAN Manager.
This is a good practice when using session-based authentication.
"""
logout_url = f"{SDWAN_MANAGER}/logout"
try:
session.post(
url=logout_url,
verify=False,
timeout=30,
)
except RequestException:
pass
def main():
validate_environment_variables()
with requests.Session() as session:
login_to_sdwan_manager(session)
xsrf_token = get_xsrf_token(session)
devices = get_devices(session, xsrf_token)
print_devices(devices)
logout_from_sdwan_manager(session)
if __name__ == "__main__":
main()
Example Output
When you run the script successfully, your output may look similar to this:
Login successful.
Number of devices in Cisco Catalyst SD-WAN Manager: 9
Hostname : Manager
Device Type : vmanage
System IP : 10.10.1.1
Reachability : reachable
Status : normal
Site ID : 101
Version : 20.12.1
--------------------------------------------------
Hostname : Controller
Device Type : vsmart
System IP : 10.10.1.5
Reachability : reachable
Status : normal
Site ID : 101
Version : 20.12.1
--------------------------------------------------
Hostname : Validator
Device Type : vbond
System IP : 10.10.1.3
Reachability : reachable
Status : normal
Site ID : 101
Version : 20.12.1
--------------------------------------------------
Hostname : DC-cEdge01
Device Type : vedge
System IP : 10.10.1.11
Reachability : reachable
Status : normal
Site ID : 100
Version : 17.12.01a.0.118
--------------------------------------------------
Hostname : Site1-cEdge01
Device Type : vedge
System IP : 10.10.1.13
Reachability : reachable
Status : normal
Site ID : 1001
Version : 17.12.01a.0.118
--------------------------------------------------
Hostname : Site12-Edge01
Device Type : vedge
System IP : 10.10.1.22
Reachability : reachable
Status : normal
Site ID : 1012
Version : 17.12.01a.0.118
--------------------------------------------------
Hostname : Site2-cEdge01
Device Type : vedge
System IP : 10.10.1.15
Reachability : reachable
Status : normal
Site ID : 1002
Version : 17.12.01a.0.118
--------------------------------------------------
Hostname : Site3-cEdge01
Device Type : vedge
System IP : 10.10.1.17
Reachability : reachable
Status : normal
Site ID : 1003
Version : 17.12.01a.0.118
--------------------------------------------------
Hostname : Site3-cEdge02
Device Type : vedge
System IP : 10.10.1.18
Reachability : reachable
Status : normal
Site ID : 1003
Version : 17.12.01a.0.118
--------------------------------------------------
Your exact output will depend on the sandbox or lab environment you are using. The number of devices, software versions, hostnames, device types, and system IP addresses may be different.
Code Explanation
Let’s now walk through the script and understand what each part is doing.
The script starts by importing the required modules:
import os
import sys
import requests
from requests.exceptions import RequestException
import urllib3
The os module is used to read environment variables. The sys module is used to exit the script if required information is missing or if an error occurs. The requests library is used to send HTTP requests to Cisco Catalyst SD-WAN Manager. The RequestException class helps us catch connection and request-related errors. The urllib3 module is used here only to suppress certificate warnings in a lab environment.
Next, we disable insecure request warnings:
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
This is useful in a sandbox or lab where the SD-WAN Manager may use a self-signed certificate. In production, you should not simply disable certificate verification. You should use a trusted certificate and keep SSL verification enabled.
Then we read the environment variables:
SDWAN_MANAGER = os.getenv("SDWAN_MANAGER")
SDWAN_USERNAME = os.getenv("SDWAN_USERNAME")
SDWAN_PASSWORD = os.getenv("SDWAN_PASSWORD")
This keeps the script cleaner and safer. Instead of placing the username and password directly inside the Python file, we store them outside the script.
The validate_environment_variables() function checks that all required variables exist before the script continues. This prevents the script from failing later with unclear errors.
The login_to_sdwan_manager() function handles authentication. It sends a POST request to:
/j_security_check
The username and password are sent as form data:
login_payload = {
"j_username": SDWAN_USERNAME,
"j_password": SDWAN_PASSWORD,
}
This is important because Cisco Catalyst SD-WAN Manager session-based authentication expects the credentials using these specific field names.
The script uses a requests.Session() object. This is important because the session automatically stores cookies returned by the server. When SD-WAN Manager returns a JSESSIONID cookie, the session object keeps it and reuses it in later requests.
After login, the script tries to retrieve an XSRF token:
xsrf_token = get_xsrf_token(session)
For a simple GET request, this token may not be required. However, for operations that change something, such as POST, PUT, or DELETE, the token is normally required in newer SD-WAN releases. Including this function helps you understand the authentication flow you will see in real API usage.
The main API call happens inside the get_devices() function:
devices_url = f"{SDWAN_MANAGER}/dataservice/device"
This builds the full URL for the device inventory endpoint. The script then sends a GET request:
response = session.get(
url=devices_url,
headers=headers,
verify=False,
timeout=30,
)
If the request is successful, SD-WAN Manager returns JSON data. The script then extracts the device list.
Some SD-WAN Manager responses return the useful device list under a key called data. That is why the script checks for this:
if isinstance(response_data, dict):
return response_data.get("data", [])
This makes the script more flexible and easier to use across different versions and examples.
Finally, the print_devices() function loops through each device and prints useful fields:
hostname = device.get("host-name", "N/A")
device_type = device.get("device-type", "N/A")
system_ip = device.get("system-ip", device.get("deviceId", "N/A"))
reachability = device.get("reachability", "N/A")
status = device.get("status", "N/A")
site_id = device.get("site-id", "N/A")
version = device.get("version", "N/A")
The .get() method is used because not every device or API version will always return exactly the same fields. If a field is missing, the script prints N/A instead of crashing.
At the end, the script logs out:
logout_from_sdwan_manager(session)
This is a good practice when using session-based authentication because it closes the session when the script is finished.
Conclusion
Cisco Catalyst SD-WAN is Cisco’s software-defined WAN solution that provides centralised management, secure overlay connectivity, policy control, monitoring, troubleshooting, and automation capabilities for the WAN.
From a networking point of view, it helps organisations move away from manually managing individual WAN routers and toward managing the WAN as a centralised fabric. From an automation point of view, the most important component is Cisco Catalyst SD-WAN Manager because it provides the REST API that allows scripts and external tools to interact with the SD-WAN environment.
In this post, we looked at the main SD-WAN components, including SD-WAN Manager, SD-WAN Controller, SD-WAN Validator, and SD-WAN edge devices. We also explored the role of Cisco Catalyst SD-WAN Manager, the purpose of the REST API, common API categories, authentication options, and a practical Python example that retrieves a list of devices from the fabric.
The main takeaway is simple: Cisco Catalyst SD-WAN is not only a WAN management platform; it is also an automation platform. Through its APIs, you can retrieve inventory, monitor the fabric, troubleshoot issues, integrate with other systems, and build repeatable network automation workflows.
References
Cisco Certified DevNet Expert (v1.0) Equipment and Software List
How to get started with the Cisco CCNA Automation course
Cisco Certified DevNet Associate DEVASC 200-901 Official Cert Guide, Chapter 8: Cisco Enterprise Networking Management Platforms and APIs.
Cisco DevNet: Cisco Catalyst SD-WAN Manager API documentation.
Cisco DevNet: Cisco Catalyst SD-WAN Manager Device Inventory API documentation.
Cisco Documentation: Cisco SD-WAN Manager JWT Based Authentication for APIs.
Cisco Documentation: Cisco Catalyst SD-WAN Getting Started Guide.
