Webhooks and Event Subscriptions

Overview#

A SOC team wants their SIEM to receive every authentication failure and account lockout event from Argus in real time, without polling an API every few seconds. Their IT automation system needs to provision accounts in downstream systems the moment a user joins an organisation, not on the next scheduled sync. Their compliance team needs an immutable log of all platform events flowing to cold storage for regulatory audit purposes. Webhooks handle all three: when an event occurs in Argus, configured endpoints receive an authenticated HTTP POST with the full event payload within seconds.

The delivery architecture includes automatic retry with exponential backoff, cryptographic signature verification on every payload, and idempotency keys so receiving systems can safely deduplicate without missing events.

Open Standards#

HMAC-SHA256 (RFC 2104 / FIPS 198-1): Every outbound webhook delivery is authenticated with an HMAC-SHA256 signature sent in the X-Argus-Signature: sha256=<hex> header, allowing receiving systems to verify payload authenticity and integrity.
Standard Webhooks v1.0: The platform's webhook infrastructure follows the open Standard Webhooks specification, using a compatible HMAC-SHA256 signing scheme and per-delivery identifiers aligned with the svix-id / svix-timestamp / svix-signature header convention adopted across multiple provider integrations.
JSON (RFC 8259 / ECMA-404): All event payloads are serialised as application/json; the envelope structure, including event type, timestamp, delivery ID, and data body, is a plain JSON object transported with the correct media type header.
RFC 3339 / ISO 8601 Timestamps: Event envelope timestamps are produced as UTC ISO 8601 strings (e.g. 2026-06-05T10:00:00+00:00), ensuring unambiguous, timezone-aware time representation that any consuming system can parse.
UUID (RFC 4122): Delivery identifiers and subscription identifiers are version-4 random UUIDs, used as idempotency keys so receiving endpoints can safely deduplicate retried deliveries.
HTTPS / TLS (RFC 8446): All webhook deliveries and the subscription management API operate exclusively over HTTPS; outbound requests are subject to SSRF protection that enforces publicly routable HTTPS target URLs.
OAuth 2.0 (RFC 6749): The webhook management API (create, list, update, delete subscriptions) is protected by the platform's OAuth 2.0 Bearer token authentication layer, and OAuth client and token events are a first-class supported event category.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Key Features#

Cryptographic Signature Verification: Every webhook delivery includes an HMAC-SHA256 signature header for payload authenticity verification, preventing unauthorised or tampered payloads from being accepted
Comprehensive Event Types: Subscribe to events across user lifecycle, MFA, security, SSO, organisation, session, and OAuth categories for complete platform visibility
Automatic Retry Logic: Failed deliveries are retried up to 3 times with exponential backoff, ensuring reliable event delivery even during temporary endpoint unavailability
Delivery History and Debugging: View delivery attempt details including status codes, response bodies, and error messages for each webhook to diagnose integration issues
Selective Event Subscription: Subscribe to only the event types needed, minimising network traffic and focusing on events relevant to the integration
Webhook Management API: Create, list, update, and delete webhooks through a self-service API with full lifecycle management
Tenant Isolation: Users can only manage and receive events for their own webhooks, with complete data separation between organisations
Standard Payload Format: All events use a consistent JSON payload structure with event type, timestamp, event-specific data, and organisation context
Idempotency Support: Each delivery includes a unique delivery identifier usable as an idempotency key to prevent duplicate processing on the receiving side
Delivery Statistics: Track delivery success rates and failure counts per webhook for integration health monitoring

Supported Event Categories#

User Events: Account creation, login, logout, password changes, email changes, and profile updates
MFA Events: MFA enablement, disablement, passkey registration, and challenge failures
Security Events: Breach attempt detection, account lockouts, suspicious login detection, and password breach notifications
SSO Events: SSO authentication completions, provider linking, and provider unlinking
Organisation Events: User additions, removals, and role changes within organisations
Session Events: Session creation, termination, and concurrent session limit events
OAuth Events: Client registration, token issuance, and token revocation

Use Cases#

SIEM platforms subscribe to security events to receive real-time breach detection alerts, aggregate authentication failures across tenants, and trigger automated incident response workflows
IT automation systems subscribe to user lifecycle events to provision and deprovision accounts in downstream systems when users are added to or removed from organisations
Compliance teams stream all platform events to immutable log storage for regulatory audit trails, monitoring privileged user activities and MFA enrolment patterns
DevOps teams monitor OAuth client and token events to track third-party application authentication activity and detect anomalous token usage patterns
Custom integrations use webhook events to synchronise platform changes with CRM records, ticketing systems, or notification channels in real time

Integration#

The Webhooks system connects with the platform's authentication layer for secure webhook management, the event processing pipeline for reliable event capture and delivery, and supports integration with any external system capable of receiving HTTPS POST requests and verifying HMAC-SHA256 cryptographic signatures.