The Meraki API: automate and integrate your Meraki network

What the Meraki Dashboard API is

Meraki describes the dashboard API as a modern, RESTful API that uses HTTPS requests and JSON. Every request goes to a URL that names the resource, for example an organisation, a network or a device, and standard verbs read or change it:

• GET reads a resource or a list of resources.
• POST creates something new, such as a network or an administrator.
• PUT updates an existing resource.
• DELETE removes one.

In most of the world, including the UK, every request starts with the base address api.meraki.com/api/v1; organisations hosted in a few country-specific regions use their own base address. The same API reaches every product family in the Meraki dashboard: wireless, switching, security appliances, cellular gateways and cameras.

Meraki lists the jobs customers use it for: adding organisations, networks, administrators, devices, VLANs and SSIDs; provisioning many new sites with a script; onboarding and off-boarding teleworker devices; and building custom dashboards for store managers, field engineers and other roles. The sections below cover the ones we are asked about most.

Getting API access: keys and permissions

Meraki says the dashboard API is enabled by default on all organisations, so there is nothing to switch on. Access comes in two forms:

To create an API key, an administrator (not a SAML single sign-on account) signs in and goes to Organization > Configure > API & Webhooks, opens the API keys and access tab and selects Generate API key, or uses the same option on the My Profile page. Points worth knowing:

• The key is shown once. Meraki does not store keys in plain text, so copy it into a password manager or secrets store straight away. If it is lost, revoke it and generate a new one.
• Two keys per person. Each user can hold two keys, which makes rotation easy: create the new key, move your scripts, revoke the old one.
• Keys reach every organisation the admin can. A key belongs to the person, not the organisation, so it has that admin's permissions in every organisation they administer. Use a dedicated read-only administrator for reporting scripts.
• Single sign-on accounts cannot create keys. Administrators who sign in through SAML need a separate local admin account for API work.
• Keys do not expire, even when the admin's password does, so remove keys when people leave.

Each request carries the key in an Authorization header as a Bearer token. Meraki's documentation says a missing or incorrect key returns a 404 rather than a 403, so the API does not reveal what exists.

Meraki device provisioning: claiming and adding devices at scale

Device provisioning through the API follows the same steps as the dashboard, without the clicking:

1. Claim into the organisation. One call claims a list of order numbers, device serials and licence keys into the organisation inventory. Claiming by order adds every device and licence in that order.
2. Create the networks. Create a network for each site, named and tagged consistently, or clone the settings of an existing network.
3. Bind to a template. Bind each new network to the configuration template for that type of site, so it inherits SSIDs, VLANs, firewall rules and SD-WAN settings in one step.
4. Claim devices into networks. Add serials to their networks, and set names, addresses and tags so alerts and maps make sense.
5. Apply site specifics. Set the few values that differ per site, such as subnets or a static WAN address.

Two features keep large jobs within the limits. Action batches bundle many create, update and delete operations into one transaction, run synchronously or in the background. Configuration templates let one change reach every bound network, rather than one call per site. Meraki applies a stricter limit to the claim calls: each can be used up to ten times in any five-minute window, so claim in batches rather than device by device.

The API also exposes Meraki's network move feature for moving a network between organisations, with a simulate option that runs the validation checks without moving anything; our Meraki disaster recovery guide covers where that helps.

Building custom integrations: webhooks and SDKs

Most integrations combine two directions of traffic:

• Pull, with the REST API. Your system asks Meraki for data or sends it changes.
• Push, with webhooks. Meraki sends alerts to your system as events happen: a device going offline, a settings change, a usage threshold and many more. You add an HTTP server under Network-wide > Alerts, with its HTTPS address, an optional shared secret your receiver can check and an optional payload template that shapes the message for the receiving system. Meraki requires a valid certificate from a trusted certificate authority on the receiver; self-signed certificates are not supported.

For code, Meraki publishes an official Meraki Python library (install it with pip install meraki). It covers every API operation, retries automatically when the rate limit is hit, handles pagination, logs every request, and can simulate changes so you can preview a script before it touches the network. Any language that can make HTTPS requests can use the API directly.

Good practice for lasting integrations:

• Use webhooks for events and the REST API for state, rather than polling for changes.
• Give each integration its own administrator account and key, with the narrowest role that works, so access can be audited and revoked separately.
• Keep keys out of source code: Meraki's own examples read the key from an environment variable.
• Build in a dry run before any bulk change, and log what each run changed.

Automated reporting across your Meraki estate

Reporting is where the API saves the most time, because the data that takes hours to gather by hand across many networks or organisations is a handful of calls away. Typical automated reports:

• Inventory: every device with its serial, model, MAC address, network, firmware and tags. The inventory call can also filter devices by end-of-sale and end-of-support status, which feeds lifecycle planning (see Meraki end of life).
• Licensing: licence status and expiry dates across organisations, ahead of renewals.
• Health and availability: device status, uplink status and VPN status for a daily or weekly summary.
• Change history: the organisation change log, showing who changed what and when, collected into one place for audit.
• Usage: clients and application usage per site, for capacity planning.

Reports can be scheduled to land as files, in a spreadsheet, in a ticketing system or on a custom dashboard. The dashboard's own API analytics tab shows how many calls each application is making, which helps spot a script that is using more of the shared budget than it should.

Configuration compliance checks

Meraki configuration compliance means checking that every network still matches the standard you designed. Because the API can read any setting, a script can compare each network against a baseline and report the differences:

• SSIDs using the expected security mode and VLANs.
• Firewall rules, content filtering and intrusion prevention settings on every MX.
• Firmware versions and upgrade windows.
• Administrators and their roles, including accounts that should have been removed.
• Alert recipients and webhook destinations.

Configuration templates keep most of this consistent in the first place, so the check mainly catches local overrides and networks that were not bound to a template. Pair it with the change log, which records the old and new value of every change, and you have both the current position and the history behind it. We can help you define the baseline and build the checks.

Feeding Meraki inventory into a CMDB

A configuration management database (CMDB) is only useful if it is accurate, and network kit is easy to lose track of. A Meraki CMDB feed uses the inventory and device calls to send each device's serial, model, MAC address, network, address, firmware and tags into the CMDB on a schedule, so new devices appear and removed devices are flagged without anyone re-keying them.

Tips for a clean feed:

• Use the device serial as the unique key; Meraki serials do not change when a device moves network.
• Map Meraki networks to sites and tags to roles or owners in the CMDB.
• Add end-of-sale and end-of-support dates from the inventory data, so the CMDB shows replacement dates.
• Treat Meraki identifiers as text, not numbers; Meraki's guidance is that IDs are opaque strings.

Rate limits and good practice

Meraki's published limits are:

When a limit is hit the API returns HTTP 429 with a Retry-After header saying how long to wait. Good practice from Meraki's guidance:

1. Handle 429 responses by waiting for the Retry-After time (the Python library does this for you).
2. Use action batches and templates instead of many single calls.
3. Do not poll for things that rarely change, such as the list of networks. Meraki suggests reading the configuration changes call to see what has changed instead.
4. Use webhooks to receive events rather than polling for them.
5. Remember the budget is shared: a reporting job and a provisioning script running at once draw on the same 10 calls per second.

How Forever Systems helps

Forever Systems is a Cisco Partner. We can help you save time with Meraki automation: set up API access safely, build provisioning scripts for new sites, schedule reports across your Meraki estate, define configuration compliance checks and connect Meraki inventory and alerts to the systems your team already uses. The scope is agreed at quote.

If you are still choosing hardware, browse the Meraki shop and add what you need to your basket. To talk about automation, contact us.