Use cases

What teams use Dispatch for.

From solo developers monitoring side projects to teams routing events across services. If a webhook needs to be received, inspected, transformed, or delivered, Dispatch fits.

Integration development

Debug integrations without re-triggering events

Building a new integration means waiting for the right event to fire, inspecting the payload, realizing something is wrong, fixing it, and waiting again. That cycle is slow.

Dispatch stores every inbound event with its full payload. Inspect headers and body in the dashboard, see exactly what the provider sent, and replay the event to any destination as many times as you need. The source system never knows.

  • Full payload inspection: headers, body, event type
  • One-click replay to any destination
  • Per-attempt delivery logs with response status and latency
  • Works across GitHub, Stripe, Jira, Linear, and more
GitHubpull_request.opened
receivedReplay

{

"action": "opened",

"number": 482,

"pull_request": {

"title": "fix: retry jitter",

"user": { "login": "ari" }

}

}

  • DiscordDiscord#dev20064ms
  • CLI tunnellocalhost:300020012ms

Repo & project monitoring

One dashboard for all your repos

Maintaining many repos means a constant context switch: per-repo Discord bots, duplicated webhook configs, notifications scattered across channels.

Dispatch gives you one endpoint per project. Pushes, pull request reviews, CI status, and releases flow through the same pipeline, routed to the right channel and formatted consistently, with a full event log when something needs an audit.

  • Single endpoint for all repos in a project
  • Route by event type: pushes to one channel, PRs to another
  • Consistent formatting across GitHub, GitLab, and Bitbucket
  • Full history of every event, filterable by type and status
GitHubPOST /hooks/acme-platform
  • pushDiscord#commits
  • pull_requestSlack#code-review
  • workflow_runDiscord#ci-alerts
  • releaseTelegram@releases
First match wins. Unmatched events are still stored.

Alerting & on-call

Page for what matters. Log the rest.

Webhook noise is real. Most events aren't worth a notification, and the one that is can't drown in a channel nobody reads.

Filter rules decide which events page your team and which just get recorded. Critical payment and error events hit the on-call channel; routine ones land in a quiet log, stored and searchable.

  • Filter on any header or payload field
  • Critical events to on-call, routine events to a quiet log
  • Filtered events are still stored, searchable, and replayable
  • Failure alerts by email or straight to a destination
On-call filterAND

body.level in ("error", "fatal")

body.project eq "payments-api"

  • Sentrylevel: fatalDiscord#on-call20038ms
  • Sentrylevel: infostored · no page

Event routing & fan-out

One event in. Every destination notified.

Delivering one event to several places usually means custom bots, duplicated webhook configs, or a glue service you now maintain.

Dispatch links any number of destinations to an endpoint and fans out every event to all of them. Each destination gets its own template, retry policy, and delivery log.

  • Per-destination templates: Discord embeds, Slack blocks, Telegram HTML
  • Routing rules pick destinations by event type
  • Independent retries with exponential backoff per destination
  • Forward raw JSON to your own API with custom headers
GitHubpush · acme/api
received
  • DiscordDiscord#dev20047ms
  • SlackSlack#engineering20052ms
  • Webhookapi.acme.dev20089ms
One event, three deliveries. Retries are independent per destination.

API & integration middleware

Normalize webhook payloads before they hit your API

Every provider sends webhooks differently. Stripe wraps everything in an envelope. GitHub sends a different flat shape per event type. Jira nests everything. Adapter code for each one is complexity your API doesn't need.

Dispatch sits in front of your API. JSONata transforms reshape each provider's payload into one consistent format before it reaches your code. Your API sees one clean schema, not twelve.

  • JSONata transforms per endpoint-destination link
  • Fail-open: if a transform errors, the original payload is delivered
  • Routing rules apply different transforms per event type
  • Retries and delivery logs on every forwarded request
Stripeinvoice.payment_failed

Provider sends

{

"type": "invoice.payment_failed",

"data": {

"object": {

"id": "in_1QkX9w",

"amount_due": 4900

}

}

}

jsonata transform

Your API receives

{

"event": "payment.failed",

"invoice": "in_1QkX9w",

"amount": 4900

}

Your endpoint is one POST away.

Set up your first endpoint in minutes. Free to start, no credit card required.

POST /hooks/your-slug