Webhook to Slack: building an event-driven workforce

Every workday your systems produce a steady stream of small, important facts. Someone signs up for the product. A payment clears. A deploy finishes, or fails halfway through. A lead fills in a form on the marketing site at two in the morning. Each of these is a signal that somebody on your team would act on if they saw it in time, and most of them quietly land in a database row, an email nobody opens, or a dashboard people remember to check once a week. The event happened. The response never did.

An event-driven workforce closes that gap by putting events in front of the people who care about them, in the place those people already spend their day. For most teams that place is Slack. This guide walks through how to send any webhook to Slack and build real workflow around it, from the very first delivery through to the reporting and diagnostics that keep it trustworthy months later. The examples use Viably's Webhook Relay, though the underlying ideas apply to any event you can POST from one system to another.

What an event-driven workforce actually means

The phrase sounds grander than the practice. In plain terms it means your team reacts to things as they happen rather than discovering them later during a review. A support lead sees the enterprise trial sign up the moment the form is submitted, so the welcome note goes out while the interest is fresh. Finance watches revenue arrive in a channel through the day instead of reconciling it on Friday. Whoever is on call learns that the nightly deploy failed from a message in their channel, not from a customer.

Viably groups these signals into a handful of event types so each one arrives formatted for what it is. A transaction reads as a payment card with an amount and a customer. A signups event announces a new account. leadgen captures downloads and gated content fills, contactform handles enquiries, and devops carries deploy and CI results. Anything that does not fit a named type still comes through cleanly as others. The point of the categories is that the person reading the channel understands the event at a glance, without anyone having to hand-write the message each time.

From event to an owned follow-up

Seeing an event is useful. Making sure someone acts on it is where the real value sits. A signal that everyone notices and nobody owns tends to evaporate the same way it would have in a database, just a little more visibly.

This is why each relay endpoint can spawn a task on delivery. When you turn the option on, every qualifying event posts its Slack message and then drops a task card underneath it, so the follow-up has a home the moment it appears. You can assign that task to a specific person, or leave it up for grabs and let whoever is free claim it in Slack. For payment endpoints connected to Stripe you can go further and choose which events deserve a task at all, so a new subscription or a scheduled cancellation raises one while routine successful charges simply post and stay quiet. A cancellation that lands in the channel with a task attached, assigned to someone in customer care, becomes a genuine save instead of a number that dips at the end of the month.

Delivery you can actually trust

The difference between a toy integration and infrastructure is what happens on a bad day. Slack has a brief outage. Your own server sends a burst of events during a launch. A network hiccup drops a request. If any of these quietly loses an event, people stop trusting the channel, and a channel people distrust is worse than no channel at all.

Viably treats delivery as the serious part of the job. Every endpoint retries on failure with exponential backoff, and you can set how many attempts it makes, anywhere from one up to ten, depending on how important that stream is. Payment events are de-duplicated by charge id before anything is counted or posted, so a webhook that Stripe re-delivers, which it does routinely, never shows up twice or inflates a total. When a source produces more volume than a channel can comfortably absorb, batch mode holds the events and posts a single summary instead of a flood. You choose how the batch flushes: on a schedule every few hours, once a certain number of events accumulate, or a hybrid of the two that sends whenever the first condition is met. High-value payment relays can also post a periodic revenue report on their own cadence, so the team gets a clean digest rather than a running commentary.

None of this asks anything of the system sending the webhook. Your app POSTs the event once and moves on. The retries, the ordering, the de-duplication, and the batching are handled on the receiving side, which is exactly where that logic belongs.

Reporting and stats, without a second tool

Once events flow into Slack for a few weeks, a pattern question arrives on its own. How many signups came through last month? Is transaction volume climbing? Which category is quietest? Answering that usually means exporting data somewhere and building a chart, which is a project nobody scheduled.

Viably keeps the answer next to the events. The Month in Review area of your dashboard charts every relayed event by category, one line per stream, so payments, signups, and leads each get their own colour. A cumulative toggle switches from daily volume to a running month-to-date total, which is the view you want when you are asking whether a number is growing rather than how a single day went. Because the chart is built from the same events you already relay, there is nothing extra to instrument. The reporting is a byproduct of using the relay, and it looks back across earlier months on the paid plan so trends have room to show themselves.

Logs and diagnosis when something looks off

Reliable delivery still needs a way to answer the question every integration eventually raises: did that event actually arrive, and if not, why. Guesswork here is expensive, because the person asking is usually mid-incident.

Each endpoint keeps its own activity log with a clear tally of what happened. You can see how many events were delivered, how many failed, and how many were dropped, alongside the time of the most recent one, so a glance tells you whether the stream is healthy. When batch mode is on, a separate view lists the events currently queued and waiting for their next flush, and a Flush Now control sends them immediately when you would rather not wait. Failed deliveries carry enough context to point at the cause, whether that is a channel the bot was removed from or a payload that arrived malformed. If a token is ever exposed, you rotate it in place and the old one stops working at once, without tearing down the endpoint or losing its history.

Setup is a single slash command

For all of that capability, standing up a relay takes about a minute. Inside Slack you run /webhook-relay, which opens the endpoints for your workspace, and you create one for the source you want to connect. You can also manage everything from the web command center if you prefer a larger canvas. Either way you get a relay URL and a bearer token, and your app starts posting to it.

The payload is deliberately plain. POST a JSON body with a title, some text, and optional fields, include the token, and Viably formats a tidy Block Kit message and delivers it to the channels you chose. Services that cannot set an Authorization header, Stripe among them, can pass the token as a query parameter instead, so even rigid webhook senders integrate without a proxy in front of them. All of this is available on the free plan, retries and reporting and logs included, which means you can prove the workflow end to end before it ever costs anything.

POST https://hq.viably.app/relay
Authorization: Bearer <your-token>
Content-Type: application/json

{
  "type": "signups",
  "title": "New Pro signup",
  "source": "app.example.com",
  "fields": { "Plan": "Pro", "Seats": 12 }
}

Where to go next

An event-driven workforce is less about any single integration and more about a decision to let the systems your team relies on speak up in the room where the team already works. Sending the webhook is step one. Deciding which events deserve a channel, who owns each one, and how to keep the signal clean is the craft, and that is the subject of part two in this series.

When you are ready to wire up a source, the Webhook Relay guide covers the generic payload in full, and Stripe to Slack walks through payments end to end. If you would rather start by seeing an event land in your own channel, add Viably to Slack and run /webhook-relay.