Slack Alerts

TrustLens doesn’t ship a dedicated Slack app or a “Slack” notification channel with its own settings screen. Instead, Slack is reached through webhooks — and because Slack’s Incoming Webhooks accept a simple JSON body, you can route TrustLens events into a Slack channel using the tools the plugin already provides. This page explains the two supported paths, exactly what each one sends, and how to format a payload Slack will render nicely.

---

The Two Ways to Reach Slack #

Path	What it sends	Where it’s configured
Automation “Fire webhook” action (Pro)	Any trigger you build a rule for — segment change, chargeback filed, linked accounts detected, etc.	The rule’s webhook action (see Actions Reference)
Card-Testing Defense Pro alerts	Card-testing attack / auto-escalation / Panic Freeze alerts	The card-testing alert Slack webhook option

Both ultimately POST JSON to a Slack Incoming Webhook URL. There is no separate per-channel routing UI, no Block Kit builder, and no “Slack” tab — routing is simply a matter of which webhook URL (and therefore which channel) you point each path at.

---

Path 1: Automation “Fire Webhook” Action #

This is the flexible path and the one most stores use. Any Pro automation rule can fire a webhook when its trigger and conditions match, and that webhook can be a Slack Incoming Webhook.

1. In Slack, create an Incoming Webhook for the channel you want alerts in.
2. Copy the webhook URL (it looks like https://hooks.slack.com/services/T.../B.../...).
3. In TrustLens, build an automation rule and add a Fire webhook action pointing at that URL.

By default the automation engine sends a generic JSON payload (and signs it with HMAC-SHA256 — see Webhooks and HMAC). Slack’s Incoming Webhooks expect a text field, so if you want a readable message rather than a raw event object, format the payload like this:

{
  "text": "Chargeback filed for ${order.total}",
  "attachments": [
    {
      "color": "#cc0000",
      "fields": [
        { "title": "Customer", "value": "${customer.email}" },
        { "title": "Score", "value": "${customer.score}" },
        { "title": "Brand", "value": "${dispute.brand}" }
      ]
    }
  ]
}

Because the engine treats every webhook receiver identically, the same approach works for Microsoft Teams, Discord, PagerDuty, or any custom HTTP endpoint — only the payload shape changes.

---

Path 2: Card-Testing Defense Pro Alerts #

Card-Testing Defense Pro has its own alert dispatcher that can notify you when an attack is detected, when auto-escalation triggers a Panic Freeze, and when Panic Freeze is activated manually. It sends to an email address and/or a Slack Incoming Webhook.

The Slack message is a simple payload — a bold title line plus an attachments block with key/value fields — not Block Kit. A typical message looks like:

*TrustLens — attack_detected*
fingerprint: …, declines: …, window: …

The card-testing alert Slack webhook is stored as a plugin option (trustlens_card_testing_alert_slack_webhook) rather than a labelled field on a settings screen, so it’s typically set programmatically or via a filter. If you want richer, fully-controlled card-testing alerts in Slack, build an automation rule on the Card Testing Attack trigger with a Fire-webhook action instead (Path 1) — that gives you the full payload control shown above.

---

Rate Limiting #

Slack imposes its own rate limits on Incoming Webhooks (roughly one message per second per webhook). A burst-heavy event — such as a rapid card-testing attack — can produce many triggers in a short span. To stay within Slack’s limits and avoid noise, put a cooldown on any automation rule that targets Slack, and consider sending high-volume events to a lower-traffic digest channel.

---

Security #

A Slack Incoming Webhook URL is effectively a password — anyone with the URL can post to that channel. Treat it accordingly:

1. Store it only where you’d store other secrets.
2. If a webhook URL leaks, regenerate it in Slack immediately and update it in your rule or option.
3. Review the channel history for unauthorized messages after any suspected leak.

Automation webhooks are additionally signed with HMAC-SHA256 (the X-TrustLens-Signature header), but note that Slack’s Incoming Webhooks don’t verify that signature — it’s there for your own receivers. See Webhooks and HMAC.

---

Beyond Slack #

Slack is just one destination. The same automation “Fire webhook” action can target:

• Microsoft Teams (Incoming Webhook with an adapted payload)
• Discord (different webhook payload format)
• PagerDuty (its Events API)
• Any custom HTTP receiver — and those can verify the HMAC signature

The engine treats all webhook receivers identically; Slack is documented here only because operational alerting is the most common use case.