Outbound is not inbound
Two objects, opposite directions, both under Integrations:
If your goal is “an alert should start an investigation”, you want an inbound endpoint. If your goal
is “our ticketing system should know when the investigation is done”, you want an outbound webhook.
Setting one up
Outbound webhooks live under Integrations → Webhooks (outbound). New notification sink opens a four-step wizard.1
Destination
Give it a name, then choose where events go. Webhook sends signed POST requests to any HTTPS
endpoint — you supply the destination URL and a signing secret. Slack posts messages to a
channel instead, using your existing Slack connection.
2
Events
Pick which event types this sink should receive. The catalog is the same regardless of which
sources feed it.
3
Payload & test
Inspect exactly what will be sent — always JSON — and use Send test event to fire a real
request at your endpoint before anything depends on it.
4
Subscriptions
Choose which sources feed this sink: specific agents, specific workflows, specific incident
pipelines, or the whole workspace.
What you can subscribe to
Three families of event, in one catalog:
Events and sources are separate axes, which is what makes fan-in useful. One sink can take
run.failed from a single agent; another can take run.finished from every source in the workspace;
a third can take incident events from two specific incident pipelines. agent.created is
workspace-scoped by nature — there is no per-agent source for an agent that does not exist yet.
What gets delivered
One fixed JSON envelope, versioned, with no templating — so there is exactly one shape to write a receiver against:The request
Verify the signature over the raw bytes you received, before parsing. Re-serializing the JSON and
signing that will not match.
Two things KAOP will not do, both deliberate:
- Redirects are never followed. Any
3xxresponse is treated as a failed attempt, because a redirect to an internal address is a way around the destination you configured. - Private and loopback destinations are refused — and the destination is re-resolved and re-checked on every send, not only when the sink was created, so a name that starts resolving internally later is caught at delivery time.
Rotating the signing secret
Rotate signing secret issues a new one and shows it to you once. Rotation is an audited, elevated action, so plan for the cutover: your receiver should be ready to accept the new secret before you rotate.How delivery behaves
A failed attempt is retried with backoff, up to a bounded number of attempts, and then dead-lettered
— which marks the delivery
exhausted in the log. There is no automatic follow-up after that, so
exhausted is the state to alert on if these events are load-bearing for you.
Rate limiting is handled differently from failure, and in your favour: a 429 or 503 is retried
after the delay your Retry-After header asks for, and that wait does not consume the retry budget.
So back-pressure from your side costs you a delay rather than a dropped event.
A disabled or deleted sink is a silent no-op — events for it are dropped rather than queued up for a
destination that no longer wants them.
Auditing what was sent
Every sink row carries a History link. It opens the delivery log for that sink: when each attempt happened, which event it carried, which attempt number it was, the result, and the response body your endpoint returned (captured up to a few kilobytes — enough for the diagnostic, which is almost always at the front). The log is durable and per-workspace, so “did this fire, and what came back?” has an answer well after the fact. Configuration and deliveries are recorded in two different places on purpose:- Configuration changes are audited — creating, updating, or deleting a sink, rotating its secret, and subscribing or unsubscribing a source all write audit entries.
- Deliveries are not audit entries. They are operational data, and they live in the delivery log above.
Who can manage them
Reading the list of sinks is a workspace-scoped permission. Creating, updating, deleting, rotating a secret, and sending a test event are administrative actions held at a deliberately higher bar — an outbound webhook is a workspace-chosen arbitrary URL, which puts it in the same class as managing credentials. See Roles & permissions.Next steps
Runs & evidence
What the
run.* events are describing.Integrations
Inbound endpoints, and the connection catalog.
Audit log
Where configuration changes to a sink are recorded.
Channels
The conversational route into and out of Slack.