Destinations
A destination is a target where events are delivered. Dispatch supports five destination types:
| Type | Description |
|---|---|
| Discord | Delivers formatted embeds to a Discord channel via webhook |
| Slack | Delivers formatted messages to a Slack channel |
| Telegram | Delivers formatted messages to a Telegram channel or group via bot |
| Webhook | Sends the payload as an HTTP POST to any URL |
| CLI | Forwards 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:
- Add the Dispatch bot to your target channel or group
- In the dashboard, create a destination with type Telegram
- 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
| Field | Description |
|---|---|
| Name | Display name |
| Type | discord, slack, telegram, or webhook |
| Webhook URL | Target URL (encrypted at rest) |
| Channel ID | Telegram chat, channel, or group ID (Telegram only) |
| Event Types | Optional list of event types to accept (empty = all) |
| Is Active | Toggle to enable/disable delivery |
| Retry Policy | Retry 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]
}
| Field | Description |
|---|---|
max_attempts | Total number of delivery attempts (including the first) |
backoff | Array of delays in seconds between attempts |
Default: 7 attempts with backoff of 1s, 5s, 30s, 2min, 15min, 1hr, 6hr.
Retry Flow
- First delivery attempt fails
- A
retryingdelivery attempt is created withnext_retry_atset based on the backoff schedule - The retry scheduler (polls every 5 seconds) picks up due retries
- If the retry succeeds, the attempt is marked
success - If the retry fails and more attempts remain, a new retry is scheduled
- After
max_attempts, the delivery is markedfailedand 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_aftervalue 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