Automation
Interfaces and tools
NX-OS exposes several automation surfaces: NX-API (JSON or XML over HTTPS 443, in either CLI-style or DME object style), NETCONF/YANG, RESTCONF, and the Guest Shell for on-box Python. DCNM/NDFC provides fabric-wide provisioning and templates; Ansible uses nxos modules over network_cli or httpapi; POAP automates initial bring-up through DHCP plus TFTP/HTTP and a script.
Key concepts to name: idempotency (running the same playbook twice yields the same state), declarative versus imperative intent, check/dry-run mode, and a single source of truth instead of ad hoc CLI.
Traps
NX-API must be enabled (feature nxapi) and listens in the management VRF by default. A CLI-style request must specify the right message type, and the reply nests under ins_api.outputs.body. Plain HTTP on port 80 versus HTTPS on 443 is a classic distractor. A playbook that reruns and keeps reporting changes is usually not idempotent because the intended state was expressed as raw CLI. Feature commands gate everything: feature bgp, feature interface-vlan, feature nxapi.
Worked example
To verify VXLAN peers from a script, POST to https:///ins with a body whose ins_api object sets version 1.0, type cli_show, chassis 1, input "show nve peers", and output_format json. Parse ins_api.outputs.body, not the top-level JSON.
Rule of thumb
Read before you write. Fetch current state (nxos_facts, a REST GET, show run section), compute the delta, push only that, and create an NX-OS checkpoint first so rollback is one command.