HTTPS Webhook

Sends events as a JSON payload via HTTPS POST to a configured endpoint.

The endpoint's certificate must be issued by a publicly trusted CA.

Configuration

Field	Required	Description
Name	Yes	A descriptive name for this forwarder
URL	Yes	HTTPS URL of the webhook endpoint
Secret	Yes	HMAC-SHA256 signing key
Authorization Header	No	Bearer token sent in the Authorization header
Event Filters	No	Select which event categories or types to forward

Payload

One request carries a batch of up to 500 events, in the order they were recorded.

{
  "tenant_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "delivered_at": "2026-04-08T09:25:00.418512Z",
  "events": [
    {
      "id": 12345,
      "session_id": "f0e1d2c3-b4a5-6789-0abc-def123456789",
      "event_class": "authentication",
      "event_type": "logged_in",
      "message": "jdoe@example.com logged_in",
      "session_type": "client",
      "remote_address": "198.51.100.42",
      "data": {
        "user_email": "jdoe@example.com",
        "client_name": "laptop-jdoe",
        "auth_type": "azure_ad_oidc",
        "tenant_name": "Acme Corp"
      },
      "created_at": "2026-04-08T09:24:59.123456Z"
    }
  ]
}

Field	Description
tenant_id	Tenant UUID
delivered_at	When the request was built: RFC 3339, UTC
events[].id	Event id: an integer, unique and increasing. Deduplicate on it, since a batch can be delivered twice
events[].created_at	Event creation time: RFC 3339, UTC, sub-second precision
events[].data	The event's fields. Which ones are present depends on the event, see the Event Reference

Request Headers

Header	Value
Content-Type	application/json
User-Agent	XplicitTrust-CloudController/1.0
X-Webhook-Signature	sha256=<HMAC-SHA256 hex digest>
Authorization	Bearer <token> (if configured)

Signature Verification

1. Read the raw request body.
2. Compute HMAC-SHA256(secret, body) with the configured secret.
3. Compare the hex digest with the value after sha256= in the X-Webhook-Signature header.

Only the body is signed; headers are not. Replay protection is the receiver's responsibility, and each event's id is the key for it.

Responses and Retries

• Reply with any 2xx status within 10 seconds. The response body is ignored.
• 429 and 5xx responses and connection errors are retried twice within the same delivery, after about one and two seconds. Any other 4xx response fails the delivery immediately.
• A failed delivery is retried later with half the batch size (see Delivery). That is also how a 413 Payload Too Large response resolves itself.
• One delivery including its retries is limited to 60 seconds.