Skip to content
CyberGuardCyberGuard Docs

Outgoing webhooks

Outgoing webhooks let CyberGuard notify an external system the moment something changes, instead of that system polling the API. Register an endpoint, pick the events you care about, and CyberGuard posts a signed JSON body to your URL — enough to keep a ticketing system in sync, post to a chat channel, or archive changes to immutable storage.

Where to find it

Section titled “Where to find it”

Extra → Settings → Webhooks, once the flag is on.

Create an endpoint

Section titled “Create an endpoint”

Use the add button and fill in:

  • Is active — the master switch for this endpoint. Leave it off while you build the receiver, then turn it on.
  • Name and Description — how you will recognise the endpoint later.
  • URL — where CyberGuard posts. It must resolve to a public host; private, loopback and internal addresses are rejected both when you save and again at send time, so a receiver inside your network needs a public ingress.
  • Secret — use the generator to produce a whsec_... value. Copy it now; you will need it in the receiver to verify signatures.
  • Events — the event types this endpoint subscribes to, grouped by model.

Event types

Section titled “Event types”

An event name is the model name, a dot, and what happened. CyberGuard emits created, updated and deleted for each of the following:

ModelEvents
Applied controlappliedcontrol.created, appliedcontrol.updated, appliedcontrol.deleted
Findingfinding.created, finding.updated, finding.deleted
Evidenceevidence.created, evidence.updated, evidence.deleted
Evidence revisionevidencerevision.created, evidencerevision.updated, evidencerevision.deleted

Subscribe narrowly. An endpoint subscribed to everything will see a lot of updated traffic during an audit push.

What gets delivered

Section titled “What gets delivered”

The body is minified JSON with three top-level fields — the event type, a timestamp in ISO 8601, and data holding the serialized object:

{
  "type": "appliedcontrol.created",
  "timestamp": "2026-09-16T14:35:06Z",
  "data": {
    "id": "53709ff2-ade7-4172-9dee-daa580cbba5b",
    "name": "MFA enforcement",
    "status": "active"
  }
}

Three headers accompany it, following the Standard Webhooks convention:

HeaderPurpose
webhook-idA unique id for this message. Log it and ignore repeats — retries reuse the same id.
webhook-timestampUnix send time. Reject messages older than your tolerance window, typically five minutes.
webhook-signaturev1, followed by the base64 HMAC-SHA256 of webhook-id.webhook-timestamp.body, keyed with your endpoint secret.

Recomputing the signature over the raw request body is what proves the message came from your CyberGuard instance and was not altered. Parse the JSON only after the signature checks out.

Delivery and retries

Section titled “Delivery and retries”

Deliveries are queued and sent in the background, so saving an object never waits on your receiver. A failed delivery is retried up to five times with a growing delay, reusing the same webhook-id — which is exactly why idempotency on your side matters. Respond quickly with a 2xx and do the real work asynchronously; a slow receiver turns into a retry storm.

Section titled “Related”