What is the Meraki Dashboard API rate limit per organization?

Correct: a — 10 req/s per org. That's the org-wide ceiling regardless of how many keys/apps you use. (The 100 req/s figure is the separate per-source-IP budget.) Exceed it and you get 429 + Retry-After.

You must push 350 firewall-rule changes across one org as fast as possible without tripping the rate limit. Best approach?

Correct: c. A batch caps at 100 actions, so one batch (b) can't hold 350. Split into 4 batches (≤100 each), staying under the 5-concurrent-batch limit. Individual POSTs (a) hit the 10 req/s wall; extra keys (d) share the same per-org pool.

Your action batch returns HTTP 200 but the changes never appear in the dashboard. The response shows "confirmed": false . What happened?

Correct: b. An unconfirmed batch is a draft. The 200 just means "batch object created", not "changes applied". Confirm it, then verify status.completed === true — never trust the HTTP code alone for batches.

A webhook receiver occasionally processes the SAME "config changed" alert twice, creating duplicate tickets. Given Meraki can trigger a workflow up to 10×/min, what is the correct design fix?

Correct: a. Webhook delivery is at-least-once — duplicates happen. The fix lives in YOUR handler: dedupe on the unique alertId (idempotency) so processing the same event twice is harmless. You can't disable resends (b), the rate limit (c) is unrelated, and HTTP (d) is rejected outright.

A teammate edits an SSID in the GUI that is managed by Terraform. The next CI run executes terraform plan . What is the expected output, and why does this matter?

Correct: c. Terraform compares declared state vs live state and flags the GUI edit as drift, proposing to restore the code's value on the next apply. That drift-detection is exactly why regulated estates adopt IaC — unauthorized changes can't quietly persist.

A vendor proposes hard-coding the Meraki API key directly in a public GitHub repo's main.tf "so the pipeline always has it." Evaluate this.

Correct: d. A Meraki key is full read/write to the entire org — committing it anywhere is a critical exposure (and secret scanners will find it). Inject via environment variable or a secrets vault, gitignore the secret file, and rotate. Keys are NOT read-only, and Terraform does not encrypt your source.

For a 24×7 NOC that must learn about a critical AP outage within seconds AND never miss one even during a receiver deploy, which design is strongest?

Correct: b. Webhooks give the seconds-fast push, but delivery is best-effort — a receiver outage can drop events. The robust pattern combines event-driven webhooks (HA receiver) with a lightweight periodic poll that catches anything missed. Polling alone (a) is too slow; one box (c) is a single point of failure; email (d) lacks structure and speed.

Cisco Meraki API & Automation — Dashboard API, Webhooks, Action Batches & Terraform

Q: Priya at HCL writes a monitoring script that loops over 300 networks, calling a per-device endpoint for each AP. It works in the lab but fails in production with 429 errors. What is the single best fix?

Correct: a. The fix is fewer, smarter calls plus proper backoff. Org-wide endpoints return everything in one call instead of 300 per-device calls. A second key (b) shares the same per-org pool — no help. More servers (c) just spreads the same per-org limit and risks the per-IP cap too. A longer timeout (d) doesn't change how many requests you fire.

Q: You need to read the client list from 80 networks AND push a new firewall rule to each. Which part can an action batch do?

Correct: b. Action batches are for create/update/delete (POST/PUT/DELETE) only — never GET. Push the 80 firewall rules in batches; read the client lists with a separate org-wide GET endpoint. Mixing the two mental models is the most common batch mistake.

Q: A new admin sets a webhook receiver URL to http://10.20.0.9:8080/hook (an internal box, plain HTTP). The dashboard rejects it. Why?

Correct: d. Meraki cloud can only POST to a public HTTPS endpoint with a valid certificate — it cannot reach 10.20.0.9 on your LAN. Expose the receiver through a public reverse proxy or cloud function with TLS. The webhook cap is 30/org (not 5), and webhooks span all product types, so the other options are wrong.

The wrong way — and why it haunts you at 2 AM

Rohan at TCS just inherited 140 retail-store networks. The CISO wants the same captive-portal SSID, the same content filter, and a new VLAN pushed to every store by Friday. Rohan opens the Meraki dashboard and starts clicking. Store 1, store 2, store 3... by store 19 his eyes glaze, and on store 23 he picks the wrong VLAN. Nobody catches it for three weeks — until a store can't reach the payment gateway.

That is the trap: manual change does not scale, and it has no audit trail. The whole point of Meraki being cloud-managed is that the cloud has an API. Anything you can click, you can script. And scripted change is repeatable, reviewable, and reversible.

Think of the dashboard as a restaurant where you walk up to the counter for every single order. The API is the food-delivery app — you place 140 identical orders at once from your couch, and the kitchen knows exactly what you asked for. No mishearing, no "I think you said large".

Rohan @ TCS — after the payment-gateway incident, his team mandated: "no production network change by hand." Every change now goes through a Python script or Terraform, reviewed in a pull request. Misconfigs dropped to near zero.

The whole game: your code → the cloud Dashboard API → every Meraki device. You never SSH a device.

① Dashboard API — one key, one header, every org

The Meraki Dashboard API is a plain REST API at https://api.meraki.com/api/v1. You authenticate with a single API key, passed in the X-Cisco-Meraki-API-Key header (or the standard Authorization: Bearer header on v1). Generate the key under My Profile → API access after an org admin first enables the API org-wide.

curl — list every network in an org

curl https://api.meraki.com/api/v1/organizations/123456/networks \
  -H "Authorization: Bearer 6bec40cf957de430a6f1f2baXXXXXXXXXXXXXXXX" \
  -H "Content-Type: application/json"

Expected output

[
  { "id": "N_24329156", "name": "Store-Delhi-01",  "productTypes": ["appliance","switch","wireless"] },
  { "id": "N_24329157", "name": "Store-Mumbai-02", "productTypes": ["appliance","switch","wireless"] },
  { "id": "N_24329158", "name": "Store-Pune-03",   "productTypes": ["appliance","switch","wireless"] }
]

Notice the golden rule the community repeats endlessly: prefer org-wide and network-wide calls over per-device calls. One call returns all 140 networks; looping 140 per-device calls burns your rate budget for nothing.

The 429 wall — the lesson everyone learns once

Here is the hard limit you will hit on your first big script: 10 requests per second, per organization — no matter how many keys or apps you point at it. There is a second ceiling too: each source IP gets a budget of 100 requests/second. Exceed either and the API answers 429 Too Many Requests with a Retry-After header telling you the seconds to wait.

▶ Watch a burst hit the 429 wall — and recover

Click Play. A greedy script floods the API, gets throttled, then backs off the right way.

① BURST Script fires 25 requests in one second → org budget is 10 req/s

Naive loop with no delay. The first ten land fine.

▼

② THROTTLE Requests 11–25 bounce back: HTTP 429 Too Many Requests

▼

③ READ HEADER Response carries Retry-After: 2 — wait 2 seconds, do not retry instantly

▼

④ BACKOFF Script sleeps, then retries with exponential backoff + jitter (2s, 4s, 8s…)

▼

⑤ SUCCESS Retried requests return 200 OK — the script now self-paces under 10 req/s

Press Play to step through a throttle-and-recover cycle. Each press of Next advances one stage.

The one-line fix: use the official SDK

The official meraki Python library has automatic retry + backoff built in. It reads Retry-After for you and re-sends. For most engineers, "just use the SDK" is the entire 429 strategy. Roll your own only when you need fine-grained async control.

Python — the SDK handles 429 for you

import meraki
d = meraki.DashboardAPI(api_key="6bec40cf...", maximum_retries=4)
# SDK auto-paces, auto-retries on 429, reads Retry-After
nets = d.organizations.getOrganizationNetworks("123456")
print(f"{len(nets)} networks in 10.20.0.0/16 estate")

Pause & Predict

You run TWO scripts from the same Jenkins box, each with its OWN API key, both hammering the same org. Do the two keys give you 20 req/s total?

No. The 10 req/s limit is per organization, not per key. Two keys against one org still share the same 10 req/s pool — and since both run from one Jenkins box, they also share the 100 req/s per-source-IP budget. Coordinate the scripts or serialize them; more keys does not buy more throughput.

Quick check · Q1 of 10

Priya at HCL writes a monitoring script that loops over 300 networks, calling a per-device endpoint for each AP. It works in the lab but fails in production with 429 errors. What is the single best fix?

a) Replace the per-device loop with org-wide/network-wide endpoints and use the official SDK's built-in retry/backoff b) Generate a second API key so she gets double the rate budget c) Run the script from 5 different servers simultaneously d) Increase the HTTP timeout to 120 seconds

Correct: a. The fix is fewer, smarter calls plus proper backoff. Org-wide endpoints return everything in one call instead of 300 per-device calls. A second key (b) shares the same per-org pool — no help. More servers (c) just spreads the same per-org limit and risks the per-IP cap too. A longer timeout (d) doesn't change how many requests you fire.

② Action Batches — 100 changes, one atomic call

Here is the killer feature for Rohan's 140-store rollout. An action batch bundles up to 100 individual config operations (POST / PUT / DELETE) into one request. The cloud processes them as a single unit — and crucially, you can mark a batch confirmed + synchronous so it is atomic: either every change applies, or none do.

That atomicity is the whole point. No more half-configured network where the VLAN got created but the firewall rule didn't. And because it is one HTTP request, it sidesteps the 10 req/s wall entirely for bulk change.

Same 100 changes. Left: a flaky loop that can leave the network half-configured. Right: one atomic batch.

The rules you must know

💯

Up to 100 actions

tap

A single batch holds up to 100 operations. Need more? Split into several batches — but only 5 can run concurrently per org.

⚛

Atomic

tap

A confirmed batch is all-or-nothing. One bad action and the whole batch fails — nothing is half-applied. Check status.errors.

✍

Writes only

tap

Batches do POST / PUT / DELETE — create/update/delete. They do NOT do GET. You can't read data with a batch.

⏯

Sync vs Async

tap

Synchronous = small batch, immediate result. Asynchronous = large batch queued; poll status.completed later.

curl — one atomic batch creating two VLANs on a network

curl https://api.meraki.com/api/v1/organizations/123456/actionBatches \
  -H "Authorization: Bearer 6bec40cf..." -H "Content-Type: application/json" \
  -d '{
    "confirmed": true,
    "synchronous": true,
    "actions": [
      { "resource": "/networks/N_24329156/appliance/vlans",
        "operation": "create",
        "body": { "id": "20", "name": "POS", "subnet": "10.20.20.0/24", "applianceIp": "10.20.20.1" } },
      { "resource": "/networks/N_24329156/appliance/vlans",
        "operation": "create",
        "body": { "id": "30", "name": "Guest", "subnet": "10.20.30.0/24", "applianceIp": "10.20.30.1" } }
    ] }'

Expected output

{
  "id": "543",
  "organizationId": "123456",
  "confirmed": true,
  "synchronous": true,
  "status": { "completed": true, "failed": false, "errors": [], "createdResources": [
      { "id": "20", "uri": "/networks/N_24329156/appliance/vlans/20" },
      { "id": "30", "uri": "/networks/N_24329156/appliance/vlans/30" } ] },
  "actions": [ { "resource": "...vlans", "operation": "create" }, { "...": "..." } ]
}

The symptom: "my batch silently did nothing"

What you see: the API returns 200, your script reports success, but the VLANs never appear in the dashboard. The cause: you left "confirmed": false. An unconfirmed batch is just a draft — it is created but never executed. You must either set confirmed: true at creation or PUT the batch to confirmed afterward. Always assert on status.completed === true, never on the HTTP code alone.

Aditya @ Infosys wrapped the 140-store rollout in one Python loop that built one action batch per store (≤100 actions each), throttled to 5 concurrent batches. The whole estate updated in under four minutes — and a typo in store 50's subnet failed only that store's batch, leaving the other 139 untouched. That is atomicity earning its keep.

Quick check · Q2 of 10

You need to read the client list from 80 networks AND push a new firewall rule to each. Which part can an action batch do?

a) Both — batches handle reads and writes equally b) Only the firewall-rule push (a write); the client-list read is a GET, which batches do not support — use a normal org-wide GET for that c) Only the read; batches are query-only d) Neither — batches are deprecated in API v1

Correct: b. Action batches are for create/update/delete (POST/PUT/DELETE) only — never GET. Push the 80 firewall rules in batches; read the client lists with a separate org-wide GET endpoint. Mixing the two mental models is the most common batch mistake.

③ Webhooks — stop polling, let Meraki call you

Reading the API on a timer (polling) is wasteful and slow — you only learn about an outage on the next poll. Webhooks flip it around. You register an HTTPS endpoint, and the moment an AP goes down or a config changes, Meraki POSTs a JSON payload to you within seconds.

Three hard rules from the docs you must respect: the URL must be HTTPS with a valid public certificate; an org may have at most 30 webhook receivers; and an event can trigger a given workflow up to 10 times per minute (so design idempotent handlers).

▶ Watch a webhook fire — AP goes down → Slack alert

An access point loses power at a Pune store. Trace how the alert reaches the NOC.

① EVENT AP 10.20.30.45 at Store-Pune-03 stops sending heartbeats → Meraki marks it down

▼

② BUILD PAYLOAD Cloud builds JSON: alertType: "ap_down", networkName, deviceSerial, occurredAt, sharedSecret

▼

③ POST Meraki sends HTTPS POST → your receiver at https://hooks.techclick.in/meraki

▼

④ VALIDATE Your app checks the sharedSecret matches the expected value — reject if not

▼

⑤ ACT App posts to Slack #noc-alerts + opens a ticket. NOC sees it in <10 seconds.

Watch where the sharedSecret is validated (stage 4) — skip it and anyone can spoof your alerts.

curl — register an HTTP server (webhook receiver) on a network

curl https://api.meraki.com/api/v1/networks/N_24329158/webhooks/httpServers \
  -H "Authorization: Bearer 6bec40cf..." -H "Content-Type: application/json" \
  -d '{
    "name": "NOC-Slack-Relay",
    "url": "https://hooks.techclick.in/meraki",
    "sharedSecret": "kali-noc-7f3a9c"
  }'

Expected output — and a sample alert payload Meraki later POSTs you

{ "id": "aHR0cHM6...", "name": "NOC-Slack-Relay",
  "url": "https://hooks.techclick.in/meraki" }

// later, when the AP drops, Meraki POSTs:
{ "version": "0.1", "sharedSecret": "kali-noc-7f3a9c",
  "organizationName": "Techclick-Retail", "networkName": "Store-Pune-03",
  "alertId": "0000", "alertType": "APs went down",
  "occurredAt": "2026-05-31T09:14:22Z",
  "deviceName": "AP-Pune-03-Lobby", "deviceSerial": "Q2XX-XXXX-XXXX" }

Pause & Predict

Your webhook receiver returns HTTP 500 for two minutes during a deploy. A genuine "AP down" alert fired during that window. Will you ever see it?

Risky. Meraki retries failed webhook deliveries a limited number of times, but it is not a durable message queue — a long receiver outage can drop alerts entirely. That is why production designs buffer webhooks behind a load-balanced, highly-available endpoint (and still keep a periodic API poll as a safety net for critical alerts). Never make a single fragile box your only path for outage alerts.

Pro tip: payload templates beat parsing raw JSON

Meraki supports custom payload templates using Liquid syntax. Instead of writing glue code to reshape the alert for Slack or PagerDuty, you define the exact JSON Meraki should send. There are pre-built templates for Slack, Teams, and PagerDuty — pick one, drop in your channel, done.

Quick check · Q3 of 10

A new admin sets a webhook receiver URL to http://10.20.0.9:8080/hook (an internal box, plain HTTP). The dashboard rejects it. Why?

a) The port 8080 is blocked by Meraki b) The org has hit its 5-webhook limit c) Webhooks only work for switches, not appliances d) Webhook receivers must be a publicly reachable HTTPS URL with a valid TLS certificate — plain HTTP and private RFC1918 addresses are not accepted

Correct: d. Meraki cloud can only POST to a public HTTPS endpoint with a valid certificate — it cannot reach 10.20.0.9 on your LAN. Expose the receiver through a public reverse proxy or cloud function with TLS. The webhook cap is 30/org (not 5), and webhooks span all product types, so the other options are wrong.

④ Terraform — your whole network as reviewable code

The final level. With the official Terraform provider for Meraki (cisco-open/meraki on the registry), you declare the desired state of your networks in .tf files. Terraform diffs that against reality and makes only the calls needed to converge. Your firewall rules now live in Git, get pull-request reviewed, and rebuild with one command.

Imagine writing a shopping list so precise that a robot rebuilds your exact kitchen from scratch — same fridge, same spices, same layout — just by reading the list. Terraform is that list for your network.

The IaC loop: write → plan (diff) → review in a PR → apply. Click the GUI later and the next plan flags the drift.

main.tf — declare a network and an SSID as code

terraform {
  required_providers {
    meraki = { source = "cisco-open/meraki", version = "~> 1.0" }
  }
}
provider "meraki" { api_key = var.meraki_api_key }

resource "meraki_network" "pune03" {
  organization_id = "123456"
  name            = "Store-Pune-03"
  product_types   = ["appliance", "switch", "wireless"]
}

resource "meraki_wireless_ssid" "guest" {
  network_id    = meraki_network.pune03.id
  number        = 1
  name          = "Techclick-Guest"
  enabled       = true
  auth_mode     = "psk"
  encryption_mode = "wpa"
  ip_assignment_mode = "NAT mode"
}

Expected output — terraform apply

Plan: 2 to add, 0 to change, 0 to destroy.
meraki_network.pune03: Creating...
meraki_network.pune03: Creation complete after 2s [id=N_24329158]
meraki_wireless_ssid.guest: Creating...
meraki_wireless_ssid.guest: Creation complete after 1s
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Pause & Predict

After Terraform creates the SSID, a colleague renames it in the GUI to "Store-Guest". You run terraform plan the next day. What does Terraform say?

It reports drift. The plan shows ~ name = "Store-Guest" -> "Techclick-Guest" — Terraform sees the live state no longer matches the code and proposes to change it back. This is the superpower of IaC: unauthorized GUI changes get caught and reverted on the next apply, so the code stays the single source of truth.

Security & the gotchas that bite in production

Automation hands enormous power to a single API key — and that key is the new crown jewel. Treat it like a root password.

The numbers worth memorising — for the exam and for the 2 AM page.

The symptom: your key shows up in a public repo

What you see: GitHub's secret scanner emails you, or worse, you find unexpected config changes you didn't make. The cause: a hard-coded key in main.tf or a script pushed to a public repo. A leaked Meraki key can read and rewrite your entire estate. Fix immediately: revoke the key in the dashboard (instant), generate a new one, move it to an environment variable or vault, and add the file to .gitignore. Never store secrets in source.

Patch the platform too, not just your scripts

Automation lives on top of the devices — keep them patched. In late 2024 Cisco disclosed AnyConnect VPN flaws on Meraki MX / Z-series (CVE-2024-20439 / CVE-2024-20440) that allowed session takeover and denial of service; exploitation began in 2025. Your slick Terraform pipeline doesn't matter if the underlying firmware is vulnerable. Use the API itself to audit firmware versions org-wide and flag laggards.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Meraki Developer Hub + community Q&A. For complex prod issues, paste your script error + endpoint into chat.techclick.in.

📖 Glossary — the terms in one place

Dashboard API: The REST API at api.meraki.com/api/v1 that does everything the GUI does, in code.
429 / Retry-After: The throttle response; the header tells you exactly how long to wait before retrying.
Action batch: One request bundling up to 100 write operations, applied atomically when confirmed.
Idempotent: Safe to run twice — the second run changes nothing. Essential for webhook handlers.
Webhook: An HTTPS callback Meraki sends you the instant an event fires, instead of you polling.
sharedSecret: A token you set on the receiver; validate it on every webhook to reject spoofed POSTs.
Terraform / IaC: Declarative config in Git; plan shows the diff, apply converges reality to code.
Drift: When the live network no longer matches the code — caught on the next terraform plan.

🧠 Self-explain (the fastest way to lock it in)

In one or two lines, explain to yourself: why does an action batch beat a loop of 100 separate API calls? Typing it from memory beats re-reading — research calls this the self-explanation effect.

👥 Teach a friend: message a teammate the difference between webhooks and polling in your own words. If you can teach it, you own it.

⏰ Want a spaced-recall nudge?

Drop your email and we'll send you 3 quick recall questions on this lesson in 3 days — the spacing effect makes it stick for months, not hours.

✓ Saved — we'll nudge you. (No spam, unsubscribe anytime.)

📚 Sources

Cisco Meraki Developer Hub — Dashboard API v1: Rate Limit (10 req/s per org, 100 req/s per source IP, 429 + Retry-After). developer.cisco.com/meraki
Cisco Meraki Developer Hub — Action Batches Overview & Create Organization Action Batch (≤100 actions, 5 concurrent, sync/async, atomic).
Cisco Meraki Developer Hub — Webhooks & Create Network Webhooks HTTP Server (payload fields, sharedSecret, HTTPS requirement).
Cisco Meraki Documentation — Platform Management → Workflows → Webhooks (30 receivers/org, 10 triggers/min). documentation.meraki.com
Terraform Registry & GitHub — cisco-open/terraform-provider-meraki (official IaC provider).
The Meraki Community — "Avoid hitting the API rate limit for high-scale" + "429 — Too many requests" practitioner threads.
Cisco Security Advisory — Meraki MX / Z-series AnyConnect VPN Session Takeover & DoS (CVE-2024-20439 / CVE-2024-20440). sec.cloudapps.cisco.com
Cisco Learning Network — ECMS 500-220 exam topics (Automation & API).

What's next?

You can now configure Meraki at scale. Next we go the other way — visibility. When something's broken, how do you SEE it? Packet capture from the dashboard, the event log, Insight performance scoring, and the live tools that turn "users say it's slow" into a root cause.

Next · Troubleshooting & Visibility → ← Recap Cloud Architecture

Meraki API & Automation — One Call to Configure 100 Networks

By the end, you'll be able to

Pick a topic — jump straight to it

Dashboard API

Action Batches

Webhooks

Terraform / IaC

The wrong way — and why it haunts you at 2 AM

① Dashboard API — one key, one header, every org

The 429 wall — the lesson everyone learns once

▶ Watch a burst hit the 429 wall — and recover

② Action Batches — 100 changes, one atomic call

The rules you must know

③ Webhooks — stop polling, let Meraki call you

▶ Watch a webhook fire — AP goes down → Slack alert

④ Terraform — your whole network as reviewable code

Security & the gotchas that bite in production

🤖 Ask the AI Tutor

📖 Glossary — the terms in one place

📝 Wrap-up — seven more

🧠 Self-explain (the fastest way to lock it in)

⏰ Want a spaced-recall nudge?

📚 Sources

What's next?