Automation, Integration, and API Usage
The Dashboard API
Meraki exposes a REST API over HTTPS at api.meraki.com/api/v1. Requests authenticate with an API key in the X-Cisco-Meraki-API-Key header. Keys are created by an administrator with API access and effectively carry that administrator's scope, so treat them as secrets, store them outside source control, and rotate them. Most endpoints require an organization ID, then a network ID, then a device serial in the path.
Rate limits and pagination
The API permits roughly five requests per second per organization. Exceeding it returns HTTP 429 with a Retry-After header; well-behaved scripts back off and retry instead of hammering the endpoint. Large collections are paginated - follow the Link header with rel="next" rather than assuming one response holds everything.
Integrations
- Webhooks / HTTP server: push alerts and events to external systems.
- Syslog and NetFlow: exported from MX appliances for SIEM and traffic analysis.
- Scanning API: streams observed Wi-Fi client data for location analytics.
- Camera and sensor APIs: expose telemetry from MV and MT devices.
Traps
Assuming legacy /api/v0 paths behave identically to v1; omitting the organization ID; assuming an API key is scoped to a single network (it is not); and ignoring pagination so a script silently processes only the first page.
Rule of thumb: wrap every integration in retry-with-backoff and cache organization and network IDs rather than re-fetching them on each call.
Worked example: a script enumerating 800 networks must page through results using the Link header and pace calls to stay under the per-organization rate limit.