Delivery channels

A channel is a configured destination. Reports, watches, monitors, and alert routes all deliver through the same channel objects, so a Slack workspace or an S3 bucket is set up once and reused everywhere.

Read: 5 min
Module: Channels

Supported channels

Channels are configured under Settings → Channels. Each one is validated when you save it — a bad webhook URL or an expired Slack token fails at configuration time rather than silently at 3 a.m. on the night a report matters.

Kind	Carries	Configuration
`email`	Formatted table, CSV, XLSX, PDF	Optional from-address; transport comes from the workspace email settings
`slack`	Message + file	Incoming webhook URL; a route can override the channel
`discord`	Message + attachment	Incoming webhook URL; a route can target a thread
`telegram`	Message + document	Bot token; the route target is the chat id
`whatsapp`	Message	Evolution API — unofficial. Base URL, API key, instance
`whatsapp_cloud`	Message	Meta Cloud API — official. Phone number id, access token, template
`sms`	Text	SMS provider credentials
`s3`	File object	Bucket, region, credentials, optional prefix
`sftp`	File	Host, port, credentials, remote directory
`webhook`	JSON payload	URL, optional headers, optional signing secret
`pagerduty`	Incident	Events API integration key — alerting, not report delivery
`opsgenie`	Alert	Alerts API key — alerting, not report delivery

There are two WhatsApp kinds and the difference matters: whatsapp_cloudis Meta’s official Cloud API and is the one to use for anything customer-facing; whatsapp drives an unofficial Evolution API instance you host yourself.

Email: system vs tenant

DataRunner keeps two email paths apart on purpose. Platform mail — invites, password resets — always goes through the provider configured on the deployment. Your reports and alerts go through yourworkspace’s email settings, so they come from your domain and your reputation, not ours.

System email

Invites, password resets, platform notices. Configured by the operator, not by a workspace.

Tenant email

Report results, alerts, campaigns. Configured per workspace under Settings → Email.

No silent fallback. If a workspace has no email provider configured, tenant mail fails loudly instead of borrowing the platform provider. Sending customer- facing mail from the wrong domain is worse than not sending it.

Routes and fan-out

A report does not point at a channel directly — it points at one or more routes, and a route pairs a channel with a format and recipients. That indirection is what lets the same report go out as a rendered table to Slack and as an Excel file to S3, from a single run.

Fan-out

Every route on a report fires on every run. One slow route does not block the others.

Per-route outcome

Success and failure are recorded per route, so a partial delivery is visible in history.

Idempotency

A delivery receipt is keyed on run and route, so a worker retry cannot double-send.

Webhook payloads

The webhook channel POSTs a JSON envelope describing the run and its result. Large result sets are not inlined — the payload carries a signed download URL instead, so a million-row export does not become a multi-megabyte POST body.

webhook payloadjson

{
  "event": "report.delivered",
  "runId": "5f1c…",
  "reportId": "a91b…",
  "workspaceId": "3c40…",
  "status": "done",
  "startedAt": "2026-07-28T07:00:00Z",
  "durationMs": 1840,
  "rowCount": 1423,
  "columns": ["day", "signups", "revenue"],
  "resultUrl": "https://…/exports/5f1c….csv?sig=…"
}

Verify the signature header before trusting a payload, and treat delivery as at-least-once: dedupe on runId plus the route id.

ReportsWhat gets delivered AlertingRouting failures and incidents API & webhooksOutbound webhooks for workspace events