What the Meraki Dashboard API can and cannot back up

BOTTOM LINE The public Dashboard API exposes a large part of Meraki configuration, especially for MX, MR and MS. It does not provide a universal, lossless export of every dashboard setting, secret, entitlement or operational state. Reliable recovery therefore depends on coverage mapping, a separate secrets process and carefully engineered restore logic.

Cisco describes the Dashboard API as a REST interface for managing and monitoring Meraki networks at scale. This guide focuses on what can be captured and written back through that public interface, and on the operational work required to turn API data into a usable recovery capability. View the current API overview.

Disclosure. OnBackup provides Meraki configuration backup services. This document is intended as a neutral technical reference. Tools that use the public Dashboard API share its endpoint, permission and rate-limit constraints, although their coverage, secret handling, validation and restore engineering can differ materially.

The short version

NO GENERAL SNAPSHOT RESTORE Meraki Dashboard does not provide a general, versioned configuration snapshot with a one-click whole-estate restore. The Organization Change Log is an audit record of individual changes, not a complete dependency-aware recovery point.

The current Change Log endpoint exposes old and new values for recorded changes and has a maximum lookback of 365 days. That is useful for investigation, but it is not equivalent to a coherent snapshot of every object and relationship. Cisco Change Log API.

Coverage at a glance

The labels below describe practical round-trip potential, not a guarantee that every dashboard control is represented. Coverage varies by product, model, firmware, licence, feature availability, region/base URI, administrator permissions and API release status.

Coverage summary based on the public Dashboard API v1.71.0. Early Access or product-specific APIs may add or change coverage.

What backs up well

MX security appliances

MX has broad API coverage. A well-designed backup can capture and replay many common configuration domains, including L3 and L7 firewall rules, port forwarding, one-to-one and one-to-many NAT, content filtering, intrusion protection and malware settings, traffic shaping, uplink selection, site-to-site VPN, third-party VPN peers, VLAN and DHCP settings, static routes and warm-spare configuration.

Important correction: the current third-party VPN peer response schema includes the shared secret. It should therefore be treated as highly sensitive backup data, not assumed to be write-only. Confirm actual behaviour with the permissions and firmware used in the target estate. Third-party VPN peers API.

MR wireless

MR configuration is also broadly exposed: SSID settings, authentication mode, VLAN tagging, per-SSID L3/L7 firewall rules, traffic shaping, RF profiles, Bluetooth settings and identity PSKs can be handled through relevant endpoints. Splash themes and assets now have dedicated API operations, so older statements that uploaded splash assets are wholly unavailable are no longer accurate.

Secret handling is endpoint-specific. The SSID response includes a PSK field, but read-only administrators receive a masked value. RADIUS server host and port data are returned without the shared-secret field. Identity PSK passphrases are available through the relevant iPSK endpoints when the caller has sufficient access. See wireless SSIDs, identity PSKs and splash assets.

MS switches

MS APIs cover a wide range of configuration, including port mode and VLAN settings, voice VLAN, PoE, schedules and tags; access policies; ACLs and QoS; spanning-tree settings; Layer 3 interfaces and routing; DHCP policy; and link aggregation.

Important correction: logical switch stacks can be created through the API by supplying a name and member serial numbers, and stack membership can be managed through stack endpoints. A restore still cannot reproduce physical cabling or make unavailable hardware operational. RADIUS secrets used by switch access policies are accepted on write but omitted from the GET response. See create switch stack and switch access policy.

Network-wide and organisation settings

Relevant APIs expose alert settings, syslog servers, traffic-analysis settings, firmware windows, group policies, administrators and permissions, policy objects and groups, configuration templates and bindings. SNMP settings are readable, but the current organisation SNMP response does not return SNMPv3 authentication or privacy passphrases.

These areas are recoverable only when dependencies are respected. If a deleted group policy or policy object is recreated, the new server-side ID can differ from the captured ID. References elsewhere in the backup must be translated before dependent objects are written.

Areas that need special treatment

Configuration templates

Templates can be listed, created, configured and bound through the public API. The difficult part is safely reproducing inheritance: determining which values come from the template, preserving permitted local overrides, sequencing template and network writes, and controlling the effect of binding or re-binding.

Cisco's bind operation also documents auto-bind constraints for switch profiles. A production recovery process should test template restoration in a non-production organisation or disposable network before relying on it. Bind network API.

Meraki Systems Manager

Systems Manager is not completely absent from the API. Device inventory, tags and installed device profiles can be read, and selected actions such as installing apps are available. However, the current public API does not offer a comprehensive round-trip authoring surface for every MDM profile, app catalogue item and enrolment setting. Treat SM backup as limited and define the supported object set explicitly.

MV cameras and footage

Camera quality and retention settings can be read and updated through dedicated endpoints, alongside other per-camera settings and analytics information. Camera video is a separate data-protection problem. Cisco provides video-link and clip operations, including creation of short clips on supported cameras and firmware, but those operations are not a general continuous or bulk footage archive.

Relevant references: quality and retention, clip operation and Video Clip API guidance.

MG cellular gateways

The API exposes selected MG settings, including configuration in LAN, port, firewall and uplink areas where supported. Coverage should be assessed endpoint by endpoint against the models and firmware actually deployed; a generic 'good' label is not a substitute for an inventory-specific coverage test.

What a configuration backup cannot recover by itself

1. Write-only or omitted secret material. RADIUS shared secrets and SNMPv3 authentication/privacy passphrases are not present in the relevant read responses. They must be supplied from a controlled secrets store or re-entered during recovery.

2. Personal authentication artefacts. Administrator API keys and 2FA enrolment are personal security state, not ordinary organisation configuration. SAML IdP metadata and certificate fingerprints may be readable, but private signing-key material is not a recoverable dashboard setting.

3. Physical and live operational state. Cabling, power, device availability, physical stack readiness, WAN reachability and the condition of replacement hardware cannot be restored from JSON configuration.

4. Entitlements and lifecycle state. Device claiming, organisation inventory and subscription binding have dedicated API workflows. They should be documented in the recovery runbook, but they are not the same as replaying a configuration backup.

5. Camera recordings. Configuration capture can protect camera settings. It does not automatically preserve the video retained on cameras or create an evidential footage archive.

6. Arbitrary historical firmware. Firmware versions and schedules are visible, and a rollback endpoint exists, but rollback is a controlled firmware workflow with eligibility and time-window constraints. A configuration backup is not an archive of every historic firmware image.

SECURITY NOTE Because some current endpoints can return PSKs or other sensitive values, configuration backups must be encrypted, access-controlled, logged and retained under an explicit policy. Do not assume that all exported JSON is non-secret simply because it came from a configuration API.

Why restore is harder than capture

7. Discover scope and capability. Identify the organisation, network products, templates, licences, firmware and permissions. Record which endpoints are supported and which captured values are masked or omitted.

8. Build a dependency graph. Create parent objects before children: for example, policy objects and group policies before rules that reference them, VLANs before dependent DHCP settings, and templates before network binding.

9. Translate identifiers. Maintain a map from captured IDs to newly created IDs. Apply it to every reference. Group-policy and policy-object IDs are common examples; MX VLAN IDs are caller-supplied and should not be used as a generic remapping example.

10. Plan safe write behaviour. Validate the target, preview differences, support domain-level restores and make operations idempotent where practical. Record each accepted, rejected and skipped write so an interrupted run can resume safely.

11. Respect call budgets. Cisco currently publishes 10 requests per second per organisation, with an additional burst allowance of 10 in the first second (maximum 30 over two seconds), plus 100 requests per second per source IP. Handle HTTP 429 responses using Retry-After and backoff.

12. Verify the result. Read the restored configuration back, compare it with the intended state, test critical traffic paths and capture unresolved secrets or manual actions. A successful HTTP response is not the same as a successful service recovery.

Cisco recommends action batches for suitable bulk configuration operations and the official Python library includes automatic retry/backoff handling. Action-batch availability does not remove the need to verify endpoint support, dependencies and final state. Rate-limit guidance | Action batches.

Evaluation checklist

13. Does the backup inventory its own coverage by endpoint, product and firmware instead of using a single percentage?

14. Which fields are masked, omitted or permission-dependent, and where will the missing secrets be stored?

15. Can it restore one network or one configuration domain and show a preview diff before writing?

16. How does it rebuild dependencies and translate newly created object IDs?

17. How does it handle template inheritance, local overrides and re-binding risk?

18. What happens after a 429 response, a permission failure or an interruption halfway through a restore?

19. Does it read the target back and produce a clear verification report, including manual follow-up actions?

20. How are backups encrypted, access-controlled, retained and tested?

Frequently asked questions

Does Meraki Dashboard have built-in configuration backup and restore?

It does not provide a general versioned snapshot and one-click whole-estate restore. The Change Log and firmware rollback features are useful controls, but neither is a complete dependency-aware configuration recovery system.

Can the API back up RADIUS shared secrets?

Not from the relevant read endpoints reviewed for this guide. RADIUS hosts and ports are returned, while the shared-secret fields needed on write are omitted. Plan to supply them from a separate secrets store.

Are all PSKs write-only?

No. The current wireless SSID schema includes a PSK field, although read-only administrators receive a masked value, and the third-party VPN peer schema includes its shared secret. Treat returned secrets as sensitive and test with the exact role and estate used in production.

Can configuration be restored to different hardware or another organisation?

Sometimes, where the target supports the same product features and the caller has the required permissions and licences. Hardware-specific state, entitlement workflows, template relationships and server-generated IDs still need explicit handling. It should never be presented as a universal lift-and-shift guarantee.

Can switch stacks be restored?

Logical stack creation and membership are API-manageable. Physical stacking cables, hardware condition and operational readiness remain manual dependencies.

Can camera footage be backed up through this process?

Not as part of ordinary configuration backup. Clip and video-link APIs support specific retrieval use cases, but they are not a continuous, bulk archive of all retained footage.

Can firmware be rolled back?

Yes, in supported circumstances through Meraki's firmware rollback workflow and API. That corrects the claim that downgrade is never possible, but it does not mean any historic version can be restored at any time.

Are free scripts sufficient?

They can be useful for capture and smaller estates. Assess restore ordering, identifier translation, secrets, templates, rate limiting, retention, monitoring and read-back verification before treating a script as a recovery capability.

Verification basis and official sources

This guide was checked against Cisco's public documentation available on 13 July 2026. The API changes frequently; re-check the current endpoint schema before publishing hard guarantees or designing a recovery runbook.

21. Dashboard API overview — current public API version and scope

22. API call budgets and rate limits — organisation/IP limits, 429 handling and action-batch guidance

23. Organisation configuration changes — Change Log fields and 365-day maximum lookback

24. Wireless SSIDs — SSID configuration, PSK permission behaviour and omitted RADIUS secrets

25. Wireless identity PSKs — readable iPSK passphrases and policy references

26. Switch access policy — readable access-policy fields

27. Update switch access policy — write-side RADIUS secret fields

28. Third-party VPN peers — current response schema includes the shared secret

29. Splash assets and themes — API support for retrieving splash assets

30. Bind a network to a template — template binding and auto-bind constraints

31. Create a switch stack — logical stack creation from switch serials

32. Systems Manager device profiles — installed profile visibility

33. Camera quality and retention — read/write camera configuration

34. MV Video Clip API — clip scope and support requirements

35. Network device claiming — inventory/lifecycle workflow

36. Firmware rollback API — network rollback operation

37. Managing firmware upgrades — rollback eligibility and operational constraints

38. Dashboard API authorisation — API authentication and permission model

39. SAML IdP configuration — readable SAML IdP metadata and certificate fingerprint

PUBLICATION NOTE Coverage and field behaviour can change between API versions. Preserve the verification date and version when publishing this document, and schedule a periodic content review.

About this guide

OnBackup is a Meraki configuration backup service built for MSPs. Corrections and current field observations are welcome: contact OnBackup.

OnBackup is an independent service and is not affiliated with or endorsed by Cisco. Cisco, Meraki and related marks are trademarks of Cisco and/or its affiliates.