3.1Cisco SDKs and network management APIs

Cisco exposes a management API per product, but the exam does not ask whether you have memorized each API's spec—it asks which platform's API you would call to solve the automation requirement in front of you. Even "get a device list" targets a different endpoint on cloud-managed Meraki, on Catalyst Center governing an enterprise access network, and on data-center SDN with ACI. This section first pins down what an SDK buys you instead of writing raw requests, then lines up the main platforms by "which problem each one solves."

3.1.1What an SDK takes off your hands

• An SDK (software development kit) is a set of libraries that make an API easy to use from a particular language. Instead of hand-writing the URL, auth headers, pagination, and error handling in a raw requests.get(url, headers=...), you get the same result via a method call like dashboard.organizations.getOrganizationDevices(org_id). Cisco ships Python SDKs for Meraki (the official meraki package), Webex, and more.
• The value of an SDK is abstraction and consistency—it hides boilerplate such as auth and pagination and returns results as native data structures (Python dict/list). But underneath it is still the same REST API, so when a new feature is not yet covered or you need fine-grained control, the sound call is to drop down to raw REST/RESTCONF. Treat an SDK as a tool to write boilerplate quickly and safely, not as a cure-all.

3.1.2Scope of the main management platforms

• Meraki is cloud-managed: devices (MX/MR/MS, etc.) are centrally managed from a cloud dashboard, and the Dashboard API (REST, API-key auth) operates organizations, networks, devices, and clients. It shines when many sites need unified cloud management.
• Catalyst Center (formerly DNA Center) is an on-prem controller that governs the enterprise access network (wired/wireless). Its Intent API offers intent-based operations (device inventory, topology, policy, assurance). ACI is data-center SDN, where the APIC controller manages the fabric declaratively.
• Catalyst SD-WAN (formerly Viptela) binds the WAN into an overlay and controls policies/templates through the vManage controller's REST API. Cisco NSO is a multi-vendor service orchestration platform that pushes configuration to diverse devices via YANG service models and NETCONF/CLI (cross-vendor automation, including non-Cisco).

Suppose you are automating operations for a retail chain with 200 nationwide sites. There are three requirements: "(1) every morning, fetch the list of online devices from each store's cloud-managed network; (2) codify and deploy an application tenant (EPG) in the head-office data center; (3) push standard service configuration in bulk to WAN sites, including newly added non-Cisco gear." Lumping these as "it is Cisco automation, so use Catalyst Center's Intent API for everything" is wrong—you must see that each requirement points at a different management domain. Since (1) binds store devices in the cloud, the natural move is Meraki's Dashboard API (endpoints under organizations, such as getOrganizationDevicesStatuses); standing up a controller per store would be overkill. Requirement (2) is about data-center SDN, so it targets ACI's APIC, which handles tenants/EPGs declaratively—hunting for this in Meraki's Dashboard API would find no such object. Requirement (3) hinges on multi-vendor and service-level bulk rollout, so Cisco NSO, which distributes to heterogeneous devices via YANG service models, is the best fit (piping CLI to a single device does not survive a non-Cisco mix or standardization). If a need to pull assurance or topology for the enterprise wired/wireless access network is added, that is exactly when Catalyst Center's Intent API earns its place. The point: platform selection is not "because it is new" or "because it is famous," but the judgment to pick the API whose managed domain (cloud / DC / WAN / access network / cross-vendor) matches the requirement.

3.1.3Section summary

• An SDK abstracts raw REST into language-native methods; underneath it is the same REST API, so drop to raw REST/RESTCONF for uncovered features or fine control
• Meraki = cloud/Dashboard API, Catalyst Center = access network/Intent API, ACI = DC SDN/APIC, Catalyst SD-WAN = WAN/vManage, NSO = cross-vendor
• Platform selection is the judgment to pick the API whose managed domain matches the requirement, not consolidating on one "because it is famous"