Cisco ACI and Meraki APIs

Let's start with the big picture. A network is a collection of connected devices like switches, routers, and firewalls. Traditionally, to change anything on the network, a human engineer would log into each device individually and type commands. This is slow, error-prone, and doesn't scale well.

Cisco ACI (Application Centric Infrastructure) is a solution to this problem for large data centres. Instead of managing each switch separately, ACI treats the whole data centre fabric as one giant, programmable switch. The key component is the APIC (Application Policy Infrastructure Controller). The APIC is the central brain. It holds the entire network policy — rules about which applications can talk to each other, security settings, and quality of service. When you tell the APIC a new rule, it automatically pushes that rule to every relevant switch in the fabric. You never touch a switch directly.

How do you talk to the APIC? Through an API (Application Programming Interface). Specifically, ACI exposes a REST API. REST (Representational State Transfer) is a standard way for software to talk to software over HTTP, the same protocol your web browser uses. When you send a REST API request, you use HTTP methods like GET (read data), POST (create), PUT (update), or DELETE (remove). For ACI, you send these requests to the APIC's IP address. The APIC understands JSON (JavaScript Object Notation), a lightweight text format for structuring data, like a very organised shopping list.

An example: say you want to create a new network segment for a web server. You write a Python script that sends a POST request to the APIC with a JSON body describing the segment. The APIC receives it, applies the configuration to all relevant switches, and sends back a success message. This whole process takes under a second. Doing it manually could take 30 minutes.

Now, what about Cisco Meraki? Meraki is a different product line aimed at smaller organisations, like branch offices, schools, or retail stores. Meraki devices (switches, wireless access points, firewalls) are managed through a cloud-based dashboard. You log into a website to see and change settings. But Meraki also offers a REST API. The key difference is that the Meraki API is hosted in the cloud, not on a local controller. You send your API requests to a special Meraki cloud URL (api.meraki.com), and the cloud then pushes changes to your remote devices.

Both ACI and Meraki APIs use authentication. Before you can do anything, you must prove who you are. For ACI, you typically use a username and password, or an API token generated in the APIC. For Meraki, you use an API key, a unique string of letters and numbers that you create in the Meraki dashboard. This key is sent as a header in every request, like a digital ID badge.

The crucial concept for the exam is that these APIs allow for automation. Instead of a human clicking buttons in a dashboard, a script can react to events. For example, if a new server is automatically deployed in your data centre, a script can automatically call the ACI API to open the required firewall rules. This is the heart of DevOps — using code to manage infrastructure (often called Infrastructure as Code or IaC).

ACI focuses on the "fabric" — a group of switches that act as one. Meraki focuses on "cloud-managed" — devices that phone home to the cloud. Both provide programmable control, but their architecture differs. ACI is on-premises, low latency, and very powerful. Meraki is cloud-based, simpler, and better for distributed locations. The 200-901 exam expects you to know these fundamental differences and how to interact with both APIs using HTTP and JSON.

An IT professional at a mid-sized company called "GreenLeaf Inc." is responsible for their network. GreenLeaf has one main data centre with 50 servers and 10 branch offices around the country, each with a small Meraki switch and a wireless access point.

In the data centre, the engineer uses Cisco ACI. Every morning, they run a script that checks the health of the network. The script calls the ACI REST API with a GET request to fetch all active faults. The API returns a JSON list. If a fault is critical, the script automatically opens a ticket in the company's helpdesk system using another API. This is a classic example of IT automation — using APIs to connect different systems so they work together without manual intervention.

One day, a new application team needs a new network segment for a customer-facing web app. Instead of opening a ticket and waiting for the network team, the engineer has built a self-service portal. The developer fills out a web form. That form triggers a script that sends a POST request to the ACI API, creating:

- A new bridge domain (a logical network segment) - A contract (a set of firewall rules allowing web traffic) - An endpoint group (EPG, a group of servers bound by a policy) The whole process takes 10 seconds. Without the API, it would take hours of manual configuration across multiple switches.

Meanwhile, a branch office in Manchester reports that its Wi-Fi is slow. The engineer logs into the Meraki cloud dashboard, but they don't click around. Instead, they run a Python script that uses the Meraki REST API to fetch the signal-to-noise ratio for every access point in that office. The script finds one AP with a poor channel. The engineer then sends a PUT request to the Meraki API to change the radio channel on that AP. The change takes effect in seconds.

The engineer also uses the Meraki API to automate onboarding of new branch offices. When a new office opens, they plug in the Meraki switch and AP. The devices automatically connect to the Meraki cloud and appear in the dashboard. The engineer's script detects the new devices via the API and automatically applies a standard configuration template. This is called zero-touch provisioning (ZTP). Without the API, the engineer would have to configure each device manually over a command-line interface (CLI).

In summary, the IT professional uses both ACI and Meraki APIs to:

- Automate repetitive tasks (health checks, configuration changes) - Enable self-service for other teams (developers creating network segments) - Perform remote troubleshooting without logging into a GUI - Standardise deployments across many locations - Integrate network management with other IT systems (ticketing, monitoring) The skill tested in 200-901 is knowing how to structure these API calls, what authentication to use, and how to interpret the JSON responses.