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 covers the whole Meraki estate. 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. Organization governance. Who can administer the dashboard and whether they have 2FA, what the SSO configuration asserts, what you are licensed for and when it expires, which hardware you own but have not deployed, when each device goes end-of-support, the dashboard password policy, and a full log of who called the API from where. These are org-wide and cost one call each regardless of estate size. Security appliance (MX). The LAN and WAN sides of every MX: VLANs and DHCP scopes, the full firewall rule set in evaluation order, port forwarding and NAT, content filtering, intrusion detection and malware protection state, site-to-site and third-party VPN, traffic shaping and SD-WAN uplink preference, warm-spare pairing, and live WAN uplink status with public IP per circuit. Switching (MS). Every physical port with its VLAN, PoE, STP guard and access policy, plus live status — link speed, duplex, errors, PoE draw and client count per port. Alongside it the network-wide switching config: STP bridge priority, ACLs, QoS and DSCP mapping, storm control, rogue-DHCP policy and ARP inspection, multicast and OSPF. Network-wide. The things that belong to a site rather than a product family: local Meraki accounts used for Client VPN and splash, group policies, where alerts route and what actually fired, the four telemetry export paths, LLDP/CDP topology, and the appliance and switch event logs. Camera, sensor, cellular gateway and Systems Manager. Footage retention and camera access roles, sensor readings and alert thresholds, cellular uplink signal and eSIM inventory, and MDM devices, users, profiles and trusted access. See the verification warning below before relying on these.

⚠️ 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/integrations/
  2. Under Credentials, enter each value and click the save icon on its row:
  3. Secret name: MERAKI_API_KEY
  4. Secret value: Paste the 40-character key from Step 2

Step 4: Choose which parts of Meraki to collect

Meraki is split into six folders in /admin/integrations/, because a folder is what you tick — and there is no point creating switch tables for an organization that owns no switches.
The core Cisco Meraki folder is required. Every other folder’s collectors depend on meraki/meraki_get_organizations.py, meraki_get_networks.py and meraki_get_devices.py for their organization, network and device context.If the core folder is not enabled, those dependencies cannot resolve and the dependent collectors refuse to run rather than publishing results built on a stale snapshot. You will see Dependency meraki/... not found - is the 'meraki' folder enabled? in the activity log.
MERAKI_API_KEY is one secret shared by all six folders — you enter it once, not per folder.

About the Logs folder

Cisco Meraki – Logs holds the high-volume append-only streams: the appliance and switch event logs, and the API request log. They are in their own folder and off by default deliberately — ConfigView is an asset inventory, not a log ingestion product, and these tables grow without bound in a way the configuration tables do not. Enable them only if you have a specific question they answer, and expect to manage their growth. Note that the admin audit log is not in this folderConfiguration Change Log lives in the core folder, because “who changed what” is governance rather than telemetry.

Load order

Parents must run before children. ConfigView wires the dependencies automatically, but load order still 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

Organization governance — access, licensing, and audit

These are all org-wide: one API call each, no matter how large the estate. They depend only on Organizations.

Security appliance (MX) — the network edge

Network-scoped collectors walk every network whose product_types includes appliance; the per-MX ones walk devices where product_type = 'appliance'.

Switching (MS) — ports and the switching fabric

Network-scoped collectors walk networks whose product_types includes switch; the per-switch ones walk devices where product_type = 'switch'.

Network-wide — the things that belong to a site, not a product

These walk every network in the organization, regardless of hardware. The two event-log collectors are the exception: they are filtered to networks that have the matching product type.

Camera, sensor, cellular gateway and Systems Manager

These are the least-verified collectors in the integration. Every other family on this page was validated field-by-field against a live organization. No organization available during development owned MV, MT, MG or Systems Manager hardware, so for most of these the column names come from Cisco’s published OpenAPI spec — which has been wrong twice already on this integration.Four are confirmed, because they answer at the organization level even with no hardware present: Camera Permission Scopes, Cellular eSIM Service Providers, Systems Manager APNs Certificate, and the wrapper shape of Cellular eSIM Inventory.If you own this hardware, treat your first run as the verification step and check for columns that come back unexpectedly NULL. tools/meraki_null_audit.py in the master-scripts repo does exactly that.
Every collector below is gated on product_types / product_type, so on an organization without the hardware it makes zero API calls and inserts zero rows.

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
  • secret on meraki_appliance_vpn_third_party_peers — the IPsec pre-shared key for third-party VPN peers. Only secret_is_set is recorded.
  • psk on meraki_camera_wireless_profiles — the pre-shared key for camera wireless profiles. Only psk_is_set is recorded.
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.
  • Live tools and on-demand actions remain out of scope, as above. Beyond those, every read endpoint Cisco exposes on the Dashboard API is now collected.