meraki-dashboard¶

Cisco Meraki Dashboard API v1: device availability, appliance uplinks and wireless clients of every organization the API key can read.

Validation status: simulator only. The package is built from the official documentation and OpenAPI description (v1.75.1, November 2026) and tested against a synthetic simulator in CI; it has not been run against a real Dashboard yet. Reports from users of real organizations are welcome.

Coverage¶

All metric jobs use organization-wide endpoints: one request per organization and job (one page per 1000 items), whatever the number of networks and devices.

Template	Endpoint	Default interval	Requests	Metrics
`meraki-organizations`	`GET /organizations`	1h	1 per account	`meraki_organization_api_enabled`, `meraki_organization_info`; inventory of the other jobs
`meraki-networks`	`GET /organizations/{organizationId}/networks`	1h	1 per organization (per 1000 items)	`meraki_network_info` (name, product types, time zone)
`meraki-devices`	`GET /organizations/{organizationId}/devices`	1h	1 per organization (per 1000 items)	`meraki_device_info` (name, model, firmware, product type, network)
`meraki-device-availabilities`	`GET /organizations/{organizationId}/devices/availabilities`	5m	1 per organization (per 1000 items)	`meraki_device_up` (online or alerting), `meraki_device_alerting`
`meraki-appliance-uplink-statuses`	`GET /organizations/{organizationId}/appliance/uplink/statuses`	5m	1 per organization (per 1000 items)	`meraki_appliance_uplink_active`, `meraki_appliance_uplink_up` (active or ready), per appliance and interface
`meraki-wireless-client-counts`	`GET /organizations/{organizationId}/wireless/clients/overview/byDevice`	5m	1 per organization (per 1000 items)	`meraki_wireless_device_clients` (clients connected now, per access point)

meraki-device-availabilities replaces devices/statuses, deprecated in October 2024 (deprecated operations); Meraki refreshes availabilities every 5 minutes, hence the default interval.
Measures carry organization_id, network_id and serial, and meraki_device_up and meraki_device_alerting also carry product_type (appliance, switch, wireless...); names, models and firmware are in the _info metrics. No client MAC address is collected.
Uplink IP addresses are not exposed.

Auth setup¶

Create an API key in the Dashboard (My profile > API access), ideally for a read-only administrator of the organizations to monitor, and give it to Tapyr as the apiKey secret. It is sent as Authorization: Bearer (authorization). For regional Dashboards, set the baseURL param (https://api.meraki.ca/api/v1, https://api.meraki.cn/api/v1, https://api.meraki.in/api/v1, https://api.gov-meraki.com/api/v1). The Dashboard may redirect a request to the shard of the organization (n123.meraki.com): the package allows redirects to the hosts of the Meraki domains (redirects.hosts), and Tapyr sends the key there too, each redirect being a request reserved in the budget.

Limits¶

Limit	Value	Source
`org-rate`	10 requests per second per organization, burst 20 (10 extra in the first second), on the requests carrying `organizationId`	Rate limit: "up to 10 requests per second per organization", "an extra 10 requests in the first second", shared across all API applications of the organization
`ip-rate`	100 requests per second per Tapyr instance	Same page: "up to 100 requests per second from each source IP address"
`ip-concurrency`	10 concurrent requests per Tapyr instance	Assumed: not documented officially, commonly reported by the community

429 responses carry Retry-After, honored by the budget engine. There is no daily quota: the per-organization rate is the constraint, and it is shared with the other applications using the API on the same organizations (the official SDK keeps 1 request per second for them). The example gives Tapyr half of it (budget: { share: 0.5, scaleRates: true }).

Quota maths with the defaults, one page per 1000 items: each organization costs 3 requests per 5 minutes (meraki-device-availabilities, meraki-appliance-uplink-statuses, meraki-wireless-client-counts), 36 an hour, plus 2 an hour (meraki-networks, meraki-devices); the account adds 1 an hour (meraki-organizations). An account with 2 organizations sends 77 requests an hour, far below the per-organization rate: the rate matters for bursts and for the share left to other applications. tapyr plan shows the projection.

Simulator¶

tapyr sim --provider meraki-dashboard --listen 127.0.0.1:8083

8083 is the port of the simulator under tapyr sim --all --listen-base 127.0.0.1:8081 (portOffset: 2). A synthetic Dashboard of 2 organizations, each with 4 networks of 10 devices (an MX appliance, three MS switches, six MR access points), generated from a seed. Statuses flap every 5 minutes, client counts and appliance uplinks move over simulated time. The simulator accepts the key sim-meraki-key, paginates with Link headers and enforces the limits above.

Scenario	Effect
`default`	No fault
`quota-tight`	No daily quota on Meraki: other applications spend most of the per-organization rate, a third of the organization requests get 429
`bad-day`	From 1h, slow responses (p50 600 ms, p99 4 s) for an hour; from 2h, 25% of the organization requests fail with 502 for 30 minutes; at 4h, a 10-minute outage

Dashboard¶

dashboards/meraki-dashboard.json (Grafana, Prometheus data source, organization and network variables): devices up and down, alerting, appliance uplinks and networks on a backup uplink, wireless clients, API requests and 429 (Tapyr self-metrics). The network names come from meraki_network_info: run the meraki-networks job for the network variable and the joins.

Known caveats¶

Simulator-validated only (see above).
meraki-wireless-client-counts needs access points; organizations without wireless return no item.
Networks bound to configuration templates are reported as returned by the API.