Outbound and inbound have opposite risks
Posting a message from your app to Slack can fail without hurting anyone as long as the app stays up and the failure is visible. Receiving events from Slack means exposing an endpoint that must prove each request is genuine and answer inside a short window. The first is a delivery-design problem; the second is a verification and timing problem. Treating them as one integration usually produces an endpoint that is either slow or trusting.
- Outbound: webhook URL or bot token, rate limits, duplicates.
- Inbound: signature, timestamp, three-second acknowledgement, retries.
- Interactive buttons and slash commands add their own rules and are outside both single jobs.
Outbound choices
An incoming webhook URL contains a secret and is tied to one channel; leaking it lets anyone post there, and Slack says it searches for and revokes leaked ones. A bot token with the posting permission can post to chosen channels and can see an error when the channel is wrong. Either way, Slack allows about one message per second per channel and answers a rate-limited call with 429 and a Retry-After value.
- Keep the URL or token in your secret store, never in the repository.
- Send the alert after the customer's action is safely saved.
- Record one post per event identifier.
Inbound rules
Slack signs each request with a timestamp and your signing secret, and documents refusing requests more than five minutes old. For the Events API your app must return a 2xx within three seconds; Slack retries a failed delivery up to three times and can pause subscriptions when most deliveries fail. The safe shape is: verify, claim the event ID with one atomic insert, queue the work from that record and reply, so a retry or a simultaneous duplicate finds the claim and starts nothing.
- Read the raw body before parsing.
- Answer the one-time URL verification request with the challenge value.
- Rotate the signing secret from the app settings if it is exposed.
Which paid step fits
One event posted to one channel is the single alert outcome at a fixed £195 test price; one verified, replay-safe events endpoint is a separate outcome at a fixed £445 test price. Staff alerts as part of a larger customer-messaging build sit in the notification project. Prices are untested and payment follows the agreed checks and sign-off. Creating or approving the Slack app stays with your workspace admin. Send the framework and the event, never tokens or the signing secret.
Sources and limits
- Slack: incoming webhooks Checked 2026-10-11.
- A webhook URL contains a secret and is tied to one user and one channel.
- Slack searches for and revokes leaked webhook secrets.
- Slack: Web API rate limits Checked 2026-10-11.
- chat.postMessage allows about one message per second per channel with short bursts tolerated.
- A 429 response carries a Retry-After header.
- Slack: verifying requests Checked 2026-10-11.
- Requests are signed with a timestamp and a signing secret.
- Requests more than five minutes old should be refused.
- Slack: Events API Checked 2026-10-11.
- An app must return a 2xx within three seconds.
- Failed deliveries are retried up to three times.