SOAR Integration
Forward security events from Clevername to your existing SIEM or SOAR platform, and let that platform act back through SOAR API keys. Register signed webhooks, choose which event types are forwarded, and issue scoped keys for inbound control.
How it works
Clevername pushes security events to your SOAR/SIEM platform via webhooks. When a configured event type occurs (an alert fires, a session is paused or killed, a policy is violated), the platform sends an HTTP POST to your webhook URL with the event payload in JSON format.
Supported event types
- alert.fired — A CleverGuard alert rule fired (includes alert id, name, severity, and detail).
- session.paused — An agent session was paused through the SOAR API.
- session.killed — An agent session was killed through the SOAR API.
- policy.violated — An emergency policy was activated through the SOAR API (carries the policy type, enforcement, reason, and TTL).
Session events include an actions_available list with the pause, kill, and restrict URLs for that session, so your SOAR playbook can respond directly.
Webhook secrets vs SOAR API keys
These are two separate credentials. Each webhook has a secret that you supply when you register it; Clevername signs every payload with that secret using HMAC-SHA256. A SOAR API key (prefix csk_) is the credential your SOAR platform uses to call into Clevername — to pause, kill, or restrict sessions, revoke tokens, or set emergency policies. Keys are scoped to the organization, carry explicit permissions (read, pause, kill, restrict, configure), live at most 90 days, and are managed at /dashboard/security/soc/soar-keys.
Open the SOAR integration panel
Navigate to Security → SOC Console and scroll to the SOAR Integrations panel. It has two tabs: Webhooks (registered endpoints, with delete) and SOAR Keys, plus a Manage SOAR Keys link to /dashboard/security/soc/soar-keys.
Register a webhook endpoint
Webhooks are registered through the SOAR API (there is no add-webhook form in the panel). Send a POST with:
- url — The public HTTPS URL of your SIEM/SOAR webhook receiver.
- events — The event types to forward (see the list above).
- secret — A secret you generate; Clevername uses it to sign every payload.
POST /api/hub/soar/v1/webhooks
{
"url": "https://siem.example.com/hooks/clevername",
"events": ["alert.fired", "session.killed", "policy.violated"],
"secret": "<your-random-secret>"
}Create SOAR API keys for inbound control (optional)
If your SOAR playbooks should act on Clevername (pause or kill a session, revoke a token), create a key at Manage SOAR Keys. Choose the minimum permissions the playbook needs and an expiry (90 days maximum). The key is shown once — store it in your SOAR platform's secret store.
Verify delivery
There is no test-event endpoint. Trigger a real event — for example, pause a session through the SOAR API (POST /api/hub/soar/v1/sessions/{id}/pause with a key that has the pause permission), which emits session.paused, or wait for an alert rule to fire — and confirm your SOAR platform received it and the signature verified. Pausing from the SOC Console's own session controls does not emit a SOAR event.
Monitor delivery health
The panel shows each webhook's status (active) and the number of deliveries in the last 24 hours. Failed deliveries are retried up to 3 attempts with backoff (30 seconds, 2 minutes, 10 minutes); after the last attempt the delivery is marked failed and the webhook's failure counter increments. The webhook itself is never paused automatically.
Webhook payload format
Each webhook payload includes a standard envelope with the event type, timestamp, organization ID, and the event-specific data. The payload is signed with HMAC-SHA256 using the webhook's secret, delivered as a hex digest in the X-CleverGuard-Signature header. The event name is in X-CleverGuard-Event and a per-delivery ID in X-CleverGuard-Delivery.