Webhook Guides
Send Webhooks to Slack
A webhook to Slack workflow sends important provider or internal events into a Slack channel through a first-class FastHook SLACK destination. It is best for incident alerts, customer lifecycle notifications, review queues, deployment notices, and team-visible automation.
Configure the channel, message template, optional Block Kit JSON, and bot token on the destination. Add filters so only Slack-worthy events pass through before FastHook calls Slack chat.postMessage.
Inbound Slack vs outbound Slack
| Intent | FastHook pattern | Page |
|---|---|---|
| Receive Slack Events API callbacks | Slack source with signature verification | Slack webhooks guide |
| Send provider events into a Slack channel | Slack destination using chat.postMessage | This page |
Slack notification use cases
- Alert on failed webhook deliveries or retry exhaustion.
- Notify finance or support about payment events.
- Send deployment, release, or workflow events from GitHub into an engineering channel.
- Send Shopify order or fulfillment exceptions into an operations channel.
- Escalate high-priority provider events while keeping full delivery logs in FastHook.
Create the Slack destination
Use a bot token that can post in the target channel. Keep one destination per channel or alert workflow.
curl -X POST "https://api.fasthook.io/v1/destinations" \
-H "Authorization: Bearer fhp_xxx" \
-H "x-team-id: tm_3b5335b627084a838b" \
-H "Content-Type: application/json" \
-d '{
"name": "Slack incident channel",
"type": "SLACK",
"config": {
"channel": "#incidents",
"text_template": "Payment failed for {{payload.customer.email}}",
"blocks_template": "[{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Payment failed*\\nCustomer: {{payload.customer.email}}\\nInvoice: {{payload.invoice_id}}\"}}]",
"auth_type": "SLACK_BOT_TOKEN",
"auth": {
"bot_token": "xoxb-your-slack-bot-token"
},
"rate_limit": 1,
"rate_limit_period": "second"
}
}'Shape the Slack message
Slack expects a message JSON body, usually with text and optional blocks. Keep the message compact and link back to the system of record when possible.
{
"text": "Payment failed for {{payload.customer.email}}",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*Payment failed*\nCustomer: {{payload.customer.email}}\nInvoice: {{payload.invoice_id}}"
}
}
]
}Examples
| Webhook source | Slack message | Why it helps |
|---|---|---|
| GitHub | workflow_run failed in production | Engineers see build or deploy failures quickly. |
| Stripe | invoice.payment_failed for a customer | Finance and support can coordinate recovery. |
| Shopify | orders/create needs review | Operations can inspect order events without watching raw logs. |
Route only action-worthy events
- Send failures, approvals, escalations, and review events to Slack.
- Do not send every successful webhook unless the channel is explicitly a log stream.
- Use provider event type, payload severity, environment, or customer tier in filters.
- Use a staging Slack destination with a test channel before replaying production failures.
Debug Slack delivery
- channel_not_found or not_in_channel usually means the channel value is wrong or the bot is not in the channel.
- invalid_auth usually means the Slack bot token is wrong, revoked, or missing permissions.
- A 400 can also mean the rendered Block Kit JSON is not valid for Slack.
- A timeout or 5xx should be retried after Slack or network health recovers.
- Inspect the FastHook attempt response body before editing filters or replaying a batch.
Retries, replay, and delivery logs
Slack can reject messages because of invalid auth, channel membership, malformed Block Kit JSON, rate limits, or temporary API failures. FastHook records each Slack delivery attempt so operators can inspect the response before retrying or replaying.
- Retry temporary Slack failures with backoff.
- Replay important missed notifications after fixing channel or token configuration.
- Keep FastHook logs as the delivery record instead of treating Slack history as the source of truth.
- Use filters so replay does not flood channels with old low-priority events.
Slack channel hygiene
Slack is best for events that need a team to notice or coordinate. It is weak as a durable event archive, so pair it with FastHook request and attempt history instead of treating a channel as the source of truth. Use Google Sheets, object storage, or an internal API when the destination needs durable reporting or automated processing.
Design one destination per channel or workflow. That makes it clear which connection owns which alert, and it lets you pause or throttle a noisy channel without changing unrelated webhook routes.
- Include the provider event type and business object id in every Slack message.
- Add severity or environment fields before routing to incident channels.
- Keep high-cardinality debug payloads out of Slack; link to the system of record instead.
- Use rate limits when replaying old failures into a channel people actively read.