MERAKI_API_KEY) when setup is complete.
This integration is built for Wi-Fi troubleshooting. Alongside the SSID and RF configuration, it captures the evidence you actually need when someone says “the wifi is broken”: which step of the connection failed (association, authentication, DHCP, DNS), per-client and per-AP latency and packet loss, channel utilization, rogue APs, mesh health, and the raw wireless event log.
⚠️ Required: a full-organization read-only admin
A Meraki API key inherits the permissions of the admin who generated it. ConfigView requires an admin with organization-wide access — read-only is enough, and is what we recommend. If you use a network-scoped admin instead:Create the key from a full organization admin. Read-only is sufficient for every script in this integration; ConfigView never writes to Meraki.
- Networks outside that admin’s scope are missing from the inventory entirely
Organizations,Assurance Alerts, and everybyDevice/byNetworkorg-wide collector return partial data or 403- The gaps are silent — they look like “we have no APs there” rather than an error
Step 1: Enable Dashboard API access
API access is off by default on a Meraki organization.- Sign in to the Meraki dashboard as a full organization admin
- Go to Organization → Settings
- Scroll to Dashboard API access
- Tick Enable access to the Cisco Meraki Dashboard API
- Click Save changes
Step 2: Generate the API key
- Still signed in as that admin, click your profile name (top right) → My profile
- Scroll to the API access section
- Click Generate new API key
- Copy the key immediately — it is a 40-character hex string and it is shown only once. Meraki will not display it again; you would have to revoke and regenerate.
Use a dedicated service admin. The key dies with the admin account that owns it. If you generate it from a person’s account and that person leaves, ingestion stops. Create a dedicated read-only org admin (for example configview-api@yourcompany.com), and generate the key from there.
Step 3: Add the secret to ConfigView
- Go to your ConfigView dashboard:
https://{companyname}.configview.com/admin/secret/ - Click Add Secret
- Secret name:
MERAKI_API_KEY - Secret value: Paste the 40-character key from Step 2
- Click Save
Step 4: Enable the Meraki scripts
- Go to:
https://{companyname}.configview.com/admin/cron/ - You should see meraki in the list of available apps
- Enable scripts. Parents must be enabled before children — ConfigView wires the dependencies automatically, but load order matters for first-run timing.
Foundation — enable these first
Everything else reads its context from these four tables.Wi-Fi troubleshooting — the ones that answer “why is it broken”
Wireless configuration — the “settings” half
Credentials are never stored
Two fields are deliberately dropped before anything is written to the database:pskonmeraki_wireless_ssids— the pre-shared key for PSK SSIDspassphraseonmeraki_wireless_ssid_identity_psks— iPSK passphrases
raw_json snapshot, and replaced with [redacted]. A ConfigView database dump can therefore never become a Wi-Fi passphrase dump. If you need to verify a PSK, use the Meraki dashboard.
Rate limits and scheduling
Meraki allows 10 requests per second per organization (burst +10, max 30 in 2 seconds) and 100 requests/second per source IP. That ceiling is shared with every other application hitting the same org, including Meraki’s own integrations. ConfigView paces evenly rather than bursting, defaulting to 5 requests/second — half the budget, leaving room for whatever else touches the org.429 responses carry a Retry-After header, which the collectors honour before retrying.
Cost scales with the size of the estate:
- Org-wide collectors — 1 call each, regardless of size
- Per-network collectors — 1 call per wireless network
- Per-AP collectors — 1 call per access point (2 scripts)
- Per-SSID collectors — 1 call per enabled SSID per network (11 scripts). Disabled SSID slots are skipped, which is usually a 5× saving
run_at, so history accumulates in the table even though each call only asks for a day.
Watch these three for row growth
Most tables here are small — tens to hundreds of rows per run. Three are not, and they are the ones to re-schedule or disable if the database grows faster than you want:
They are genuinely useful, so they are enabled by default — but on a daily schedule they are the bulk of your row growth. If Air Marshal is noisy for you, a weekly cadence still catches a persistent rogue.
Table reference
Every table also carries
org_id, org_name, a raw_json copy of the source object, and a run_at batch timestamp. Network-scoped tables add network_id and network_name; per-AP tables add serial and device_name; per-SSID tables add ssid_number and ssid_name.
Troubleshooting
Everything returns 404. Dashboard API access is not enabled on that organization. See Step 1 — it is a per-org switch, and enabling it in one org does nothing for the others. 401 on every call. The key was revoked, or the admin account that owns it was deactivated. Generate a new one and update the secret. Some networks are missing. The key belongs to a network-scoped admin. Regenerate it from a full organization admin. Wireless tables are empty butmeraki_devices has rows. Check product_types on meraki_networks — the wireless collectors only walk networks that include wireless. A network of MX/MS hardware with no MR access points is correctly skipped.
Per-SSID tables are empty. They depend on meraki_wireless_ssids and only walk SSIDs with enabled = 1. Run the SSIDs script first; if every SSID slot is disabled, there is genuinely nothing to fetch.
A single script logs 400/403/404 and continues. That is deliberate. Hotspot 2.0, Bluetooth, mesh, and the alternate management interface are not supported on every hardware generation or licence tier, so an unavailable endpoint is skipped with a log line rather than failing the whole run.
What you can’t ingest with this setup
- Per-client connectivity events (
GET /networks/{id}/wireless/clients/{clientId}/connectivityEvents). One call per client — infeasible to sweep for an estate of any size. The network-level Wireless Event Log covers the same ground in aggregate. Open a feature request if you need per-client depth for a named investigation. - Live tools (ping, cable test, throughput test, packet capture). These are on-demand actions against a device, not inventory — they mutate state and take seconds to minutes to return. Out of scope for a scheduled collector.
- Signal-quality, client-count, data-rate and usage history. Deliberately left out of this pass to keep row growth predictable. The Channel Utilization History script is included as the representative time-series. Request the others if you want them.
- Non-wireless product families. Switch ports, appliance/MX firewall rules, VPN status, camera and sensor data are all available in the Meraki API but out of scope here — this integration is scoped to Wi-Fi.
meraki_devicesstill inventories the full hardware estate.