Your fleet is making millions of API calls a day just to check if routers are online. Webhooks push that information to you the moment something changes.
Browse the API reference1,000 routers × 1 call/min × 60 min × 24 hrs
1.44M calls/day
Delayed detection. Wasted API calls. Rate-limit pressure.
Only fires when a router actually goes online or offline.
~50 calls/day
Instant notification. Zero wasted calls. Real-time awareness.
Webhooks aren't just about reducing API calls. They're the event layer that enables everything from simple alerting to fully autonomous network management.
Trigger workflows the moment something happens — not minutes later when a polling loop catches it. Router offline? Auto-create a ServiceNow ticket, notify on-call, and spin up a backup link before anyone checks a dashboard.
AI agents need real-time signals to act on. Webhooks feed events directly into AI systems that diagnose, decide, and remediate autonomously. That loop starts with a webhook.
Webhooks connect NCM to everything else in your stack — ITSM, SIEM, observability platforms, Slack, Teams, PagerDuty, and custom dashboards.
Stream network events into your data pipeline. Build live dashboards that update the instant a device changes state, not on a 60-second delay.
The shift: Polling asks “what happened?” Webhooks tell you “something is happening.” That difference is what separates reactive network management from proactive, AI-driven operations. Every automation workflow, every AI agent, every real-time dashboard starts with an event — and webhooks are how NCM delivers those events to your systems.
NCM webhooks are built on the alert system. You create an HTTP destination (your server), configure alert rules for the events you care about, and NCM pushes a notification to your URL when those events fire.
When an event fires, NCM sends an HTTP POST to your URL with the alert payload. Your server validates the request using the shared secret and processes the event.
Register your server URL with NCM. The secret verifies that incoming webhooks are actually from NCM. Or do it in the NCM UI: Alerts & Logs → Push Destinations → Add Destination. Save the destination_config_id from the response — you'll need it in Step 3.
Verify NCM can reach your server before configuring alert rules. A 201 Created response with an empty body means your destination is reachable and the secret is valid.
Configure which events trigger notifications and where they're sent. Or in the NCM UI: Alerts & Logs → Alert Rules → Add Rule → select alert types → add your HTTP destination.
When an alert fires, NCM sends an HTTP POST to your destination URL. Verify the request using the shared secret.
These are the event categories you can subscribe to. Each category contains multiple specific alert types and links to its full definitions, thresholds, and example messages.
| Category | What it covers | Common use case |
|---|---|---|
| General | Device online/offline, device registered, device unregistered | Fleet uptime monitoring — replaces polling |
| Health | Cellular health score changes, connection quality degradation | Proactive network quality monitoring |
| Modem | Signal strength thresholds, carrier changes, SIM events | Cellular connectivity monitoring |
| Configuration | Config push, config rejected, config drift | Change management, compliance |
| Security | Unauthorized access attempts, certificate events | Security monitoring, SIEM integration |
| Carrier Data | Pooled data usage thresholds, per-router usage percentage | Cost management |
| Carrier Selection | CSI test started/passed/failed/error | Connectivity resilience monitoring |
| Ethernet | Ethernet link up/down, speed changes | WAN monitoring |
| Hardware | Hardware failures, critical operating temperature | Device health monitoring |
| Battery | Battery health, over current/temp/voltage, low power, power off, maintenance cycles, backup power, wall power restored | E100/E400/X20 battery monitoring |
| LAN | LAN interface events | Local network monitoring |
| Location Services | Geofence enter/exit, GPS events | Fleet tracking, geofencing |
| Cellular Access Points | AP reboot, NTP sync issues, radio status, AP/core connection state, high temp, SAS grant events, IPsec tunnel failure | Private cellular monitoring |
| Mobility Gateway | Mobility gateway events | Mobile network monitoring |
| NetCloud OS Apps | SDK app events | App lifecycle monitoring |
| Subscriptions | License expiration, subscription changes | License management |
| Wi-Fi as WAN | Wi-Fi WAN connection events | Alternative WAN monitoring |
| Service Gateway | Service gateway events | Gateway monitoring |
| AI Insights | AI-generated network recommendations | Proactive optimization |
See the complete Alerting and Reporting documentation for details.
This is the #1 reason customers poll. Replace it with a single alert rule.
Instead of polling net_device_signal_samples, set a threshold alert.
Track configuration changes across your fleet without polling configuration_managers.
Know immediately when a device switches from primary to backup WAN.
Auto-create an incident when a device goes offline.
Post to a channel on any alert.
Webhooks are configured through these v2 API endpoints:
Authentication for these endpoints uses the v2 API key headers (X-CP-API-ID, X-CP-API-KEY, X-ECM-API-ID, X-ECM-API-KEY).
Firewall configuration: if your webhook destination is behind a firewall, allowlist NCM's outbound IP addresses (see the alert_push_destinations documentation for the current list).