Send warm visitor alerts to Slack or an HTTPS webhook

Save the destination

1. 1
   Create the receiver.

   For Slack, create an Incoming Webhook for the channel that should receive leads. For an HTTPS receiver, prepare a public endpoint on port 443. URLs with credentials, fragments, private-network addresses or redirects are not supported.

2. 2
   Open Buyers → Who is buying → Almost buying.

   In Slack / Webhook alerts, choose the destination type and paste the webhook URL. URLs contain secrets and are stored encrypted in Vault; later reads show only the destination's origin.

3. 3
   Choose contact sharing and save.

   Known name, email and company fields are omitted by default. Enable the checkbox only when those fields should go to this destination. Page paths, source and recorded intent text are still sent. Choose a destination appropriate for the information recorded by your website.

• Create a Slack Incoming Webhook

Test, then send a visitor

Test saved destination sends a connection message with no visitor information. Wait 30 seconds after a test before choosing Send alert beside a warm visitor. The server checks website permissions and reloads the visitor's current qualification for the selected dates before sending.

One attempt is allowed per website every 30 seconds. A successfully sent visitor cannot be sent again for 15 minutes. A receiver's successful HTTP response confirms acceptance, not that a person read the message. There are no automatic retries. A timeout may happen after a message was received, so check the destination before retrying.

Removing a destination deletes its stored secret and stops future sends. Existing messages remain in Slack or the receiving service. A saved disabled destination from an earlier version remains disabled until you save it again.

HTTPS payload fields

Query strings and fragments are removed from lastPage. Stored page paths and signal text may still contain customer-entered information. Receiving systems should deduplicate events using id rather than assuming repeated HTTP requests describe different leads.

Verify an HTTPS signature

Copy the signing secret immediately after saving an HTTPS destination. It is shown once and is not included in later settings reads. Saving again rotates it. Keep it on your receiver's server.

X-Attriboo-Timestamp is the Unix time in seconds. X-Attriboo-Signature is v1= followed by the hex HMAC-SHA256 of timestamp + a period + the exact request-body bytes. Check signatures before parsing or acting on the JSON, reject timestamps outside a five-minute window and deduplicate accepted event IDs.

import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifyAttriboo(rawBody, headers, secret) {
  const timestamp = headers.get('x-attriboo-timestamp') || '';
  const signature = headers.get('x-attriboo-signature') || '';
  if (!secret || !/^\d{10}$/.test(timestamp) || !/^v1=[a-f0-9]{64}$/.test(signature)) return false;
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;
  const expected = createHmac('sha256', secret)
    .update(timestamp + '.').update(rawBody).digest();
  return timingSafeEqual(expected, Buffer.from(signature.slice(3), 'hex'));
}