Cisco Meraki Integration

Connect Cisco Meraki to Atlas AVD and keep each organization's switches, access points, security appliances, cameras and sensors documented in Atlas Vault.

Before you begin

  • An Enterprise plan or above. The Integrations hub is locked below Enterprise
  • The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
  • A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
  • A Meraki Dashboard API key, from an organization that has Dashboard API access turned on. Read-only organization access is enough
  • To sync into Vault: a Vault admin and at least one asset template (the Network Device template is a good fit)

What you can do

  • Document every device in a Meraki organization as an Atlas Vault asset, with no manual data entry.
  • Map each Meraki organization to the customer company it belongs to.
  • Keep the documentation current: every hour Atlas adds new devices, updates changed details and archives devices Meraki no longer reports.
  • Search Vault for a device by name or by any mapped detail, such as model, serial, MAC address or IP.
  • Ask Atlas Advisor about documented equipment, for example "Which Meraki switches does Contoso have?"

Step 1: Create an API key in Meraki

In the Meraki dashboard, go to Organization → Settings → Dashboard API access, make sure API access is enabled, then create a key from your profile's API keys and copy it. Note which dashboard you sign in to: an organization lives in exactly one dashboard region, and a key only works against its own region.

  • Global: dashboard.meraki.com
  • Meraki for Government: dashboard.gov-meraki.com
  • Canada: dashboard.meraki.ca
  • India: dashboard.meraki.in
  • China: dashboard.meraki.cn

Step 2: Connect in Atlas

Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The key is stored encrypted and is never shown again. Meraki is cloud-hosted, so there is no server address to enter.

  1. Select the tenant in the tenant picker.
  2. Go to Administration → Integrations and click Connect on the Cisco Meraki card.
  3. Pick the Dashboard region your organization is in.
  4. Paste the API Key and click Connect. Atlas reads the organizations the key can see before saving anything; if Meraki rejects the key, nothing is stored.

Step 3: Map each organization to a company

Add one sync per organization. An organization can be mapped only once in a tenant. When your customers live in separate Atlas tenants, connect Meraki in each tenant; a tenant only ever sees its own Meraki connection, syncs and assets.

  1. Open Atlas Vault → Assets → RMM & PSA sync and click Add sync.
  2. Source: Cisco Meraki.
  3. Device type: pick a Meraki organization.
  4. Template: the asset template each device becomes, for example Network Device.
  5. Company: the customer this organization belongs to.
  6. Field mappings: map each Meraki field you want onto a template field, for example model, serial, firmware, lan_ip and network.
  7. Leave Sync automatically every hour on, click Save Changes, then click Run now to document the organization straight away.

What gets documented

Each device is matched by its serial number, so renaming it or moving it between networks updates the same asset. These are the Meraki fields you can map:

  • Hardware: name, serial, model, MAC address, product type (switch, wireless, appliance, camera, sensor and so on), firmware, tags, notes and the device's dashboard link.
  • Addressing: LAN IP, WAN 1 and WAN 2 IPs, and public IP.
  • Health: status (online, offline, alerting or dormant) and when the device last reported.
  • Placement: street address, latitude and longitude, network name and organization.
  • Per-model details: type detail: followed by the detail's name to map one, for example detail:Port count on a switch.

If Meraki's device status or network list can't be read on a run, the hardware is still documented without those fields, and the values already in Vault are left as they are.

Your own documentation is kept

Atlas only fills the fields you map. Notes, attachments, custom fields and anything else you add in Vault are yours and are never touched. If you edit a mapped field by hand, Atlas keeps your value; if Meraki later reports something different, the field is flagged under Drift to review so you can choose which to keep. A device Meraki stops reporting is archived, not deleted, and comes back automatically if it returns. Atlas archives a device only after a complete read of the organization, so an outage or a rejected key never empties your documentation. Archiving needs the sync to be the only Meraki sync using its template: when several Meraki syncs share one template, Atlas leaves missing devices in place for you to archive by hand.

Ask Atlas Advisor

Atlas Advisor answers questions from the documented assets, read-only and limited to what you can see in Vault. For example: "Which Meraki switches does Contoso have?", "What's the LAN IP of the main office appliance?" or "Which Meraki devices haven't synced recently?".

What the integration does not do

  • It is read-only. It never changes a device, network or setting in the Meraki dashboard.
  • It does not document connected clients.
  • It does not show Meraki alerts, and it does not create tickets.
  • It does not keep a change history of Meraki devices; the asset shows the latest values.
  • It does not fill in mappings for you: you choose which Meraki fields go where.
  • It syncs every hour or when you click Run now; the interval cannot be changed.
  • It does not archive missing devices automatically when several Meraki syncs share one asset template.
  • It connects one Meraki API key (and one dashboard region) per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new key.

GCC High tenants

On a tenant or deployment in Azure Government (GCC High), calls to Cisco Meraki are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from Cisco Meraki stay empty. The operator who runs your Atlas deployment can approve Cisco Meraki as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.

Disconnecting

Click Disconnect on the card and confirm. Atlas deletes its stored copy of the API key and pauses every Atlas Vault sync from Meraki. The documented assets stay in Vault; turn the syncs back on after you reconnect. Nothing changes in Meraki. Revoke the key in the Meraki dashboard too if you no longer need it.

Troubleshooting

  • Cisco Meraki rejected the supplied credentials: the key is wrong or revoked, the organization has Dashboard API access turned off, or the key belongs to a different dashboard region. Check the region, then connect again.
  • Cisco Meraki is temporarily rate limiting requests — try again shortly: wait a minute and try again. Scheduled syncs retry with backoff on their own.
  • Could not connect to Cisco Meraki — verify the server URL and credentials: Meraki could not be reached. Try again shortly.
  • The Device type list is empty: the key can't see any organizations. Check the key's organization access in the Meraki dashboard.
  • Some devices have no status or network name: Meraki's status or network list could not be read on that run. They are filled in on a later sync.
  • A sync reports the integration is not configured: Meraki was disconnected. Connect it again, then turn the sync back on.

Next steps