Send events from your site to Slack

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.

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.

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.

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.

Nothing breaks, and payments are already covered: 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, which is the whole reason to send one.

The first delivery of a type nobody has sent before reaches Slack immediately, formatted the same generic way others is, 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.

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.

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.

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.

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.

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.

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.

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 needs nothing from us to be waiting for you.

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.

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 ask which page converts and which campaign paid off, and get an honest answer to both.

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.