Meraki API Automation: A Practical Guide for UK IT Teams

Meraki API automation means using the Dashboard API, a RESTful interface, to configure, monitor and audit your Meraki estate from scripts instead of clicking through the dashboard. For multi-site organisations such as schools and trusts, manufacturers, hotel groups and logistics operators, it turns repetitive changes into repeatable, reviewable code. This guide covers the essentials: getting a key safely, working within rate limits, using Python, batching changes, replacing polling with webhooks, and knowing when automation is the wrong tool.

TL;DR

• The Meraki Dashboard API is enabled by default, and a key inherits the permissions of the administrator who creates it, so create keys from a purpose-made account with only the access the script needs.
• Budget your calls: the limit is per organisation, so one runaway script can slow every other integration. Use the official Python library, which handles retries on 429 responses.
• Use action batches for bulk writes and the Push API (webhooks) for change detection, rather than polling.
• Store keys in environment variables or a secrets manager, never in scripts, and plan for key expiry.
• Automation suits repeatable, estate-wide work. One-off changes to a templated estate are often quicker in the dashboard.

Table of Contents

• What the Meraki Dashboard API does
• Getting started: API keys and access
• Meraki API automation with Python
• Working within rate limits
• Action batches for bulk changes
• Replace polling with webhooks
• Our perspective: where automation pays and where it does not
• A safe workflow for production changes
• Common pitfalls
• When to bring in a partner
• FAQ
• Sources

What the Meraki Dashboard API does

The Dashboard API is an interface that lets software talk directly to the Meraki cloud platform and the devices it manages. Cisco’s documentation describes uses such as automated network provisioning, bulk configuration changes and custom dashboards. The same page cites a large retailer that provisioned 1,800 store networks in 9 minutes.

Meraki offers more than one API. The Meraki developer hub describes three, and notes that they are free to use. The Dashboard API is the one most IT teams start with, and it is the focus here.

Typical automation jobs include:

• Provisioning: creating networks from a standard design, claiming devices and applying settings such as VLANs, SSIDs and firewall rules.
• Bulk change: updating an SSID, a switch port profile or a syslog destination across dozens or hundreds of sites.
• Reporting: exporting device inventory, licence state, firmware status or client counts for audit.
• Drift detection: confirming that live configuration still matches the approved standard.
• Integration: feeding alerts into a ticketing system or asset register.

Getting started: API keys and access

Access is simple, and the risks sit in how keys are handled.

1. Check the API is on. Cisco states that the Dashboard API is enabled by default on all organisations.
2. Use the right account. You need a non-SAML/SSO account to generate a key. SAML users cannot generate API keys.
3. Generate the key. You can do it from the API & Webhooks page or from My Profile. The key is tied to the administrator who creates it and inherits that person’s permissions.
4. Record it immediately. The dashboard does not store keys in plain text, so the moment of creation is the only time you can copy it. If it is lost, revoke it and generate another.
5. Mind the limit. Each user profile can hold a maximum of two active keys at a time, which is useful for rotating a key without downtime.

Key hygiene that auditors will ask about

Because a key carries the full permissions of its owner, a key created by a super-admin is a super-admin credential. Our recommendations:

• Create a dedicated service account with the narrowest role that does the job. A reporting script needs read-only access.
• Keep keys out of source code. Load them from an environment variable or a secrets manager.
• Rotate on a schedule. Cisco’s April to July 2026 release notes describe security updates including a default one-year key expiry and header-based authentication for webhooks, so build key renewal into your operational calendar rather than discovering it when a job fails.
• Revoke keys when staff or suppliers leave.

For schools, trusts and other organisations working to formal compliance expectations, this is part of the evidence that network changes are controlled. Our cybersecurity compliance basics guide covers the wider picture.

Meraki API automation with Python

Python is the most common choice, and Cisco publishes an official Python library covering the Dashboard API calls. It supports Python 3.7 or above, and it includes error handling, logging and retry logic for 429 rate limit responses, so you write business logic rather than HTTP plumbing. The source is available in the dashboard-api-python repository, which is generated from the API’s OpenAPI specification so that it tracks releases.

Example 1: list every network in an organisation

import os
import meraki

dashboard = meraki.DashboardAPI(
    api_key=os.environ["MERAKI_DASHBOARD_API_KEY"],
    suppress_logging=True,
)

org_id = os.environ["MERAKI_ORG_ID"]
networks = dashboard.organizations.getOrganizationNetworks(
    org_id, total_pages="all"
)

for n in networks:
    print(n["name"], n["id"], n["productTypes"])

The key is read from the environment, and pagination is handled by the library. This is a sensible first script because it is read-only and gives you the network IDs that most other calls need.

Example 2: report devices by model

from collections import Counter

devices = dashboard.organizations.getOrganizationDevices(
    org_id, total_pages="all"
)
print(Counter(d["model"] for d in devices))

A model count is the starting point for refresh planning. Add serial numbers and network names and you have an export for your asset register.

Example 3: change one setting across many sites

for n in networks:
    if "wireless" not in n["productTypes"]:
        continue
    ssids = dashboard.wireless.getNetworkWirelessSsids(n["id"])
    for s in ssids:
        if s["name"] == "Guest" and not s["enabled"]:
            print("Guest SSID disabled at", n["name"])

Note that this one only reports. Run any script that writes against a single test network first, log what it intends to change, and only then enable the write call. A mistaken filter can alter every site at once.

Working within rate limits

The API call budget exists to protect your network from runaway applications. Cisco’s rate limit page sets out the figures:

Two practical consequences follow.

First, the limit is shared across the organisation. A nightly export, a monitoring integration and an engineer’s ad hoc script all draw on the same budget. Schedule heavy jobs away from each other.

Second, retries need to be polite. If you are not using the official library, read the Retry-After header and back off rather than hammering the endpoint.

Action batches for bulk changes

Looping over hundreds of networks with one call per setting is the fastest way to exhaust your budget. Action batches group multiple write actions (create, update, destroy) into one request and apply them atomically: all succeed or none do. Cisco gives the example of adding a switch to a network, configuring all 48 ports and setting its management interface in a single operation.

That all-or-nothing behaviour matters in practice. A half-applied change across a site is harder to diagnose than a failed one. Batches can run synchronously or asynchronously depending on size, so check the current limits on that page before designing a large job.

Prefer update (PUT) operations where the endpoint allows, because repeating them with the same payload leaves the same result. That makes a failed run safe to repeat, which is a property you want in anything scheduled.

Replace polling with webhooks

A common mistake is to poll the API every minute for device status. It burns budget and still lags behind reality. The Push API is Meraki’s event-driven delivery service: you configure a webhook endpoint once and receive data as it becomes available instead of polling repeatedly.

This suits three scenarios well:

• Configuration change alerts: be told when an administrator alters a firewall rule, rather than diffing exports.
• Availability events: pass device-down alerts to your service desk without a polling loop.
• Compliance evidence: keep a timestamped record of changes for review.

When you build a webhook receiver, authenticate inbound calls using the header-based approach described in Cisco’s 2026 release notes, and keep the endpoint reachable only as far as it needs to be.

Our perspective: where automation pays and where it does not

We have worked with Cisco networks for over 35 years, and our view on Meraki automation is deliberately pragmatic. The API is excellent for estate-wide consistency, but it is not a reason to script everything.

Automation earns its keep when three things are true: the task repeats, it spans many sites, and the result can be verified. A school trust rolling out a new staff SSID to forty sites meets all three. A single firewall tweak at one site does not, and writing and testing a script costs more than the change.

We also see a trade-off between the API and Meraki’s own configuration templates. For estates built on templates, one edit to the template reaches every bound network, with no code to maintain. We explain the boundary in Meraki Templates: When One Edit Beats API Cloning, and When It Doesn’t. The API comes into its own for the things templates cannot express: inventory reporting, per-site exceptions, onboarding workflows and integration with other systems.

The second lesson is ownership. A script that nobody maintains becomes a risk. Every automation needs a named owner, version control, a test network and a plain-English description of what it changes. Without these, the first engineer to leave takes the knowledge with them.

Finally, automation should follow design, not replace it. If the underlying network architecture is inconsistent, scripts will faithfully spread the inconsistency. An audit of the network first usually saves more time than the scripting that follows.

— Jacob

A safe workflow for production changes

Whatever you automate, a repeatable process reduces risk:

1. Read before you write. Start with a GET script that lists the objects you intend to change.
2. Dry run. Print the exact change per site. Review it with a second person.
3. Pilot. Apply to one low-impact network, such as a test or small office site, and verify on the dashboard.
4. Batch the rollout. Use action batches in sensible groups rather than the whole estate at once.
5. Verify. Re-read the configuration and compare it with the intended state.
6. Record. Keep logs of the run, who ran it and which key was used.

In environments where downtime is expensive, such as manufacturing sites with production lines on the network, schedule changes inside agreed maintenance windows even when the API makes them near instant.

Common pitfalls

• Hardcoded keys in scripts shared by email or stored in a repository.
• Over-privileged keys. Reporting jobs do not need full write access.
• Polling loops that consume the shared budget and starve other tools.
• No pagination. Large organisations return results in pages, and a script that reads only the first page silently under-reports.
• Ignoring key expiry, so jobs fail overnight on the day a key lapses.
• Unreviewed bulk deletes. Destructive operations deserve an explicit confirmation step.

When to bring in a partner

Many IT teams have the skills to write a script but not the time to design, test and support an automation framework across a multi-site estate. That is where we help. Our managed services cover ongoing monitoring and support of Cisco networks, and our network as a service option suits organisations that prefer a subscription model to owning the lifecycle. If you are unsure of your starting position, our network audits establish what is deployed and how consistently it is configured before anything is automated. You can see how we approach large estates in our Meraki multi-site deployment case, or get in touch through our main site to discuss your own.

FAQ

Does the Meraki Dashboard have an API?

Yes. The Dashboard API is a RESTful interface for managing Meraki cloud-managed infrastructure, and it is enabled by default on all organisations. It covers networks, devices, wireless, switching, security appliances and more. The official developer hub documents every endpoint.

How do I find my Meraki API key?

You cannot retrieve an existing key, because the dashboard does not store it in plain text. Generate a new one from the API & Webhooks page or from My Profile while signed in with a non-SAML administrator account, and copy it immediately. If an old key is lost, revoke it and create a replacement.

Is there a limit on how many API calls I can make?

Yes. The limit is 10 requests per second per organisation, with a short burst allowance, and 100 requests per second per source IP address. Going over returns a 429 response, and the official Python library retries automatically. Action batches and webhooks reduce how many calls you need.

Is Python the only way to automate Meraki?

No. Any language that can make HTTPS requests can call the API, and Cisco also provides tooling for workflow automation. Python is the most common choice because the official library covers all current operations and manages retries and logging for you.

Sources

• How to Use the Cisco Meraki Dashboard API, Cisco Meraki Documentation
• Cisco Meraki Dashboard API, Cisco Meraki Documentation
• Getting Started with Meraki APIs, Meraki Developer Hub
• Meraki Dashboard API Python Library, Meraki Developer Hub
• meraki/dashboard-api-python, GitHub
• Rate Limit, Meraki Dashboard API v1
• Action batches overview, Meraki Dashboard API v1
• Push API, Meraki Dashboard API v1
• April-July 2026, Cisco Meraki Documentation

Recommended

• Meraki Wi‑Fi Design: 5 Field Tested Decisions for UK Enterprise Engineers
• Meraki Templates: When One Edit Beats API Cloning, and When It Doesn’t
• Meraki Access Control vs Cisco ISE
• Cisco Meraki Multi-Site Deployment