Skip to main content
ConfigView pulls Meraki data through one Dashboard API key. The key belongs to a dashboard administrator and inherits that admin’s access — so the inventory follows the admin’s organization membership, not a per-network install. You will end up with 1 secret in ConfigView (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:
  • Networks outside that admin’s scope are missing from the inventory entirely
  • Organizations, Assurance Alerts, and every byDevice / byNetwork org-wide collector return partial data or 403
  • The gaps are silent — they look like “we have no APs there” rather than an error
Create the key from a full organization admin. Read-only is sufficient for every script in this integration; ConfigView never writes to Meraki.

Step 1: Enable Dashboard API access

API access is off by default on a Meraki organization.
  1. Sign in to the Meraki dashboard as a full organization admin
  2. Go to Organization → Settings
  3. Scroll to Dashboard API access
  4. Tick Enable access to the Cisco Meraki Dashboard API
  5. Click Save changes
Repeat this for every organization you want ConfigView to inventory. If the key can see an org but API access is switched off there, every call against it returns 404 — the health check flags this explicitly.

Step 2: Generate the API key

  1. Still signed in as that admin, click your profile name (top right) → My profile
  2. Scroll to the API access section
  3. Click Generate new API key
  4. 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

  1. Go to your ConfigView dashboard: https://{companyname}.configview.com/admin/secret/
  2. Click Add Secret
  3. Secret name: MERAKI_API_KEY
  4. Secret value: Paste the 40-character key from Step 2
  5. Click Save

Step 4: Enable the Meraki scripts

  1. Go to: https://{companyname}.configview.com/admin/cron/
  2. You should see meraki in the list of available apps
  3. 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:
  • psk on meraki_wireless_ssids — the pre-shared key for PSK SSIDs
  • passphrase on meraki_wireless_ssid_identity_psks — iPSK passphrases
They are stripped from the flattened columns and from the 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
For a site with 10 networks, 3 enabled SSIDs each, and 100 APs, a full sweep is roughly 800 calls — under three minutes. Daily is a sensible cadence for the configuration scripts; the health and event scripts are worth running more often, since they look back over a 24-hour window. The time-windowed scripts (failed connections, connection and latency stats, packet loss, Air Marshal, clients, channel utilization history) use a 24-hour lookback. Each run stores a fresh snapshot under its own 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 but meraki_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_devices still inventories the full hardware estate.