Send events from your site to Slack

Send form submissions, payments, deploys, and signups to Slack with one relay endpoint. No server is required.

Trigger: POST /relay
Lands in: The relay log, plus any channel you route to
Setup: 3 min
Needs: anything that can send a http POST

#growth

ViaApp11:04 AM

New signup from Dunder Mifflin

[email protected] · via My Site, Signup Page

Type: signups
Plan: pro
Campaign: spring-launch
Submitted at: 11:04 AM

Open the contact

The same POST shape carries every event type. Where each one lands, and how it batches, is decided per type in the dashboard.

What this guide produces, as it appears in Slack.

How it works

Before you start

Invite @Via to the Slack channel where you want webhooks to appear. Without this, Viably accepts your webhook but cannot post to the channel.

Step 1Create an endpoint

Create a relay endpoint in the Viably dashboard and attach the Slack channels you want it to use.

Step 2POST a JSON payload

Send a POST from your site or backend with the data for the event. Include a type field to route it correctly.

Step 3See it in Slack

Viably formats the payload and posts it to Slack immediately or in a batched card, depending on how the type is configured.

Environment variables

After creating an endpoint in the dashboard, add these to your project's environment.

.env

VIABLY_RELAY_URL=https://hq.viably.app/<your-endpoint-provided>
VIABLY_RELAY_TOKEN=<your-secret-token>

Both values are shown in the dashboard immediately after creating an endpoint. Your token is only displayed once, so store it somewhere safe.

TypeScript types

Drop this into your project as viablyTypes.ts. Each event type carries its own recommended fields, and Viably surfaces a hint in Slack when a recommended field is missing.

viablyTypes.ts

// viablyTypes.ts

export type ViablyEventType =
  | "transaction"
  | "leadgen"
  | "signups"
  | "contactform"
  | "devops"
  | "others"
  | "ocr";

type ViablyPayloadBase = {
  /** Routes the event to the right Slack template. Defaults to "others" if unrecognised. */
  type: ViablyEventType;
  /** Recommended. Identifies the origin, e.g. "My Site — Contact Page". */
  source?: string;
  /** ISO 8601 timestamp. Viably formats it using your workspace timezone. */
  submitted_at?: string;
/* Optional. */
  event_id?: string;
  /** Override the default Slack channels set in your dashboard. */
  channels?: string[];
  [key: string]: unknown;
};

Sending a payload

A minimal helper and three common usage examples. Any additional fields you include beyond the recognised ones appear in the Slack message as extra context.

// lib/viably.ts
import type { ViablyPayload } from "./viablyTypes";

export async function sendToViably(payload: ViablyPayload): Promise<void> {
  const res = await fetch(process.env.VIABLY_RELAY_URL!, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.VIABLY_RELAY_TOKEN}`,
    },
    body: JSON.stringify(payload),
  });
  if (!res.ok) throw new Error(`Viably relay failed: ${res.status}`);
}

// --- Contact form submission ---
await sendToViably({
  type: "contactform",
  source: "My Site — Contact Page",
  message: form.message,
  email: form.email,
  name: form.name,
  company: form.company,
  submitted_at: new Date().toISOString(),
});

Event types

The type field routes the event to the matching Slack message template. If omitted or unrecognised it falls back to others. Viably adds an inline hint to the Slack message when a recommended field is absent.

type	Description	Recommended fields
`transaction`	Payments, purchases, and financial events. Only an endpoint with the Payments or Stripe integration enabled can produce this type, and a payload cannot select it on a plain relay endpoint. See Custom event types below.	`amountemailnamecompany`
`leadgen`	Lead captures, downloads, and gated content fills	`emailnamecompany`
`signups`	New user or account registrations	`emailnamecompany`
`contactform`	Contact or enquiry form submissions. Someone is waiting on an answer, so these arrive in your Contacts queue as answerable and your team can reply by email from Slack.	`messageemailnamecompany`
`devops`	Deployments, CI/CD results, and infrastructure alerts	`titlestatus`
`others`	Anything that does not fit a specific category	none
`ocr`	Reserved for Viably OCR integrations. Results are silently routed back to the originating Slack thread, and nothing is posted to the relay's configured channel.	`job_idmessagepart`

transaction, ocr, inbox, and reply are reserved

No payload can declare itself one of these four on any endpoint. Each one means something specific enough that letting any sender claim it would be a problem: transaction counts toward your revenue figures, ocris Viably's own document pipeline, and inbox and reply decide which side of a conversation an email sits on. Send one of these four as your type to a relay endpoint that was not built for it, and Viably treats it exactly as it treats any other unrecognised value. The event still reaches Slack under others, quietly, with no error returned but resulting in no contact or revenue captured from it.

Every person event builds a contact

A leadgen, signups, contactform, or transaction event does more than post to Slack. It creates or updates a contact, keyed on the email address, so the same person's enquiry, signup, and payment gather on one record you can work, answer, and attribute revenue to. See the Lightweight CRM guide for what that record does for you.

email, name, and company on person events

All three are optional on leadgen, signups, contactform, and transaction, and all three are worth sending. email is the identity key your Contacts list is built on, so a lead captured in June and a payment in July resolve to the same person, and your periodic report can tell you how much revenue that lead eventually brought in. name and company are what turn that row into something a human can act on. Without them you still get the Slack message, but the contact arrives as a bare address with nobody to greet.

source, on every type

A human-readable label for the origin of the event, such as "My Site — Contact Page". Viably uses this for footer attribution on every message. If omitted, it falls back to the HTTP Referer or Origin header, then to the domain you set on the endpoint in the dashboard.

submitted_at, on every type

An ISO 8601 timestamp for when the event occurred, such as new Date().toISOString(). Viably formats it using your workspace's default timezone and displays it as a Submitted at field in the Slack message. If omitted, no timestamp is shown.

Duplicate events

event_id is optional, and it is the single most useful optional field on this page. It is your own identifier for the event a payload describes, and sending it is how you tell Viably that two deliveries are one event.

What it saves you from

A webhook retried after a timeout, a proxy that replays a request, or a form somebody submitted twice all arrive as two deliveries of one thing. Without an id to match them on, that becomes two lines on the Slack card, two touches on the contact record, and two captures billed against your plan. It also moves numbers you make decisions from: a contact with two events reads as somebody who came back, so the same person shows up under engaged rather than dormant in your acquisition figures. Send event_id and Viably remembers it for 24 hours, so the second delivery is dropped before any of that happens.

What happens when you omit it

Nothing breaks. Viably collapses them on order_id, and Stripe events on Stripe's own event id. For everything else it falls back to comparing the payload, and treats an identical body carrying the same email address inside ten minutes as one event. That window is deliberately short, because two identical bodies a week apart are usually one person genuinely signing up again, and a fallback cannot tell the difference. An event_id can, so Viably has something to reliably match on.

Keep the value stable, or send nothing at all

The one rule: if the same event were relayed twice, both calls have to produce the same string. Derive it from the row the event created, from the event's own timestamp, or from a hash of the submission. A database id is ideal, so signup:8814 is perfect.

Calling crypto.randomUUID() as you post the webhook is worse than sending nothing at all. A supplied event_id is taken as your word on which deliveries are the same event, so a fresh one per request means no two deliveries ever match.

If there is no row to name

Some events have nothing durable behind them. A newsletter form that posts straight to Viably has no subscription record to borrow an id from, and there the honest key is the person and the day: newsletter:[email protected]:2026-07-30. Subscribing twice in an afternoon is one subscription, coming back in March is a second, and that is exactly what the id then says. Avoid making it stable forever in this case, because Viably stores your id on the contact event under a unique index: somebody genuinely resubscribing next month would post to Slack and then be dropped from your CRM without a word.

Custom event types

The six types above are the ones Viably ships with, and they are not the limit. Send type as any lowercase value that starts with a letter and uses only letters, digits, and underscores, up to 64 characters, and it works the first time you send it. support_ticket, plan_upgraded, and nps_response are all valid without asking anyone for permission first.

A new type relays before it captures

The first delivery of a type nobody has sent before reaches Slack immediately, formatted the same generic way othersis, and it registers itself in your workspace's event catalog at the same time. What it does not do on its own is create or update a contact. An admin has to open that catalog and decide what the type means, whether it should capture a lead, a signup, or a customer, and whether your team is expected to reply, before it does anything beyond posting a message. A string a payload happens to carry should never be able to start writing into your Contacts or your revenue figures before a person on your team agreed that it should.

One token, as many types as your product actually emits

There is rarely a reason to create a second endpoint just because you want to track a second kind of event. A contact form, a signup flow, and a handful of custom milestones your product wants tracked, such as an onboarding step finished or a referral made, can all post through the same token, and Viably tells them apart by type alone. See Routing multiple event types for how to send different types to different channels without touching your integration code.

A workspace can register up to 200 distinct types

That is a generous ceiling for how many kinds of event one product realistically emits, and it mainly exists to stop a runaway sender, such as a bug that mints a fresh type name on every request, from filling the catalog and the batching queue behind it. Once a workspace reaches that ceiling, a further novel type name is treated as unrecognised and falls back to others, the same as a malformed one, so an integration never breaks outright over it.

Reporting

Every event you deliver is recorded for reporting. In the Month in Review area of your dashboard, Viably charts your webhook volume by category, so you can follow how signups, transactions, and other event types move through the month.

Extended webhook reporting

Available on Viably+. Your relay history is kept for several months, so the trend chart in Month in Review can reach back across earlier months when you want to compare periods or follow a longer pattern. Free workspaces keep the current billing period in their charts.

Channel override

By default, events are posted to the Slack channels you configured on the endpoint. You can override this per event by including a channels array in your payload. If Viably cannot access any of the override channels, it falls back to the endpoint defaults automatically.

// Send to specific channels, overriding the defaults in your dashboard
await sendToViably({
  type: "devops",
  source: "GitHub Actions",
  title: "Production deploy",
  status: "deployed",
  channels: ["C0123456789", "C9876543210"], // Slack channel IDs
});

Channel IDs can be found by right-clicking a channel in Slack, choosing View channel details, and copying the ID at the bottom.

Routing multiple event types

One endpoint token is not limited to one kind of event. Send signups and a custom type like support_ticket through the same token, and both still reach Slack, because type alone decides which template renders an event. What differs, if you want it to, is not in your code at all.

// Same token, same POST target, two different event types. Nothing about
// this call changes based on which type you send. Where each one lands in
// Slack, and how it batches, is decided per type in your dashboard, not here.
await sendToViably({
  type: "signups",
  source: "My Site — Signup Page",
  email: user.email,
  name: user.name,
});

await sendToViably({
  type: "support_ticket",
  source: "My Site — Support Widget",
  email: user.email,
  message: ticket.body,
});

Where each event lands, from your dashboard

Open your endpoint and you will find a panel by that name. Once a type has arrived at least once, an admin can point it at its own Slack channels, its own batching interval, or its own task-assignment rule, independent of the endpoint's own defaults and independent of every other type sharing the token. support_ticket can post immediately to a support channel while signups keeps batching every six hours into a growth channel, and changing one never touches the other, even though both arrived through the same POST shape and the same bearer token.

How this differs from the channels field above

channels is something your code decides, request by request, and it always wins over everything else. Where each event lands is something an admin decides once, per type, from the dashboard, and it is what a type does by default when your payload does not name a channel override itself. Most integrations never need channels at all once routing is set up this way, since the decision already lives on the type rather than needing to be repeated on every send.

In practice, one endpoint per site is usually enough

A contact form, a signup flow, a payments rail that needs its own adapter, and a handful of custom milestones can coexist as separate tokens if that is simpler for your team to reason about, though they do not have to. If the only reason you were about to create a second endpoint was to send a new kind of event somewhere else in Slack, routing that type from the dashboard usually gets you there with one fewer secret to carry in your codebase.

What a batched card shows

A type that batches does not post one card per event. Viably holds the events for the interval you set, then posts the whole flush as one card with a sortable table in it. The columns are not a fixed list. They are built from the payloads in that flush, so the fields you send are the fields your team reads.

Recognised fields come first. name, email, company, amount, plan, status and the rest of the vocabulary keep a fixed order, so two flushes of the same type read the same way.
Then your own fields. Any other value you send becomes a column, ranked by how many events in the flush carry it. A hackathon portal sending team_name and requested_by gets a column for each. Nested objects and arrays are skipped, and so are event_id and contact_id, which are plumbing rather than news.
title names the kind of event. One kind in the flush and it is stated once above the table. Several kinds and it becomes an Event column, with a count per kind above it.
Numbers stay numbers. A field whose every value is a number gets a column that sorts by size, so a score of 80 ranks above a score of 9 rather than beside it alphabetically. The When column carries the date as well, once a flush spans more than one day.
A source every event shares moves to the footer. A mixed flush keeps it per row instead, where it is the fact that tells two otherwise identical rows apart.

Getting a table worth reading

Send the same field set for every event of a type and the table comes out square. Keep values short enough to sit in a cell, and put anything long in message, which is placed last. A card holds seven columns and a hundred rows, ten to a page. Send more fields than that and the card names the ones it could not fit, so you can see what is missing and trim the payload. A flush that turns out to hold a single event posts the normal single-event card instead.

Auto-create tasks

Every endpoint has an optional Spawn a task toggle in the dashboard. When it is on, each delivered event also creates a task, posted as a claimable card threaded under the Slack notification, so events that need follow-up always have an owner.

Assign it, or leave it up for grabs. Route the task to a specific teammate, or leave it unassigned so anyone can claim it in Slack.
It is a real task. The card carries Claim and Mark Done buttons, and the task shows up on your board, in the Weekly Digest, and in follow-ups, identically to a task created by a clipboard reaction.
Non-Stripe endpoints spawn a task on every single non-batch delivery, one per lead, contact-form fill, signup, deploy, and so on.

Condition	Spawns a task when
`New subscription`	A subscription becomes active, as when a trial converts, so you can assign someone to onboard the new customer.
`Set to cancel`	A customer schedules a cancellation, so you can assign your customer success manager to reach out and recover the account before the period ends.
`Successful payment`	A charge succeeds, which is useful for high-touch follow-up on new or large transactions.

The headline use case

Point a Stripe relay at your billing events, turn on Set to cancel, and assign your customer success manager. Every time someone schedules a cancellation, a recovery task lands in Slack with their name on it, and churn becomes a worklist rather than a surprise.

Stripe Integration

Viably can receive events directly from Stripe and post them to Slack. Because Stripe webhook destinations post to a plain URL, you must use the query-param token format rather than the Bearer authorization header.

1
Create a relay endpoint
In the Viably dashboard, create a new relay endpoint with Stripe Integration enabled. Once created, open the token dialog and copy the Stripe or query-param URL. It looks like https://hq.viably.app/relay?token=….
2
Create a webhook destination in Stripe
In your Stripe Dashboard, go to Developers → Webhooks → Add destination. Paste the Viably query-param URL as the Endpoint URL. Select these two events: charge.succeeded and customer.subscription.updated.

charge.succeededin particular captures all your successful transactions in Slack, whether they originated from Stripe Checkout or from your own custom integration using Stripe's APIs. Viably looks for this event's payload to extract the correct amount, currency, and description to build your transaction messages in Slack.

You should not send any other Stripe events to this Webhook Relay endpoint, since that can cause an unexpectedly heavy load of messages in your workspace, and even double notifications or double-counting in revenue tracking.
3
Copy the signing secret
After saving, Stripe displays a signing secret beginning with whsec_. Copy it to complete your setup on Viably. If you miss it, you can reveal or roll it from the destination details page.
4
Complete setup in Viably
Back in the Viably dashboard, click Edit on the relay endpoint. Paste the whsec_… value into the Stripe webhook secret field and save. Viably will now verify every incoming Stripe request and reject anything unsigned.
5
Test it
Use Stripe's Send test event button on the destination page to fire a sample event. Check your configured Slack channel, where you should see a formatted message within a few seconds.

Why the query-param URL

Stripe webhook destinations send a plain POST and do not support custom Authorization headers. The ?token=… format is the Viably-supported alternative for these integrations, and both URLs are shown in the token dialog after endpoint creation.

Event	How Viably renders it
`charge.*`	Transaction card carrying amount, customer name, email, phone, and location from billing_details. In batch mode, each charge is a row in a per-transaction table.
`customer.subscription.updated`	Informational card showing plan, price, and customer ID. Automatically detects cancellation, new activation, or a generic update. It can also spawn a recovery task on a set-to-cancel event, covered under Auto-create tasks. Rapid-fire events for the same subscription within about 90 seconds are deduplicated.

Campaign attribution

Most teams can tell you how many people a campaign reached. Far fewer can tell you what those people went on to spend, because the campaign is recorded in the ad platform and the revenue is recorded somewhere else entirely, and nothing joins the two without somebody exporting both and reconciling them by hand. Viably closes that gap as a side effect of capturing the contact, and it asks nothing of you beyond the page URL your form already knows.

Send the page, get the campaign

Include current_page_url in your payload and Viably reads utm_source, utm_medium, utm_campaign, utm_content, utm_term, utm_id, and utm_author off the query string your ad platform appended when the visitor clicked. If you post your own JSON and the URL is not to hand, send those fields directly and they are read the same way. Nothing else changes about your integration.

Everything else on the link is kept too

The click and network ids an ad platform adds, such as fbclid, gclid, and the hsa_*cluster, are captured alongside the campaign rather than dropped. Each one shows up as its own entry under Captured data on the contact, ready to promote into a field the moment you want to match it against your ad platform's own reporting, so a new parameter from a new platform can be captured automatically without any additional setup.

The campaign that won them keeps the credit

Attribution is recorded on first touch and stays there for the life of the contact. Someone who arrives through a spring promotion and buys again in November is still counted towards the spring campaign, so a campaign that brings loyal customers goes on earning its reputation long after the spend stopped. That is usually the difference between a channel that looks expensive on the day and one that turns out to have been the best money you spent all year.

Where to read it today

Open anyone on the Contacts page and the campaign that brought them sits directly beneath the page that found them, so an enquiry landing in Slack this morning becomes an enquiry you can trace back to the ad that paid for it. For the wider view, every contact export carries UTM source, UTM medium, and UTM campaign as columns beside the source, which is enough to pivot a spreadsheet by campaign and see what each one went on to earn without touching another tool. Contacts captured before you started tagging links carry empty cells, because the columns are fixed so that a file you built a pivot on keeps working next month.

Why the campaign is stored apart from the source

One landing page can run a dozen campaigns over a year, and one campaign can drive traffic to several pages. Folding the two together would file every campaign as its own channel and scatter a page's revenue across a dozen rows that each look too small to matter. Keeping them as separate fields means you can query which page converts and which campaign paid off independently.

Any extra fields are welcome

Beyond the recognised fields, you can include anything in the payload, whether that is city, plan, or your own custom metadata. Viably renders them as additional context in the Slack message so nothing is lost. One of them earns special treatment: current_page_url is also read for campaign tags, which is covered above.

Common questions

What teams ask before they turn this on.

What do I need to run to receive webhooks?

Nothing. Viably hosts the endpoint, so your app only needs to send a single POST request.

Can one endpoint handle different kinds of event?

Yes. The payload's type field picks the Slack template and routing, so one endpoint can handle signups, contact forms, deployments, and custom events.

Do webhook events do anything beyond posting to Slack?

Yes. Person events create or update a contact, so a signup, form submission, and payment can all land on the same record.

Can we send events to different channels?

Yes. Each endpoint has default channels, and any payload can override them with a channels array.

Get started

Create your first endpoint from the Webhook Relay page. It takes one POST to see an event land in Slack.

Add Viably to Slack

See it in actionLogs and observability