Current + Cisco Meraki integration

Cisco Meraki is where a lot of MSPs keep the network itself: the MX appliances at the edge of each site, the MS switches behind them, the MR access points on top, and the cameras and sensors alongside. Current's Meraki integration is a view-only feed into the SBR/QBR module and the company network panel. It reads what Meraki already knows and never writes back.

What the integration does

Current authenticates to Meraki with a dashboard API key, walks your organizations every six hours — one at a time, well under Meraki's published rate allowance — and stages the result as evidence for AI-assisted Strategic Business Reviews. Instead of exporting a device list the week of the review, the network numbers are already sitting on the company record when you open it.

What data flows

• Organizations — the Meraki partner roster, matched to your Current companies so every signal below lands on the right record, along with which Meraki cloud and country each one is hosted in.
• Networks — each site with its name, the product types it carries, and its time zone.
• Devices — appliances, switches, access points, cameras, sensors and the rest, each with its serial, product type, network, and current state.
• WAN uplinks — one row per WAN interface on every MX, MG, and Z-series device, with the interface, its state, the internet provider, the connection type, and cellular signal where a site is running on mobile backup.
• Licence posture — expiring and expired counts, or a single co-termination date, depending on the licensing model each organization runs.

The feed is one-way. Current does not reboot devices, cycle switch ports, move licences, create administrators, or change any configuration in Meraki. Those endpoints are not in the connector's code, so they cannot be reached by a bug either — and the setup guidance is to generate the key from a read-only Meraki administrator, which makes Meraki refuse writes on its own side too. Meraki stays the source of truth for management; Current uses the evidence.

Four device states, kept apart

Meraki reports a device as online, alerting, offline, or dormant, and Current keeps all four separate rather than flattening them into a yes-or-no. Alerting means the device is reachable and reporting a problem — that is the one a technician can act on this morning, and folding it into offline would overstate the outage. Dormant means a device deliberately out of service, usually a spare on a shelf, and counting that as offline would invent an outage that does not exist. A review that shows three devices offline should mean three devices are actually down.

Sites on mobile backup, and sites you cannot see

The uplink feed answers a question most reviews never get to: which sites are running on backup connectivity right now. A branch quietly living on 4G because its fibre dropped last Tuesday is billable, is a conversation worth having, and is otherwise invisible until somebody complains about speed. Current reads the uplink state on every MX, MG, and Z-series device and shows the carrier alongside it. Where a site has no such device — an office built from switches and access points alone — Current shows no WAN state rather than reporting the site as up, because it has nothing to base that on.

Licences read as Meraki reports them

Meraki answers the licence question in two mutually exclusive shapes. An organization on co-termination licensing gets one expiry date covering the whole estate and no expiring counts; an organization on per-device licensing gets the counts, carried with the day thresholds Meraki itself used, and no single date. A third, newer subscription model is not mirrored yet. Current reads which model each organization runs and shows only what that organization actually reports — so a co-termination account is never told that zero licences are expiring, because the number it would be reading was never answered.

Both ways of running an MSP estate

Meraki supports two topologies and calls them the Tailored Service model — one organization per partner — and the Standard Service model, where a small number of organizations each hold one network per partner. Meraki recommends the second for service providers. Current supports both: the connection maps by organization by default and can map by network instead, and after the first sync the card reports what it found so the choice is confirmed rather than guessed. Nothing switches on its own, because the two are mappings of different things and changing between them re-keys every pairing.

Network gear is counted beside endpoints, never inside them

A Meraki switch is not a managed workstation. It has no patch state and no antivirus state, and adding it to an endpoint count would drag a partner's device-compliance percentage down for reasons that have nothing to do with patching. Current keeps the two counts adjacent and separate, so the network story and the endpoint story each stay readable.

Where the data appears

• In Strategic Business Reviews, in the fleet and network chapter alongside your other network feeds such as UniFi and Fortinet.
• On the company record, in the network panel: device counts by product type, the four device states kept apart, and how many sites have their WAN up.
• In dashboard network metrics, including device counts and site connectivity.
• In the renewal list, where expiring and expired licence counts sit beside the dates they came from.

Why it matters

The network section is where most business reviews go quiet, because the numbers live in the dashboard and the review lives somewhere else. An MSP running Meraki for a partner like Northwind Traders can open the account and see how many devices are deployed and what state each is in, which of the four branches has its WAN up, that the Contoso Fiber link at one site failed over to a Fabrikam Mobile connection eleven days ago, and that two licences expire inside ninety days — without anyone assembling an export first. The review becomes a conversation about what the data says rather than about where the data came from.