A network operations team runs Catalyst Center across 40 sites and wants its ticketing relay to receive push notifications rather than scheduled report exports. Only high-severity device-down events from the Reno building should reach the relay, an internal HTTPS endpoint, and alarms must arrive as pushes rather than being pulled from Assurance on a schedule. How should the outbound webhook destination and event subscription be configured?

The event subscription is the selection layer and the webhook destination is the delivery layer, and a working outbound webhook needs both linked. You register the destination once with its HTTPS URL and authentication header, then the subscription decides what flows to it by matching site, event type and severity, so only Reno's device-down alarms leave the platform. Source-side filtering is the point of the design, because the relay then receives a curated stream it can act on at once. Building a polling client against Assurance fails the push requirement, since a scheduled pull adds latency and requires repeated API requests. Registering every event type and filtering downstream works functionally, but it moves selection logic into a second system that must stay in sync with changing event definitions. Subscribing all sites for future growth satisfies neither the site scope nor the ticketing team's ownership. Exam caveat: menu paths shift between releases (the platform was long marketed as DNA Center), so treat destination and subscription as concepts rather than memorised clicks. Practical check: trigger a test device-down event and confirm exactly one matching payload lands while informational alarms stay silent.