Catalyst Center APIs: Intent, Inventory, and AI-Powered Assurance

Automating a single router with NETCONF is one thing. Automating a campus of hundreds of devices, with a single source of truth for intent, is what Catalyst Center (formerly DNA Center) is for. It is Cisco's controller for the enterprise network, and it exposes everything it does through a REST API. If you want to programmatically inventory your network, push intent, or pull assurance data at scale, that API is the door.

This article explains the Catalyst Center API model, the categories of endpoint, and how to work with it. It extends the Network Automation cluster guide. The request and response examples here are documentation-style illustrations of the API's shape, not lab captures, because Catalyst Center cannot run in CML; for hands-on practice, use Cisco's always-on DevNet sandboxes.

The Intent API Model

The key idea behind Catalyst Center's API is intent. Instead of telling each device what to do, you tell the controller what you want, and it works out the per-device configuration and pushes it. You express "this SSID should exist on these buildings" or "this device should run this template"; the controller renders and deploys the CLI. The API is the programmatic version of that: you POST intent, the controller executes it.

The endpoints group into a few clear categories:

Authentication: Token First

Every Catalyst Center API workflow starts the same way: authenticate once, get a token, use the token. This is the token model from the API security article, and it is worth doing right because that token is a network-wide credential.

# 1. Authenticate, receive a token (documentation-style example)
POST https://<catalyst-center>/dna/system/api/v1/auth/token
Authorization: Basic <base64 user:pass>

-> 200 OK
{ "Token": "eyJhbGciOi...<JWT>..." }

# 2. Use the token on every subsequent call
GET https://<catalyst-center>/dna/intent/api/v1/network-device
X-Auth-Token: eyJhbGciOi...

The token is short-lived (typically an hour). A robust script requests it, holds it in memory, and re-requests on a 401, exactly the pattern the response-codes article describes. It never logs the token and never commits it.

Reading the Inventory

The most common first real task: pull the device inventory. The response is structured JSON, one object per device:

GET /dna/intent/api/v1/network-device
X-Auth-Token: <token>

-> 200 OK
{
  "response": [
    {
      "hostname": "campus-core-1",
      "managementIpAddress": "10.1.1.1",
      "platformId": "C9500-40X",
      "softwareVersion": "17.9.4",
      "reachabilityStatus": "Reachable",
      "role": "CORE"
    },
    ...
  ]
}

From here everything is normal JSON handling (the subject of the Python and JSON article): iterate response, pull the fields you need. The device id in each object is the handle you use for follow-up calls (health, config, command runner). This inventory pull is the "hello world" of Catalyst Center automation and the foundation of most scripts.

The AI-Driven Assurance Angle

The renamed emphasis in the current ENCOR blueprint ("Automation and Artificial Intelligence") shows up here. Catalyst Center's assurance is not just raw metrics; it applies machine learning to establish baselines, correlate events, and surface issues with probable root causes rather than leaving you to read graphs. Through the API you can pull:

• Health scores for clients, devices, and applications, computed from many underlying metrics into a single 1-10 number.
• Issues, the controller's own list of detected problems, each with a severity, an affected scope, and often a suggested remediation.
• Trends and anomalies, where the AI has learned normal behaviour and flags deviations, catching a slow degradation a threshold alert would miss.

For a network engineer, the practical value is that you can feed these into your own tooling: a script that pulls open issues each morning, a dashboard that tracks health-score trends, an alert that fires when the controller's AI flags an anomaly. The intelligence lives in the controller; the API lets you act on it.

The Asynchronous Task Model

One important wrinkle: many Catalyst Center write operations are asynchronous. When you POST a provisioning intent, you do not get the result immediately; you get a task ID, and the actual work happens in the background. You then poll a task endpoint to learn whether it succeeded.

POST /dna/intent/api/v1/<provisioning-call>
-> 202 Accepted
{ "response": { "taskId": "abc-123", "url": "/dna/intent/api/v1/task/abc-123" } }

# poll until the task completes
GET /dna/intent/api/v1/task/abc-123
-> { "response": { "isError": false, "progress": "..." } }

The 202 Accepted response is the signal: "I have queued your request." A script that treats 202 as final success is wrong; it must poll the task ID until isError is set one way or the other. This asynchronous pattern is common to controllers generally and is a frequent source of "the API said OK but nothing happened" confusion. It did not say OK; it said "accepted, ask me later."

FAQ

Can I lab Catalyst Center?

Not in CML. Use Cisco's always-on DevNet sandboxes (sandboxdnac.cisco.com and similar), which expose a real Catalyst Center API you can call for free. The examples here illustrate the API shape; the sandbox is where you run them for real.

How does authentication work?

Basic auth once to /dna/system/api/v1/auth/token returns a JWT token. Send that token as X-Auth-Token on every subsequent call. It expires (about an hour); re-authenticate on a 401.

Why did my provisioning call return 202 with no result?

Because it is asynchronous. 202 means "accepted and queued." You get a task ID and must poll the task endpoint until it reports success or error. 202 is not final success.

What is the difference between the intent API and the CLI?

The CLI configures one device. The intent API tells the controller what you want, and the controller renders and pushes the per-device config across the whole managed network. You express outcome, not per-device commands.

Is DNA Center the same as Catalyst Center?

Yes, renamed. The API paths still contain /dna/ for compatibility, but the product is Catalyst Center. The blueprint uses the current name.

Key Takeaways

• Catalyst Center is the enterprise controller; its REST API exposes inventory, assurance, intent/provisioning, and command runner.
• The model is intent: you tell the controller what you want, it renders and pushes per-device config.
• Authenticate once for a token (/auth/token), send it as X-Auth-Token, re-auth on 401. Treat the token as a network-wide credential.
• The AI-driven assurance (health scores, issues, anomalies) is pullable via the API, letting you act on the controller's intelligence in your own tooling.
• Write operations are often asynchronous: a 202 Accepted returns a task ID you must poll. 202 is not final success.
• It cannot be labbed in CML; use the DevNet always-on sandboxes for hands-on practice.

Next: SD-WAN Manager API, or the Network Automation cluster guide.