Skip to content
Study CCNP

Describe

6.4 Describe APIs for Cisco Catalyst Center and SD-WAN Manager

5 min read ENCOR 350-401 v1.2

Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.

On this page

Cisco controllers are not just graphical dashboards. They expose APIs so other systems can read inventory, trigger workflows, deploy configuration, monitor health, and integrate with operations tools.

For ENCOR, focus on the high-level purpose and request pattern. You do not need to memorize hundreds of endpoints. You do need to know what the APIs are for and how a script usually talks to them.

Northbound vs. southbound

This topic makes more sense if you separate northbound and southbound communication.

Northbound

Northbound APIs face applications, scripts, ITSM tools, monitoring platforms, and automation systems.

Python script / ServiceNow / monitoring tool
controller northbound API
Catalyst Center or SD-WAN Manager

Southbound

Southbound communication faces the network devices.

controller
devices

The controller might use SSH, NETCONF, APIs, telemetry, control connections, or platform-specific mechanisms. For the exam, remember the direction: applications call the controller northbound; the controller manages devices southbound.

Catalyst Center APIs

Cisco Catalyst Center, formerly Cisco DNA Center, is used for enterprise network management and intent-based workflows. Its APIs are used for operations such as:

  • inventory;
  • site hierarchy;
  • device discovery;
  • assurance and health;
  • software image management;
  • template deployment;
  • event notifications and webhooks;
  • integration with external systems.

A common Catalyst Center API flow:

1. Authenticate.
2. Receive token.
3. Send token in X-Auth-Token header.
4. Call an intent API endpoint.
5. Parse JSON response.

Catalyst Center token example

import os
import requests
from requests.auth import HTTPBasicAuth

base_url = os.environ["CAT_CENTER_URL"]
username = os.environ["CAT_CENTER_USER"]
password = os.environ["CAT_CENTER_PASS"]
ca_bundle = os.environ.get("REQUESTS_CA_BUNDLE", True)

response = requests.post(
    f"{base_url}/dna/system/api/v1/auth/token",
    auth=HTTPBasicAuth(username, password),
    headers={"Content-Type": "application/json"},
    timeout=10,
    verify=ca_bundle
)

response.raise_for_status()
token = response.json()["Token"]
print("Token received")

After that, the token is commonly sent in the X-Auth-Token header.

headers = {"X-Auth-Token": token}

response = requests.get(
    f"{base_url}/dna/intent/api/v1/network-device",
    headers=headers,
    timeout=10,
    verify=ca_bundle
)

print(response.status_code)
print(response.json())

Do not print real tokens in automation logs. Use shell-safe secret input, a vault, a keychain, or a CI secret store for credentials. Environment variables are better than hard-coded passwords in examples, but they still need careful handling in shared shells and logs.

What to recognize in exam snippets

If you see this:

/dna/system/api/v1/auth/token

Think: Catalyst Center authentication.

If you see this:

/dna/intent/api/v1/network-device

Think: retrieve or work with network device inventory through Catalyst Center.

SD-WAN Manager APIs

Cisco SD-WAN Manager, historically known as vManage, is the management plane for Cisco Catalyst SD-WAN. Its APIs are used for operations such as:

  • device inventory;
  • control and data-plane monitoring;
  • templates;
  • policies;
  • alarms and events;
  • software and configuration operations;
  • operational statistics.

A common session-based SD-WAN Manager API flow:

1. POST credentials to /j_security_check.
2. Keep the session cookie.
3. Get or provide an anti-CSRF token when required.
4. Call /dataservice/... endpoints.
5. Parse JSON response.

Newer environments may support JWT-style authentication, but session-based examples are still common in labs and documentation. A successful classic session login can return an empty response body and set a session cookie; a failed login can return an HTML login page instead of JSON. Read the question carefully.

SD-WAN Manager session example

import os
import requests

base_url = os.environ["SDWAN_URL"]
username = os.environ["SDWAN_USER"]
password = os.environ["SDWAN_PASS"]
ca_bundle = os.environ.get("REQUESTS_CA_BUNDLE", True)

session = requests.Session()

login = session.post(
    f"{base_url}/j_security_check",
    data={"j_username": username, "j_password": password},
    timeout=10,
    verify=ca_bundle
)

if b"<html" in login.content.lower():
    raise SystemExit("Login failed")

token_response = session.get(
    f"{base_url}/dataservice/client/token",
    timeout=10,
    verify=ca_bundle
)

if token_response.status_code == 200 and token_response.text:
    session.headers["X-XSRF-TOKEN"] = token_response.text

devices = session.get(
    f"{base_url}/dataservice/device",
    timeout=10,
    verify=ca_bundle
)

print(devices.status_code)
print(devices.json())

session.get(f"{base_url}/logout", timeout=10, verify=ca_bundle)

In the classic SD-WAN Manager flow, the session cookie proves the login session and X-XSRF-TOKEN protects state-changing requests from cross-site request forgery. Read-only GET requests generally depend on the authenticated session cookie; mutating methods commonly require both the session cookie and XSRF token. Do not treat the XSRF token as the same thing as a bearer auth token. If you use a session-based workflow, log out or close the session when the script is done, when the platform supports it.

What to recognize in exam snippets

If you see:

/j_security_check
/dataservice/client/token
/dataservice/device

Think: SD-WAN Manager API session, token, and device inventory.

Catalyst Center vs. SD-WAN Manager

AreaCatalyst CenterSD-WAN Manager
Primary domainEnterprise campus and branch managementSD-WAN fabric management
Common old nameDNA CentervManage
API styleREST intent APIsREST APIs under /dataservice
Common auth patternBasic auth for token, then X-Auth-TokenSession cookie, anti-CSRF token, or JWT depending on version
Common useinventory, assurance, sites, templates, eventsdevices, templates, policies, alarms, statistics

Why controllers matter for automation

Without a controller, a script often talks to each device one by one.

script
R1
script
R2
script
SW1
script
SW2

With a controller, the script can ask one system for inventory, health, or a workflow.

script
controller -> managed network

This is powerful because the controller already knows device identity, topology, site hierarchy, policy state, health, and credentials.

Lab: compare controller API flows

Goal

Understand the authentication and inventory pattern for both controllers.

Option A: Catalyst Center sandbox or lab

Create cat_center_inventory.py:

import os
import requests
from requests.auth import HTTPBasicAuth

BASE_URL = os.environ["CAT_CENTER_URL"]
USERNAME = os.environ["CAT_CENTER_USER"]
PASSWORD = os.environ["CAT_CENTER_PASS"]
CA_BUNDLE = os.environ.get("REQUESTS_CA_BUNDLE", True)

token_response = requests.post(
    f"{BASE_URL}/dna/system/api/v1/auth/token",
    auth=HTTPBasicAuth(USERNAME, PASSWORD),
    headers={"Content-Type": "application/json"},
    timeout=10,
    verify=CA_BUNDLE
)
token_response.raise_for_status()
token = token_response.json()["Token"]

inventory_response = requests.get(
    f"{BASE_URL}/dna/intent/api/v1/network-device",
    headers={"X-Auth-Token": token},
    timeout=10,
    verify=CA_BUNDLE
)
inventory_response.raise_for_status()

for device in inventory_response.json().get("response", []):
    print(device.get("hostname"), device.get("managementIpAddress"))

Run:

export CAT_CENTER_URL="https://x.x.x.x"
export CAT_CENTER_USER="admin"
read -sr CAT_CENTER_PASS
export CAT_CENTER_PASS
echo
python3 cat_center_inventory.py
unset CAT_CENTER_PASS

Option B: SD-WAN Manager sandbox or lab

Create sdwan_inventory.py:

import os
import requests

BASE_URL = os.environ["SDWAN_URL"]
USERNAME = os.environ["SDWAN_USER"]
PASSWORD = os.environ["SDWAN_PASS"]
CA_BUNDLE = os.environ.get("REQUESTS_CA_BUNDLE", True)

session = requests.Session()
login = session.post(
    f"{BASE_URL}/j_security_check",
    data={"j_username": USERNAME, "j_password": PASSWORD},
    timeout=10,
    verify=CA_BUNDLE
)

if b"<html" in login.content.lower():
    raise SystemExit("Login failed")

token = session.get(f"{BASE_URL}/dataservice/client/token", timeout=10, verify=CA_BUNDLE)
if token.status_code == 200 and token.text:
    session.headers["X-XSRF-TOKEN"] = token.text

response = session.get(f"{BASE_URL}/dataservice/device", timeout=10, verify=CA_BUNDLE)
response.raise_for_status()

for device in response.json().get("data", []):
    print(device.get("host-name"), device.get("system-ip"), device.get("device-type"))

session.get(f"{BASE_URL}/logout", timeout=10, verify=CA_BUNDLE)

Run:

export SDWAN_URL="https://x.x.x.x"
export SDWAN_USER="admin"
read -sr SDWAN_PASS
export SDWAN_PASS
echo
python3 sdwan_inventory.py
unset SDWAN_PASS

What to write in your notes

After the lab, write:

Lab notes checklist (both controllers):

  • Auth pattern used (token header, cookie, or JWT)
  • Inventory endpoint called
  • Top-level JSON keys returned
  • One failure seen and how you fixed it

Exam traps

  • verify=False is a lab shortcut for untrusted or self-signed certificates, not the safe automation pattern. Prefer a trusted CA bundle or platform certificate chain.
  • Hard-coded credentials make examples shorter but create bad habits. Use shell-safe secret input, a vault, keychain, CI secret store, or another secrets manager in real scripts.
  • Catalyst Center and SD-WAN Manager are controllers, not individual routers.
  • Northbound APIs face scripts and external systems.
  • Southbound communication manages devices.
  • Catalyst Center often uses X-Auth-Token after token creation.
  • SD-WAN Manager commonly uses session cookies, an XSRF token for protected requests, and /dataservice/... endpoints in classic examples.
  • A session cookie, XSRF token, and JWT bearer token are different artifacts. Read the API pattern before copying headers between controllers.
  • API auth failures are usually 401 or 403, not routing failures.
  • A controller can return a successful HTTP status while the requested workflow task still needs polling or task-status checking.

Exam-ready summary

Catalyst Center APIs help automate campus and enterprise network workflows such as inventory, assurance, sites, templates, and events. SD-WAN Manager APIs help automate SD-WAN device, policy, template, alarm, and statistics workflows. For ENCOR, know the controller role, the northbound API idea, the authentication pattern, and the JSON request/response flow.

Sources used

  • Cisco ENCOR 350-401 v1.2 exam topics: https://learningcontent.cisco.com/documents/marketing/exam-topics/350-401-ENCORE-v1.2.pdf
  • Cisco Catalyst Center API documentation: https://developer.cisco.com/docs/catalyst-center/
  • Cisco Catalyst Center Authentication API: https://developer.cisco.com/docs/catalyst-center/authentication-api/
  • Cisco Catalyst SD-WAN Manager API authentication: https://developer.cisco.com/docs/sdwan/authentication/