Skip to main content

Destinations

A destination is a target where events are delivered. Dispatch supports five destination types:

TypeDescription
DiscordDelivers formatted embeds to a Discord channel via webhook
SlackDelivers formatted messages to a Slack channel
TelegramDelivers formatted messages to a Telegram channel or group via bot
WebhookSends the payload as an HTTP POST to any URL
CLIForwards events to a local development server via the Dispatch CLI tunnel

Creating a Destination

Discord

You can create a Discord destination in two ways:

  • Manual: Paste a Discord webhook URL directly
  • OAuth: Connect your Discord account, select a server and channel, and Dispatch creates the webhook for you

Slack

Connect your Slack workspace via OAuth, then select a channel.

Telegram

Dispatch delivers Telegram messages via a bot. To create a Telegram destination:

  1. Add the Dispatch bot to your target channel or group
  2. In the dashboard, create a destination with type Telegram
  3. Enter the chat ID — this can be a channel username (e.g., @mychannel), a numeric group/channel ID (e.g., -1001234567890), or a user ID for direct messages

Message formatting defaults to auto-converting Discord embeds to Telegram HTML. You can also configure a native telegram_html template field for full control — see Message Templates.

Custom Webhook

Enter any HTTP URL. Dispatch will POST the event payload (optionally transformed and formatted) to that URL.

Configuration

FieldDescription
NameDisplay name
Typediscord, slack, telegram, or webhook
Webhook URLTarget URL (encrypted at rest)
Channel IDTelegram chat, channel, or group ID (Telegram only)
Event TypesOptional list of event types to accept (empty = all)
Is ActiveToggle to enable/disable delivery
Retry PolicyRetry configuration (see below)

Event Type Filtering

You can configure a destination to only accept specific event types. If the event_types list is set, only events matching one of the listed types will be delivered to this destination. If the list is empty, all events are accepted.

This is different from endpoint filters — event type filtering on destinations is a simple include list, while endpoint filters support complex conditional logic.

Retry Policy

Each destination has a configurable retry policy:

{
"max_attempts": 7,
"backoff": [1, 5, 30, 120, 900, 3600, 21600]
}
FieldDescription
max_attemptsTotal number of delivery attempts (including the first)
backoffArray of delays in seconds between attempts

Default: 7 attempts with backoff of 1s, 5s, 30s, 2min, 15min, 1hr, 6hr.

Retry Flow

  1. First delivery attempt fails
  2. A retrying delivery attempt is created with next_retry_at set based on the backoff schedule
  3. The retry scheduler (polls every 5 seconds) picks up due retries
  4. If the retry succeeds, the attempt is marked success
  5. If the retry fails and more attempts remain, a new retry is scheduled
  6. After max_attempts, the delivery is marked failed and moved to the dead-letter queue (DLQ)

Rate Limit Handling

For Discord, Slack, and Telegram destinations, Dispatch automatically handles 429 Too Many Requests responses:

  • The retry_after value from the response is respected
  • A global cooldown is applied per provider when a global rate limit is detected
  • Rate-limited deliveries are rescheduled rather than counted as failures

Linking to Endpoints

Destinations are linked to endpoints to receive events. A single destination can be linked to multiple endpoints, and a single endpoint can fan out to multiple destinations.

Each endpoint-destination link supports:

  • Template — which message template to use for formatting
  • Routing Rules — conditional template selection based on event fields
  • Transform — JSONata expression applied before formatting

CLI Destination

A CLI destination is created automatically when you run dispatch listen from the Dispatch CLI. It forwards incoming events to a server running on your local machine over a secure tunnel, and appears in the destinations list as:

CLI · alice@my-laptop · my-source-slug

Events are only forwarded while the CLI session is active. If the CLI is not running when a webhook arrives, the event is stored and visible in the Events tab, but it is not forwarded to that destination.

See the CLI guide for installation and usage instructions.

Security

  • Webhook URLs and bot tokens are encrypted at rest
  • Credentials are only decrypted at delivery time and are never exposed in API responses