Webhooks

What it does

The Webhooks panel registers endpoints that receive your organization’s event notifications: the delivery URL, which events it subscribes to, a retry/backoff policy, an active/paused state, and a signing secret used to HMAC-sign every payload. The event-driven dispatcher itself is already enforced on the data plane — this panel authors and syncs the config the dispatcher reads.

Configure in the UI

System → WebhooksCitadel synthetic data on a non-production Arbitex demo instance. Never client data.

1. Open System → Webhooks and click New Webhook.

2. Enter an Endpoint id and the Delivery URL, then check the Subscribed events this endpoint should receive.

3. Set Max retries and Backoff (seconds) for delivery retries, and leave Active on (or toggle it off to pause deliveries without deleting the endpoint).

4. Click Issue secret to generate a signing secret. It is shown once — copy it now, since only a redacted hint is stored afterward. Use Rotate secret later to replace it.

5. Save the endpoint. From the row’s action menu you can Edit, Probe (a reachability check), Test (send a test event), or Delete it.

6. The Delivery log below lists recent delivery attempts, filterable by status and endpoint; click Inspect on any row to see its event payload.

Delivery log, Probe, and Test are pending backend

Endpoint CRUD (register, edit, delete, issue/rotate secret) is fully live. The delivery log, the per-endpoint Probe reachability check, and Test send are built in the console UI, but their backend routes are not yet exposed from the admin control plane — until they are, these three surface an honest “pending backend” notice rather than fabricated data.

API equivalent

List and author webhook endpoints (replace-all):

curl -X POST "https://admin.arbitex.ai/api/v1/admin/system/webhooks/list" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"du_id": null}'

curl -X POST "https://admin.arbitex.ai/api/v1/admin/system/webhooks/set" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"du_id": null, "objects": [{"object_key": "audit-sink", "payload": {"url": "https://hooks.example.com/arbitex", "events": ["dlp.violation"], "active": true, "max_retries": 3, "backoff_seconds": 30, "secret_set": true, "secret_hint": "a1b2"}}]}'

/set is desired-state / replace-all: every save re-authors the full endpoint list, so add, edit, and delete all merge into the current list before the call. The signing secret itself is never sent back by a read — only the redacted secret_hint.

Plan & availability

Webhooks are available on every plan. The number of active endpoints is not gated by plan tier today.

Deployment notes

On a Hybrid Outpost, the event dispatcher runs against that deployment’s own data plane, so an endpoint you register there only receives events from that Outpost. In an air-gapped deployment, webhook deliveries require your receiving endpoint to be reachable from the deployment’s network — an endpoint outside the air gap will never receive deliveries.

Related

• Config Backup & Restore — webhook config (never the secret itself) is included in every backup snapshot.
• Alerts — a separate config-authoring surface for threshold-based alert rules, not event webhooks.