Stop polling.
Get notified instantly.

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.

Polling every 60 seconds

1,000 routers × 1 call/min × 60 min × 24 hrs

1.44M calls/day

Delayed detection. Wasted API calls. Rate limit pressure.

Webhook on state change

Only fires when a router actually goes online or offline

~50 calls/day

Instant notification. Zero wasted calls. Real-time awareness.

Why webhooks are the foundation for modern network operations

Webhooks aren't just about reducing API calls. They're the event layer that enables everything from simple alerting to fully autonomous network management.

Event-driven automation

Trigger workflows the moment something happens — not minutes later when a polling loop catches it. Router goes offline? Auto-create a ServiceNow ticket, notify the on-call engineer, and spin up a backup link — all before anyone checks a dashboard.

AIOps and agentic AI

AI agents need real-time signals to act on. Webhooks feed events directly into AI systems that can diagnose, decide, and remediate autonomously. “Signal dropped below threshold → AI agent checks nearby tower load → recommends carrier switch → executes if approved.” That loop starts with a webhook.

Integration fabric

Webhooks connect NCM to everything else in your stack — ITSM, SIEM, observability platforms, Slack, Teams, PagerDuty, custom dashboards. Every webhook destination is a bridge between your network infrastructure and your operational tools.

Real-time observability

Stream network events into your data pipeline. Build live dashboards that update the instant a device changes state, not on a 60-second delay. Feed events into time-series databases for trend analysis and anomaly detection.

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.

How webhooks work

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.

  1. Create a destination — tell NCM where to send notifications (your URL + a shared secret)
  2. Test the destination — verify NCM can reach your server
  3. Create an alert rule — pick which events trigger notifications
  4. Link the destination — attach your HTTP destination to the alert rule

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.

Setup guide

Step 1

Create a webhook destination

Register your server URL with NCM. The secret is used to verify that incoming webhooks are actually from NCM.

POST https://www.cradlepointecm.com/api/v2/alert_push_destinations/

{
  "name": "My Monitoring Server",
  "address": "https://my-server.example.com/webhooks/ncm",
  "secret": "your-shared-secret-here",
  "enabled": true
}

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.

Step 2

Test the destination

Verify NCM can reach your server before configuring alert rules.

POST https://www.cradlepointecm.com/api/v2/test_alert_push_destinations/

{
  "destination_config_id": "YOUR_DESTINATION_CONFIG_ID",
  "secret": "your-shared-secret-here"
}

A 201 Created response with an empty body means your destination is reachable and the secret is valid.

Step 3

Create an alert rule with your destination

Configure which events trigger notifications and where they're sent.

POST https://www.cradlepointecm.com/api/v2/alert_rules/

{
  "name": "Router Online/Offline Alerts",
  "alert_types": ["online_offline_alert"],
  "http_destinations": ["YOUR_DESTINATION_CONFIG_ID"],
  "enabled": true
}

Or in the NCM UI: Alerts & Logs → Alert Rules → Add Rule → select alert types → add your HTTP destination.

Step 4

Receive and verify webhooks

When an alert fires, NCM sends an HTTP POST to your destination URL. Verify the request using the shared secret.

from flask import Flask, request, jsonify

app = Flask(__name__)
SHARED_SECRET = "your-shared-secret-here"

@app.route("/webhooks/ncm", methods=["POST"])
def handle_webhook():
    # Verify the secret matches
    payload = request.json

    # Process the alert
    alert_type = payload.get("alert_type")
    router_name = payload.get("router_name", "Unknown")

    if alert_type == "online_offline_alert":
        state = payload.get("state", "unknown")
        print(f"Router {router_name} is now {state}")

    return jsonify({"status": "ok"}), 200

if __name__ == "__main__":
    app.run(port=5000)

Available alert types

These are the event categories you can subscribe to. Each category contains multiple specific alert types.

CategoryWhat it coversCommon use case
GeneralDevice online/offline, device registered, device unregisteredFleet uptime monitoring — replaces polling
HealthCellular health score changes, connection quality degradationProactive network quality monitoring
ModemSignal strength thresholds, carrier changes, SIM eventsCellular connectivity monitoring
ConfigurationConfig push, config rejected, config driftChange management, compliance
SecurityUnauthorized access attempts, certificate eventsSecurity monitoring, SIEM integration
Carrier DataPooled data usage thresholds, per-router usage percentageCost management
Carrier SelectionCSI test started/passed/failed/errorConnectivity resilience monitoring
EthernetEthernet link up/down, speed changesWAN monitoring
HardwareHardware failures, critical operating temperatureDevice health monitoring
BatteryBattery health, over current/temp/voltage, low power, power off, maintenance cycles, backup power, wall power restoredE100/E400/X20 battery monitoring
LANLAN interface eventsLocal network monitoring
Location ServicesGeofence enter/exit, GPS eventsFleet tracking, geofencing
Cellular Access PointsAP reboot, NTP sync issues, radio status, AP/core connection state, high temp, SAS grant events, IPsec tunnel failurePrivate cellular monitoring
Mobility GatewayMobility gateway eventsMobile network monitoring
NetCloud OS AppsSDK app eventsApp lifecycle monitoring
SubscriptionsLicense expiration, subscription changesLicense management
Wi-Fi as WANWi-Fi WAN connection eventsAlternative WAN monitoring
Service GatewayService gateway eventsGateway monitoring
AI InsightsAI-generated network recommendationsProactive optimization

Each category links to its full alert type definitions, thresholds, and example alert messages. See the complete Alerting and Reporting documentation for details.

Common recipes

“Alert me when any router goes offline”

This is the #1 reason customers poll. Replace it with a single alert rule.

# 1. Create destination (one-time setup)
POST /api/v2/alert_push_destinations/
{"name": "NOC Dashboard", "address": "https://noc.example.com/hooks", "secret": "s3cret", "enabled": true}

# 2. Create alert rule for online/offline
POST /api/v2/alert_rules/
{"name": "Fleet Online/Offline", "alert_types": ["online_offline_alert"], "http_destinations": ["DEST_CONFIG_ID"], "enabled": true}

# Done. You'll get a POST to your URL within seconds of any router going offline.

“Alert me when signal drops below -90 dBm”

Instead of polling net_device_signal_samples, set a threshold alert.

POST /api/v2/alert_rules/
{
  "name": "Low Signal Alert",
  "alert_types": ["signal_strength_alert"],
  "threshold": -90,
  "http_destinations": ["DEST_CONFIG_ID"],
  "enabled": true
}

“Alert me when a config change is pushed”

Track configuration changes across your fleet without polling configuration_managers.

POST /api/v2/alert_rules/
{
  "name": "Config Change Tracking",
  "alert_types": ["config_push_alert", "config_rejected_alert"],
  "http_destinations": ["DEST_CONFIG_ID"],
  "enabled": true
}

“Alert me on carrier failover”

Know immediately when a device switches from primary to backup WAN.

POST /api/v2/alert_rules/
{
  "name": "Failover Alerts",
  "alert_types": ["failover_alert"],
  "http_destinations": ["DEST_CONFIG_ID"],
  "enabled": true
}

Integration examples

ServiceNow — auto-create incident on device offline

import requests

def handle_ncm_webhook(payload):
    if payload.get("alert_type") == "online_offline_alert":
        if payload.get("state") == "offline":
            # Create ServiceNow incident
            requests.post("https://your-instance.service-now.com/api/now/table/incident",
                json={
                    "short_description": f"Router {payload['router_name']} went offline",
                    "description": f"Device {payload['router_id']} in group {payload.get('group', 'N/A')} went offline at {payload.get('timestamp')}",
                    "urgency": "2",
                    "category": "Network"
                },
                auth=("admin", "password")
            )

Slack — post to a channel on any alert

import requests

SLACK_WEBHOOK = "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK"

def handle_ncm_webhook(payload):
    router = payload.get("router_name", "Unknown")
    alert = payload.get("alert_type", "unknown")

    requests.post(SLACK_WEBHOOK, json={
        "text": f"NCM Alert: {alert} on router {router}",
        "blocks": [
            {"type": "section", "text": {"type": "mrkdwn",
                "text": f"{alert}\nRouter: {router}\nTime: {payload.get('timestamp', 'N/A')}"
            }}
        ]
    })

API reference

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, you'll need to allowlist NCM's outbound IP addresses. See the alert_push_destinations documentation for the current list of outbound IPs.