Destinations.
Where an event leaves the system. The egress half of every pipeline. One pipeline fans out to all of its destinations in parallel on every event it matches.
What's shipping
Five built, the rest soon.
- slackSlack[ready]
- telegramTelegram[ready]
- webhook.outHTTP webhook[ready]
- email.outEmail[ready]
- warehouse.pgPostgres[ready]
- discordDiscord[soon]
- warehouse.bqBigQuery[soon]
- linear.issueLinear issue[soon]
- notion.dbNotion DB[soon]
- s3S3 / object[soon]
The dashboard's /destinations page lets you connect any of the ready ones. Adding new types is ongoing — request one at github.com/ingestlayer.
webhook.out
The default everything.
One config field: url. The worker POSTs to that URL with the body produced by the pipeline's last transform action — or, if there isn't one, the raw event envelope.
# what your endpoint receives by default
content-type: application/json
{
"id": "evt_01HZK4...",
"type": "user.signup",
"received_at": "2026-05-21T14:03:11.512Z",
"payload": { "email": "ada@example.com", "plan": "growth" }
}Any 2xx is success. Anything else is a failure; the delivery moves to retrying, with the response status and a body excerpt kept on the delivery for inspection.
Per-destination redaction
One pipeline, different bodies.
If the pipeline includes a redact.pii step, the body is re-rendered per destination using that destination's column of the redaction matrix. So Slack can receive a masked email while the warehouse keeps the raw one — same event, same pipeline, two different payloads on the wire.
Detail in actions · redact.pii.
Status on failure
Retries, then dead.
Failed deliveries retry on an exponential backoff: 30s, 2m, 10m, 1h. After five attempts the delivery is marked dead and no longer retried. Dead deliveries stay around for inspection. Full details at deliveries.