If you manage 500+ network devices across multiple customer sites, you know the drill: check Peplink InControl for the cellular routers, switch to Cradlepoint NetCloud for the backup links, open Teltonika RMS for the IoT gateways, then log into three different dashboards just to figure out which customer has a WAN failover issue. Vendor-specific monitoring tools work fine for single-vendor deployments. But MSPs managing multi-vendor fleets spend hours context-switching between dashboards, manually correlating alerts, and building reports by copy-pasting from four different systems.
Network device management software purpose-built for MSPs eliminates this fragmentation. Instead of juggling vendor portals, you get a single platform that normalizes device telemetry across vendors, automates ops workflows, and generates the unified reports your customers actually want to see during quarterly business reviews.
This guide breaks down what it takes to build (or evaluate) a multi-vendor MSP fleet management platform --- from the vendor API landscape and adapter architecture to real-time monitoring, ops automation, pricing models, and development costs.
The MSP Fleet Management Pain Is Real
The average MSP manages somewhere between 200 and 2,000 network devices deployed across 50 to 500 customer sites. These are not homogeneous fleets. A typical multi-vendor deployment spans three to five vendor dashboards, each with its own authentication, alerting logic, reporting format, and API quirks.
Here is what that looks like in practice:
No unified alerting. Each vendor has its own alert system with different thresholds, formats, and notification channels. Peplink alerts hit one inbox, Cradlepoint alerts hit another, and Teltonika alerts might go to a Slack channel. When a customer site goes down, your NOC team has to manually correlate events across systems to understand whether it is a single-device failure or a site-wide outage.
Reporting is a nightmare. Customers want unified network health reports. They want uptime percentages, bandwidth usage trends, and incident summaries in a single document. What they get instead is screenshots from four dashboards stitched together in a Word doc. This is not scalable, and it is embarrassing when you are trying to justify your managed services contract during a QBR.
No workflow automation. The path from "device offline" to "tech dispatched" to "issue resolved" is still manual for most MSPs. Someone sees an alert, creates a ticket, assigns a tech, and follows up. There is no automated escalation based on customer SLA tiers, no suppression during maintenance windows, and no automatic correlation between related alerts.
Billing reconciliation is manual. How many active devices does each customer have this month? For most MSPs, answering that question means logging into each vendor dashboard, counting devices per organization, and reconciling against the billing system. At 500+ devices, this takes hours every month and is prone to errors that cost you revenue.
Context-switching kills productivity. Every time a NOC technician switches between vendor dashboards, they lose context. Different UIs, different terminology, different navigation patterns. Studies on task-switching suggest a 20-40% productivity loss from frequent context changes. Multiply that across a team of five NOC operators and you are bleeding real money.
The Vendor Ecosystem: APIs, Capabilities, and Limitations
Before you can build a unified MSP monitoring platform, you need to understand what each vendor gives you to work with. The good news is that every major network equipment vendor now offers a REST API. The bad news is that they are all different.
Peplink (InControl 2)
Peplink's InControl 2 platform provides REST API access in two versions: v1 and v2. Authentication uses OAuth2 client credentials, which is straightforward to implement. The API exposes fleet management, device status, WAN metrics, SpeedFusion tunnel health, and SD-WAN configuration.
InControl is strong on SD-WAN orchestration and has been growing rapidly in 5G cellular router deployments. The platform handles basic fleet management well, but it lacks the deep ops workflow capabilities MSPs need --- things like customer-scoped alerting rules, SLA-based escalation, and automated reporting.
The API documentation is decent, though some endpoints have undocumented quirks around pagination and rate limiting that you will discover during integration.
Cradlepoint (NetCloud)
Cradlepoint's NetCloud Manager is the central management platform for their enterprise edge networking portfolio. The REST API provides access to device inventory, status, cellular signal metrics, and configuration management.
Cradlepoint is well-established in enterprise branch networking and retail deployments. However, third-party API access has historically been more restricted than Peplink's. NetCloud Manager handles basic fleet operations, but the API rate limits and data granularity can be limiting for real-time monitoring use cases.
Teltonika (RMS)
Teltonika Networks' Remote Management System (RMS) offers a REST API for managing their industrial IoT gateway portfolio. The API covers device management, status monitoring, and basic diagnostics.
Teltonika has been gaining traction with MSPs due to their competitive price point for industrial and IoT gateway deployments. The RMS platform is capable but less mature than InControl or NetCloud when it comes to API feature depth.
Cisco Meraki (Dashboard API)
Meraki's Dashboard API is arguably the best-documented API in the networking space. It provides comprehensive access to device inventory, network health, client analytics, and configuration management.
The trade-off is Meraki's licensing model --- it is expensive, and the per-device licensing cost can be prohibitive for large fleet deployments. Meraki is most common in SMB environments and tends to be one of several vendors in an MSP's portfolio rather than the sole platform.
Digi International
Digi provides REST API access for their industrial and enterprise IoT router portfolio. They are less common in traditional MSP deployments but appear in industrial IoT and field service scenarios.
The Common Problem
Each vendor API has different authentication mechanisms (OAuth2, API keys, session tokens), different rate limits (some documented, some discovered the hard way), different data models (status fields, metric names, interface types), different webhook support (some robust, some nonexistent), and wildly different documentation quality.
This is exactly why a unified platform needs an abstraction layer --- not a brute-force approach of hitting each vendor's API and dumping the results into a single UI.
Multi-Vendor Architecture: The Adapter Pattern
The core architectural challenge in building network device management software for multi-vendor environments is normalization. You need a vendor-agnostic device model that captures the common attributes every MSP cares about, while preserving vendor-specific metadata for deep drill-downs.
The Vendor-Agnostic Device Model
Design a unified device schema with common fields that apply across all vendors: name, model, serial number, online/offline status, last seen timestamp, GPS coordinates, customer assignment, site assignment, and interface list. Then include a flexible JSON metadata field for vendor-specific data --- things like Peplink's SpeedFusion tunnel IDs, Cradlepoint's modem IMEI, or Teltonika's IO pin states.
This separation matters. Your alerting engine, reporting engine, and customer portal all operate against the common model. Your vendor-specific diagnostic tools can reach into the metadata when needed.
Adapter Interface
Each vendor gets an adapter module that implements a standard interface:
VendorAdapter:
authenticate(credentials) -> session
list_devices(session) -> [Device]
get_device_status(session, device_id) -> DeviceStatus
get_metrics(session, device_id, time_range) -> [MetricPoint]
get_wan_quality(session, device_id) -> WANQualityReport
get_interfaces(session, device_id) -> [InterfaceStatus]
execute_diagnostic(session, device_id, command) -> DiagnosticResult
The Peplink adapter knows how to authenticate with InControl's OAuth2 flow, map InControl device objects into your unified Device model, and translate InControl's signal quality fields (RSRP, RSRQ, SINR) into your standard metric format. The Cradlepoint adapter does the same for NetCloud. The Teltonika adapter does the same for RMS.
Why This Matters
When you need to add support for a new vendor --- say a customer brings in a fleet of Digi routers --- you write a new adapter. You do not touch the alerting engine, the reporting engine, the customer portal, or the dashboard. The new adapter maps Digi's API responses into your existing device model, and everything downstream works automatically.
This is the adapter pattern, and it is the single most important architectural decision in a multi-vendor monitoring platform. Get this wrong and every new vendor becomes a six-month project. Get it right and it is two to four weeks.
Data Normalization Layer
Raw vendor metrics come in different units, different scales, and different naming conventions. One vendor reports signal strength in dBm, another in percentage. One reports bandwidth in bits per second, another in kilobits.
The normalization layer sits between the vendor adapters and the metrics storage. It converts everything into standard units: Mbps for bandwidth, dBm for signal strength, milliseconds for latency, percentage for utilization. This ensures that dashboards, alerts, and reports are consistent regardless of which vendor the device belongs to.
For a deeper look at how multi-tenant data isolation works in platforms like this, see our guide on multi-tenant SaaS architecture for B2B platforms.
Beyond Monitoring: Ops Workflows That Actually Save Time
Here is the thing most people miss: the real value of a unified MSP fleet management platform is not monitoring. InControl already monitors Peplink devices. NetCloud already monitors Cradlepoint devices. You do not need another dashboard that shows green and red dots.
The value is in ops workflows --- the automated processes that connect monitoring data to business actions.
Smart Alerting With Context
Basic alerting is "device offline, send email." Smart alerting factors in context:
- SLA-aware escalation. Device offline for more than 5 minutes at a customer with a 15-minute SLA? High priority, page the on-call engineer. Same device offline at a customer with a 4-hour SLA? Standard priority, create a ticket.
- Maintenance window suppression. Device offline during a scheduled maintenance window? Suppress the alert entirely. No noise, no false alarms.
- Correlated alerting. Five devices at the same site go offline simultaneously? That is probably an upstream power or ISP issue, not five individual device failures. Generate one site-level alert, not five device-level alerts.
- Customer-specific rules. Some customers want alerts on cellular signal degradation. Others only care about complete outages. Configurable per customer, per device type, per metric threshold.
WAN Quality Reporting
MSPs selling managed SD-WAN services need to prove the value they are delivering. WAN quality reports show latency, jitter, and packet loss trends over time --- per WAN interface, per device, per customer, per site.
These reports are not just for customers. They are for your own capacity planning. When you can see that a customer's primary WAN link has been degrading over the past 90 days, you can proactively recommend an upgrade before it becomes an outage.
Bandwidth Analytics and Anomaly Detection
Usage trending shows you which customers are approaching their bandwidth caps, which sites have unexpected traffic spikes, and which devices are consuming disproportionate bandwidth.
Anomaly detection adds a security layer: a sudden 10x spike in upload traffic from a device that normally pushes 50 Mbps could indicate a compromised device or a data exfiltration attempt. Automatic flagging of anomalies gives your NOC team early warning.
Remote Diagnostics
When a technician gets an alert, their first instinct is to log into the vendor dashboard and run a ping test, traceroute, or speed test from the device. In a unified platform, these diagnostics are available directly --- no context-switching to InControl or NetCloud.
The adapter pattern makes this possible. Each vendor adapter implements a execute_diagnostic method that translates a standard command (ping, traceroute, speed test) into the vendor-specific API call and returns a normalized result.
Customer-Facing Portal
This is a differentiator that most MSPs do not offer: a white-labeled status page per customer showing their device fleet health, uptime history, and active incidents. Customers can log in and see their network status without calling your help desk.
For MSPs, this is a value-add service that justifies higher per-device pricing. For customers, it is transparency that builds trust. We wrote about the design and implementation of customer-facing portals in our ISP customer portal development guide --- the same principles apply to MSP fleet dashboards.
Automated Reporting
Scheduled weekly or monthly reports per customer, delivered automatically: uptime percentage, bandwidth usage, incident count, SLA compliance, and device inventory changes. No more manual report assembly. No more last-minute scrambles before QBRs.
Billing Integration
Device count per customer, auto-reconciled monthly. When a customer adds or removes devices, the billing system sees the change automatically. For MSPs using per-device pricing, this eliminates the monthly manual reconciliation and ensures you are capturing revenue for every active device.
Real-Time Architecture for Fleet Monitoring at Scale
Building a fleet monitoring platform that handles thousands of devices requires thoughtful architecture decisions around polling, real-time updates, metrics storage, and scale planning.
Background Polling Workers
The primary data collection mechanism is scheduled background workers that poll vendor APIs on a regular interval. The polling frequency depends on the customer's SLA tier:
- Standard tier: Poll every 5 minutes. Good enough for most monitoring use cases.
- Premium tier: Poll every 1-2 minutes. Required for customers with aggressive SLA targets.
- Critical tier: Poll every 30-60 seconds. Reserved for healthcare, financial, or emergency services customers where uptime is mission-critical.
Each worker is scoped to a vendor adapter and a batch of devices. Workers run in parallel, and each maintains its own rate limit tracking to avoid hitting vendor API throttles.
Rate Limit Management
This is one of the most underestimated challenges in multi-vendor monitoring. Peplink InControl, for example, has API rate limits that are not always clearly documented. If you naively poll 500 devices every minute, you will get rate-limited and miss data.
The solution is intelligent polling with exponential backoff. Track your API call budget per vendor, per time window. When you approach the limit, increase polling intervals for low-priority devices first. Implement circuit breakers so that a rate-limited vendor adapter does not block workers for other vendors.
Real-Time Dashboard Updates
Nobody wants to refresh a dashboard to see if a device came back online. WebSocket connections (or server-sent events in simpler implementations) push status changes to the browser in real time.
The architecture is straightforward: when a polling worker detects a status change (device went offline, signal degraded, bandwidth spike), it publishes an event to a PubSub system. The dashboard server subscribes to relevant events and pushes them to connected browser sessions.
Event-Driven Alert Engine
The same PubSub events that update the dashboard also feed the alert engine. When a device goes offline:
- Polling worker detects the change and publishes a
device.status.changedevent. - Alert engine evaluates the event against the customer's alerting rules.
- If the event matches a rule (e.g., offline duration exceeds SLA threshold), the engine generates an alert.
- The alert is routed through the configured notification channel (email, Slack, PagerDuty, webhook).
- If the device recovers, a
device.status.recoveredevent auto-resolves the alert.
Metrics Storage at Scale
Fleet monitoring generates a lot of time-series data. Consider the math for a mid-size deployment:
2,000 devices x 12 polls per hour x 5 metrics per poll = 120,000 data points per hour.
That is roughly 2.88 million data points per day, or 86 million per month. Standard relational databases can handle this, but you need to plan for it.
Two proven approaches:
- TimescaleDB --- a PostgreSQL extension purpose-built for time-series data. You get the familiarity of SQL with automatic partitioning, compression, and retention policies.
- Time-partitioned PostgreSQL --- if you want to avoid extensions, partition your metrics tables by time (daily or weekly partitions) with automated partition creation and old partition archival.
Either way, design for this volume from day one. Retrofitting time-series storage into a platform that started with a single metrics table is painful and expensive.
Multi-Tenancy
An MSP platform is inherently multi-tenant. Each MSP customer's data must be isolated, and each MSP using the platform needs their own tenant with their own customers underneath.
This creates a three-tier tenancy model: Platform -> MSP -> MSP Customer -> Devices. Row-level security in PostgreSQL or application-level tenant scoping both work, but the choice affects everything from query performance to data export capabilities. Our multi-tenant SaaS architecture guide covers these trade-offs in detail.
Pricing Model for MSP Fleet Management Software
If you are building a network device management platform for the MSP market, pricing determines your unit economics. Here is what we see working in this space.
Per-Device Pricing
The standard model is per-device, per-month pricing. This aligns with how MSPs bill their own customers and makes the value proposition simple: "This platform costs $X per device and saves your NOC team Y hours per month."
Typical price points:
- $5-8/device/month for basic monitoring and alerting
- $10-12/device/month for monitoring + customer portal + automated reporting
- $12-15/device/month for enterprise features (white-label, SSO, SLA management, API access)
Minimum Commitment
Most platforms require a minimum of 50-100 devices to prevent onboarding costs from eating into margins. At $10/device, that puts the entry point at $500-1,000/month --- reasonable for an MSP managing even a modest fleet.
Tier Structure
| Feature | Basic | Pro | Enterprise |
|---|---|---|---|
| Multi-vendor monitoring | Yes | Yes | Yes |
| Unified alerting | Yes | Yes | Yes |
| Customer portal | No | Yes | Yes |
| Automated reporting | No | Yes | Yes |
| API access | No | Yes | Yes |
| White-label | No | No | Yes |
| SSO/SAML | No | No | Yes |
| SLA management | No | No | Yes |
| Dedicated support | No | No | Yes |
Path to $1M ARR
The math on per-device SaaS for MSPs is straightforward:
100 MSP customers x 100 devices each x $10/device/month = $1.2M ARR.
That is achievable with a focused go-to-market targeting mid-size MSPs in the 100-500 device range. The key is reducing onboarding friction and time-to-value so that MSPs see ROI within the first 30 days.
Free Trial
A 14-day free trial with a 25-device cap lets MSPs evaluate the platform against their actual fleet without commitment. The cap is high enough to be useful (you can onboard one or two customer sites) but low enough that serious evaluators will convert to paid.
Development Cost: What It Takes to Build
Whether you are building a fleet management platform as a product or evaluating the cost of building internal tooling, here are realistic budget ranges based on our experience building multi-vendor monitoring systems.
MVP: Single Vendor + Core Monitoring
Budget: $80,000 - $150,000 | Timeline: 4-6 months
The MVP covers a single vendor integration (typically whichever vendor represents the largest share of your fleet), a unified dashboard, basic alerting, and device inventory management. This is enough to validate the concept with early adopter MSPs or to replace internal spreadsheet-based tracking.
Scope includes:
- Single vendor adapter (e.g., Peplink InControl)
- Device inventory with status monitoring
- Configurable alerting rules
- Basic dashboard with real-time status
- User management and role-based access
Multi-Vendor Platform
Budget: $150,000 - $300,000 | Timeline: 8-12 months
This is the full platform: multiple vendor adapters, customer-scoped multi-tenancy, automated reporting, customer-facing portal, and billing integration. This is what you need to sell as a commercial product.
Additional scope beyond MVP:
- Two to four additional vendor adapters
- Multi-tenant architecture (MSP -> Customer -> Devices)
- Customer-facing status portal
- Automated scheduled reports
- WAN quality analytics and trending
- Remote diagnostics
- Billing integration / device count reconciliation
- API for third-party integrations
Ongoing Maintenance
Budget: $30,000 - $60,000 per year
This is the line item most people underestimate. Vendor API changes are the single biggest maintenance cost. When Peplink releases InControl API v3, or Cradlepoint changes their authentication flow, or Teltonika deprecates an RMS endpoint, your adapters need to be updated.
Budget for:
- Vendor API version updates and deprecation handling
- New vendor adapter development (expect one to two per year)
- Security patches and dependency updates
- Performance optimization as device counts grow
- Feature additions based on customer feedback
For a framework on evaluating whether to build this internally or engage a development partner, see our guide on how to choose a software development partner.
Frequently Asked Questions
What is MSP fleet management software?
MSP fleet management software is a platform that allows managed service providers to monitor, manage, and automate operations across all of their customers' network devices from a single interface. Instead of logging into separate vendor dashboards for Peplink, Cradlepoint, Teltonika, and Meraki devices, MSPs use a unified platform that normalizes device data across vendors and provides consolidated alerting, reporting, and workflow automation. The core value proposition is reducing NOC operational overhead while improving service quality through automated SLA management and customer-facing transparency.
How do you monitor multi-vendor network devices in a single dashboard?
The technical approach is the adapter pattern. You build a vendor-agnostic device model that captures common attributes (status, signal strength, bandwidth, location) and implement a separate adapter module for each vendor's API. Each adapter handles vendor-specific authentication, API calls, and data mapping. A normalization layer converts vendor-specific metrics into standard units so that dashboards, alerts, and reports are consistent regardless of the underlying hardware vendor. Background polling workers call each vendor's API on a scheduled interval, and status changes are pushed to the dashboard in real time via WebSockets.
How much does network device management software cost?
If you are buying an existing platform, expect to pay $5-15 per device per month depending on the feature tier, with minimum commitments of 50-100 devices. If you are building a custom platform, an MVP with single-vendor support and core monitoring runs $80,000-$150,000 over 4-6 months. A full multi-vendor platform with customer portal, automated reporting, and billing integration runs $150,000-$300,000 over 8-12 months, with $30,000-$60,000 per year in ongoing maintenance costs primarily driven by vendor API changes.
Build Your MSP Fleet Management Platform
The MSP market is moving toward managed network services that go beyond basic connectivity. Customers expect proactive monitoring, transparent reporting, and rapid incident response. Delivering on those expectations with a patchwork of vendor dashboards and manual processes does not scale.
A purpose-built multi-vendor monitoring and ops automation platform is the infrastructure that lets MSPs deliver enterprise-grade managed network services without enterprise-grade headcount.
Building a network device management platform? Of Ash and Fire develops multi-vendor monitoring and ops automation tools for MSPs --- from Peplink to Cradlepoint to Teltonika. We have built polling architectures, vendor adapter systems, and real-time fleet dashboards that handle thousands of devices. Schedule a free consultation to discuss your fleet management requirements.