Cisco Platforms and Development
Domain 3 tests selecting the right Cisco platform API, authenticating correctly, and using platform objects and identifiers without mixing conventions. You need to recognize the API style, auth mechanism, and primary resources for each platform.
Platform map
- Meraki Dashboard API: REST/JSON over HTTPS. Send the API key in
X-Cisco-Meraki-API-Key. Hierarchy is organizations, then networks, then devices. Use it for cloud-managed MX, MR, and MS; handle429on rate limits. - Webex: REST/JSON with OAuth 2.0 Bearer tokens. Common resources are
/v1/rooms,/v1/messages,/v1/memberships, and/v1/webhooks. Scopes includespark:rooms_writeandspark:messages_write. - DNA Center: REST Intent API.
POST /dna/system/api/v1/auth/tokenwith Basic authentication returns a token; send it asX-Auth-Token. Manage sites, devices, templates, and assurance; long operations return task IDs. - ACI: APIC REST.
POST /api/aaaLogin.jsonreturns a cookie token. The object model uses distinguished names (DNs) and supports JSON or XML. - NSO: model-driven orchestration with NETCONF/RESTCONF, YANG service models, and a JSON-RPC API.
- IOS XE: NETCONF and RESTCONF with YANG models; Guest Shell runs Python; EEM provides event-driven automation.
- Intersight uses REST with API-key signing and SDKs; vManage uses REST with a session and XSRF token.
Worked example
Create a Webex room and post a message. Reasoning: request an OAuth token with room-write and message-write scopes. POST /v1/rooms with a title returns the room id. Use that id as roomId in POST /v1/messages with text. If the token lacks the message scope, the call fails with 403; if it expires, 401. Never log the bearer token, and handle 429 with Retry-After.
Traps
- Sending a Meraki API key as a Bearer token.
- Treating a DNA Center token as a permanent API key instead of refreshing it.
- Reusing an expired ACI cookie or ignoring DN structure.
- Assuming a long-running DNA Center or NSO operation is synchronous.
- Hardcoding tokens or putting Meraki keys in URLs.