Webhooks and analytics

The Webhooks feature turns R1-MCP into an event sink for your RUCKUS One tenant, and adds a set of analytics tools that answer questions the REST API alone can’t.

Enable it under Features in the dashboard.

Setting up the receiver

get_webhook_receiver creates your receiver and returns a webhook URL and a secret. Both are shown once and stored only as hashes, so save them; a later call returns the receiver’s metadata without them. rotate: true (or the dashboard’s Webhooks card) mints a new pair and invalidates the old URL.

In RUCKUS One, go to Network Control → Service Catalog → Webhooks → Add, choose the RUCKUS One payload type, and paste both. Enable only the topics you need: RADIUS logs and client connect/disconnect are high-volume, and should be on only while you’re actively troubleshooting. The receiver rejects a request with the wrong secret (401 unauthorized) or a body over 64 KB (413 payload_too_large).

Once events start flowing, each delivery is stored verbatim — never de-duplicated, so counts are approximate — alongside normalized fields, and the analytics tools have something to work with.

The analytics are only as good as the event history you’ve collected — a receiver configured five minutes ago can’t tell you about last month.

What you can ask about

Incidents

list_incidents, get_incident, correlate_incident — the incident feed, and a causal timeline around one incident (or a moment you name): correlate_incident gathers admin changes, AP reboots and firmware events, switch config failures and the incident itself, and ranks the disruptive events that preceded it as candidate root causes rather than a list of symptoms.

The Network health check (incidents) prompt runs a full assessment from this data.

Clients

list_clients, diagnose_client, get_client_profile — a persistent client registry, per-client diagnosis, and a device profile. The registry outlives the event cache (see retention). Profiles carry a manufacturer derived from the MAC’s IEEE OUI, which is far more reliable than RUCKUS’s OS fingerprint (os_type is frequently wrong); it is empty for randomized (private) MACs. list_clients filters by OS, encryption, band, and manufacturer.

The Diagnose a client that can’t connect prompt stitches RADIUS and association events into one verdict. The Client deep-dive troubleshooting report prompt — available without this feature — assembles everything known about one MAC into a single report.

Anomalies

detect_anomalies plus the Hunt infrastructure anomalies prompt — looks for infrastructure behaving unlike itself, rather than tripping a fixed threshold.

Admin and change audit

list_admin_audit, get_change_chain — who changed what, when, and what followed from it. The Admin / change audit trail prompt packages this.

When a network “just started” misbehaving, the change chain is usually the fastest path to the answer.

Roaming

roam_matrix, get_client_roams, find_ping_pong_clients — the roaming picture across your APs, including clients bouncing between two APs, which is one of the most common invisible causes of a bad wireless experience.

Events and counts

query_events, get_event_counts, get_notifications, get_ap_health, webhook_event_summary, list_webhook_events, get_webhook_event — the raw event layer underneath the analytics, when you need to look yourself. query_events falls back to RUCKUS One’s activity log when the store has nothing for your filter, and get_ap_health adds a live R1 read of the AP unless you pass includeLive: false.

Watches: reproduce and catch

Watches are for problems you can trigger but not predict:

watch_client, watch_ap, watch_incidents — arm a watch, with a TTL.
list_watches, clear_watch — see and cancel what’s armed.

A watch expires after 24 hours by default and 7 days at most. The expiry is mandatory — there is no permanent watch. Up to 100 watches can be active at once (watch_limit_reached beyond that).

What a watch catches surfaces as a short _notices line on your next webhook_event_summary, list_webhook_events, or diagnose_client call, rather than being pushed to you; get_notifications returns the full notices, filtered by mac or since. P1–P2 incidents surface this way even with no watch set — watch_incidents widens or narrows that threshold (min_severity) for the watch’s lifetime.

The workflow is the Live reproduce-and-catch (watch & capture) prompt: arm a watch on the client or AP, go reproduce the fault, and come back to exactly the events that happened during the window — instead of scrolling a firehose hoping to spot it.

This is the single best reason to enable the webhooks feature.

How long events are kept

Retention varies by event class, which is why a month-old client event is gone while a month-old incident is not:

Event class	Kept	Row cap
Client stream	7 days	20,000
AP infrastructure	30 days	5,000
RADIUS / auth	30 days	4,000
Activity (config change)	90 days	2,000
Admin audit	90 days	2,000
Incidents	365 days	1,000

Each class purges against its own budget, so the high-volume client stream cannot crowd out a rare incident or configuration-change row. The exception: admin logins and other admin-activity events arrive on the client event stream and share its 7-day window, so list_admin_audit reaches back 90 days only for activity and admin rows. Test and unrecognised event types are kept 7 days (400 rows).

Some summaries built from events outlive the raw events, so these tools answer beyond the windows above:

Store	Kept	Used by
Client registry	180 days after the device was last seen (100,000 devices)	`get_client_profile`, `list_clients`
Roam-pair matrix	90 days (40,000 pairs)	`roam_matrix`
Event counters	120 days (20,000)	`get_event_counts`, `detect_anomalies`

Past those windows, a question isn’t hitting a bug — the data was never retained.

Next steps

Features — enabling this and the other flags
Prompts — the guided versions of these workflows
Limits and quotas — retention, watch TTLs, and every other cap
Live Console — watching a client’s events stream in a browser