Skip to main content
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 events from exactly this one Context.
  • Organization — one subscription receives events from every Sign-In Context inside the Organization.
Both scopes share the same event catalogue and payload shape. 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

EventWhen it’s emitted
signin.session.createdA guest started a new sign-in on the Captive Portal.
signin.session.resumedA returning guest resumed a previous session on the same device.
signin.session.requestedThe sign-in requires approval (Meeting Host, device approval policy) and is waiting.
signin.session.approvedAn approval was granted (admin / Meeting Host / policy).
signin.session.verifiedThe guest completed their verification step (email link, SMS code).
signin.session.deniedThe sign-in was denied.
signin.session.revokedAn 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.
EventWhen it’s emitted
signin.arenasession.loginA device joined the venue’s network and an arena session was created.
signin.arenasession.resumedA device with an active arena session re-associated (e.g. after a brief disconnect).

​
DHCP

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

​
Configuration audit

EventWhen it’s emitted
signin.configuration.auditA 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

Statistics and Exports

Batch-style reporting alternative.

Access Policies

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