Skip to main content
A webhook at the Organization scope subscribes to changes the platform makes to your Organization’s configuration and POSTs them to an endpoint you control. It’s the Organization’s live stream counterpart to the Audit Log — the audit page is the permanent record, the webhook is the push. Open Webhooks from the Organization left navigation to see the list, create new webhooks, or inspect the delivery history of an existing one.

​
What you can subscribe to at this scope

At the Organization scope, the only event a webhook can subscribe to is:
Event IDTriggered by
organization.configuration.auditAny change to Organization-scope configuration — Organization Settings, Admin Portal Authentication, Self-Service Portal Authentication, Administrators, Custom SAML Role Mappings, Service Context lifecycle, and webhook configurations themselves.
The deliberate scope: the Organization-level webhook gives you a single feed of “someone changed something at the Organization layer.” Every change that the Audit Log captures with an empty Context column shows up here. For the per-Service event streams — Sign-In sessions, RADIUS session events, DHCP, configuration audits inside each Service Context — open the relevant Service Context’s own webhook configuration. Each Service publishes its own catalogue:

Sign In webhooks

Sessions, captive-portal events, Sign-In configuration audits.

EntryPoint webhooks

EntryPoint configuration audits.

EasyPSK webhooks

Meraki Wireless Personal Network configuration audits.

Endpoint Manager webhooks

Cisco ISE Device Management configuration audits.

​
The Webhooks list

The list page shows every Organization-scope webhook in your Organization with the following columns:
ColumnWhat it means
NameThe display name you gave the webhook. Click to open its detail.
TypeEvent (each change delivered immediately) or Batch (changes accumulated and delivered in groups).
StatusEnabled (green pill) or Disabled (red pill).
EventsPills showing each event ID the webhook subscribes to. At Organization scope, this is always organization.configuration.audit.
Webhooks list with Name Type Status Events columns showing two webhook rows

​
Creating a webhook

Click Create Webhook. The form has two fields:
  • Webhook Type: dropdown with two options — Instant Event Delivery (recommended) and Batch Delivery.
  • Webhook Name: alphanumeric, 3–125 characters. The name is for your own bookkeeping; it appears in the list and in audit rows whenever the configuration changes.
Create Webhook form with Webhook Type dropdown showing Instant Event Delivery (recommended) and Batch Delivery options, plus Webhook Name field
After Create Webhook, the platform creates the webhook in disabled state and takes you straight to the Webhook Settings configuration page.

​
Event vs Batch — when to pick which

Instant Event Delivery sends one HTTP POST per change as soon as it happens. The right choice when:
  • The downstream consumer expects each event individually (a SIEM, a workflow engine, a chat-channel notifier).
  • You want to react to changes in near-real-time.
  • The volume of Organization-configuration changes is naturally modest (a few per hour at most for most teams).
Batch Delivery accumulates events into one POST per flush, either when the batch size is hit or the interval elapses. The right choice when:
  • The downstream consumer would prefer fewer larger requests (a long-term archive, a daily change report, a low-budget endpoint).
  • You’re streaming a high-volume Service-level event (sessions on Sign In, for example) and want network efficiency.
For Organization scope specifically, instant delivery is almost always the right call — Organization-configuration change volume is low, and operational visibility benefits from immediacy.

​
Webhook configuration

The detail page is laid out as five cards. Edit, save, then enable.

​
Webhook Settings

  • Webhook Name — same alphanumeric 3–125-character constraint as creation.
  • Payload URL — the HTTPS endpoint the platform POSTs to. 7–500 characters. Must be reachable from the public internet.

​
Batch Limits (Batch type only)

  • Batch Size Limit — flush early when this many events have accumulated. 2–20000.
  • Batch Intervall (in minutes) — flush after this many minutes even if the size limit hasn’t been hit. 1–86400 (the default is 20).
The webhook flushes when either limit is hit, so a busy stream flushes by size and a quiet stream flushes by time.

​
Headers

Add custom HTTP headers to every outgoing POST. The right place to plumb authentication for your downstream endpoint — a bearer token, a shared secret your endpoint validates, a tenant identifier. The platform does not sign payloads itself; if your endpoint needs to verify the request came from the platform, encode that as a header the endpoint can validate.

​
Webhook Events

The single subscribable event at this scope, presented as a checkbox you tick:
  • Configuration Change (organization.configuration.audit) — Trigger when Organization Settings are changed. (Despite the label this covers the full set of Organization-scope configuration changes listed earlier.)
Webhook Events configuration card showing a single Audit Events grouping with Configuration Change checkbox

​
Active

A toggle. The webhook is created disabled; tick Webhook Active to start delivering events. You can leave the toggle off indefinitely while you finalise the configuration.

​
Inspecting deliveries

Open a webhook’s detail and switch to the Recent Deliveries tab to see what the platform actually sent and what your endpoint returned. Each row is one delivery (one HTTP POST attempt or a sequence of attempts). For Batch-type webhooks, the Pending Events tab shows what’s queued but not yet flushed. Click a delivery row to see:
  • The full Payload the platform sent (collapsible JSON block).
  • One Delivery Attempt card per attempt, with Request and Response sub-tabs:
    • Request — the headers the platform sent (your custom Headers plus the platform’s standard ones).
    • Response — the HTTP status code your endpoint returned, the response headers, and the response body (truncated for very large responses).
  • A Completed in X seconds. footer per attempt.
Webhook configuration detail page showing Webhook Settings tab content with Webhook Name, Payload URL, Http Headers, Webhook Events with single Configuration Change checkbox, Active toggle and Webhook Deletion sections

​
Retry behaviour

If the first attempt doesn’t return a successful (2xx) response, the platform retries with an increasing delay between attempts. After several attempts the delivery is marked Failed and the platform stops retrying that specific delivery; subsequent events are still attempted on their own retry budget. There is no manual “retry now” button — failed deliveries stay visible in Recent Deliveries for inspection but cannot be re-sent. If your endpoint is fixed and you want to backfill missed events, replay them from the Audit Log or from your own change-source-of-truth instead. Successful deliveries are marked Completed.

​
Delivery history retention

Recent Deliveries keeps each delivery for 3 days after the last attempt and then ages it out. The webhook configuration itself is preserved indefinitely; only the per-delivery history is on a TTL. If you want a longer-lived record of every delivery, log them on your endpoint side — the platform does not store deliveries beyond the 3-day window.

​
What’s audited about webhooks themselves

Every webhook lifecycle event — create, edit, enable, disable, delete — emits an organization.configuration.audit event of its own. This means: a webhook can deliver an audit row about its own configuration change (and about changes to other webhooks in the same Organization). When debugging a webhook, expect to see the configuration changes you make appear in the live stream moments later.

​
Where to go next

Audit Log

The permanent record. Webhooks are the live counterpart.

Organization Settings

Every save here triggers a webhook delivery.

Managing Administrators

Administrator invites, role changes, and removals all flow through this stream.

Organization diagnostics

“My webhook isn’t delivering” — and other webhook issues.