A network operations team is building two Python jobs for Catalyst Center: one onboards branch switches with sites, credentials and profiles, and another feeds a dashboard with open issues and client health for those branches. Which split between the Intent API and the Network Assurance API should each job adopt?
Select an answer to reveal the explanation.
Short Explanation
These two APIs split along changing things versus watching them, a bit like a build crew and a home inspector. You'll send provisioning to the Intent API and dashboard queries to the Assurance API, which reads back near-real-time health analytics for you.
Full Explanation
Catalyst Center splits its automation surface into writing intent and reporting health. The Intent API carries the write workflows: creating sites, saving credentials, assigning device profiles, onboarding and provisioning hardware, and checking configuration compliance, all of which change what the controller does to the network. The Network Assurance API carries the read side, serving analytics the assurance engine builds from streamed telemetry, including issue lists, site health and client health over time. Swapping those roles fails immediately, because assurance endpoints expose analytics rather than provisioning transactions, while Intent workflow endpoints answer with workflow status instead of historical health. Deriving client health from compliance status also fails, since compliance compares configured state against intended state and says nothing about how users experience the network. Building the dashboard from Command Runner CLI snapshots fails the ongoing requirement as well, because those are on-demand, device-by-device outputs with no client or issue analytics behind them. Exam caveat: endpoint paths and response fields change between releases, so learn the roles rather than memorizing URLs. Practical check: request an assurance issue summary and confirm it returns telemetry-based records.