Webhooks

Sign In emits events every time a sign-in session changes state, a DHCP lease is granted or expires, or a configuration change is audited. Webhooks deliver those events to an HTTP endpoint you control — useful for CRM, marketing, SIEM, compliance, or operations dashboards.

Subscription scopes

A webhook subscription is attached to a scope. Sign-In events can be subscribed to at:

• Sign-In Context — the most specific, and usually what you want. One subscription receives the full Sign-In event catalogue (session lifecycle, arena session, DHCP, and the Context-level configuration audit) for exactly this one Context.
• Organization — receives only the Organization-level configuration-audit event (organization.configuration.audit), which records audited configuration changes made at the Organization level. It does not aggregate the session, arena, or DHCP events from the Organization’s Sign-In Contexts.

The two scopes do not share the same event catalogue: the session, arena, and DHCP lifecycle events are available only at the Sign-In Context scope. To capture Sign-In session activity for several Contexts, create one Sign-In Context-scoped subscription per Context. Pick the scope that matches the consuming system’s responsibility.

Where to manage Context-level webhooks

From the Sign-In Context admin, webhooks surface under the Context’s own Webhooks route. The admin UI lets you create subscriptions, see recent deliveries, inspect the details of a single delivery (the exact payload sent and the response received), and enable or disable a subscription without deleting it.

Event catalogue

Session lifecycle

Event	When it’s emitted
signin.session.created	A guest started a new sign-in on the Captive Portal.
signin.session.resumed	A returning guest resumed a previous session on the same device.
signin.session.requested	The sign-in requires approval (Meeting Host, device approval policy) and is waiting.
signin.session.approved	An approval was granted (admin / Meeting Host / policy).
signin.session.verified	The guest completed their verification step (email link, SMS code).
signin.session.denied	The sign-in was denied.
signin.session.revoked	An active session was revoked — admin action, device block, or policy change.

Arena session

Arena sessions are the venue-bound access records used by the event-access and whitelisted-device flows — a device joins the network inside a venue’s space and the arena session tracks that visit.

Event	When it’s emitted
signin.arenasession.login	A device joined the venue’s network and an arena session was created.
signin.arenasession.resumed	A device with an active arena session re-associated (e.g. after a brief disconnect).

DHCP

Event	When it’s emitted
signin.dhcp.granted	A DHCP lease was granted to a device associated with a Sign In session.
signin.dhcp.expired	The DHCP session ended — lease expired, device disconnected, or the system detected a missed expiry.

Configuration audit

Event	When it’s emitted
signin.configuration.audit	A configuration change was made inside this Sign-In Context (any audited field on a Login Module, Access Policy, Site, Service Gateway, etc.). Useful for driving a compliance pipeline that mirrors the Change log.

Subscribing

A webhook subscription carries:

• Name and description — admin labels for the list view.
• Endpoint URL — where the HTTP POST is delivered.
• Content type — the MIME type used in the POST body (typically application/json).
• Custom HTTP headers — optional extra request headers, for authentication against your endpoint or for routing.
• Enabled events — a subset of the catalogue above. Pick only the event types your consumer actually needs.
• Batch settings — how many events to pack per delivery and how often to flush (see Batching below).
• Enabled — on/off without deleting the subscription.

Payload shape

Each HTTP POST carries a batch of events — not a single event. The body is a JSON array, with one object per event inside. Each event object carries the fields specific to its type, along with common envelope fields (event type, scope, timestamps).

The delivery record shown in the admin UI displays the exact payload sent for recent deliveries — use that to confirm the concrete shape your consumer will see. Payloads are structured as open JSON objects so new fields can be added over time without breaking consumers; write your consumer to tolerate unknown fields.

Batching

Sign In batches events to avoid flooding consumers. The defaults:

• Up to 20 000 events per delivery.
• Flushed at most every 20 minutes.

If either threshold is reached first, the batch is sent. For low-volume Contexts this means near-real-time flushing on the 20-minute boundary; for high-volume Contexts it means many events per delivery.

Adjust batch settings per subscription — for low-latency consumers lower both numbers; for bulk analytics consumers raise them.

Retention of delivery records

Past deliveries are kept for 3 days on the admin delivery-history view, then auto-expire. Long-term storage of event data is the consumer’s responsibility.

Test deliveries and inspection

The delivery-history view shows every recent delivery, its HTTP status, and the payload sent. Use it to:

• Confirm a new subscription is reaching your endpoint.
• Debug failing deliveries — responses and error details are captured.
• Audit what was delivered when.

When webhooks aren’t the right fit

• Offline analysis — Statistics and Exports for CSV downloads.
• One-off compliance responses — GDPR data search.

Related

Statistics and Exports

Batch-style reporting alternative.

Access Policies

Policy state at the time of a session event is carried on the event.