How to send Digital Empire alerts to Slack

Every product in the Digital Empire portfolio -- PixelProof, EntryProof, TariffWatch -- can post alerts directly to a Slack channel via an Incoming Webhook documented on api.slack.com. This guide walks the create-app path (recommended for a single channel) and calls out the Bot Token path (recommended if you already run a Slack app for other reasons).

The 4-step Incoming Webhook setup

Slack Incoming Webhooks are the most compatible integration path. Any Slack workspace at any plan can create one, and the URL is opaque enough that our alert dispatcher can post to it with no other configuration on your side.

Sign in to the Slack workspace you want alerts to land in and go to the Slack app management console at api.slack.com/apps. Click "Create New App," pick "From scratch," name it something like "Digital Empire Alerts," and pick the target workspace.

In the left sidebar of the newly created app, click "Incoming Webhooks" and toggle "Activate Incoming Webhooks" to on.

Scroll to the bottom of the same page and click "Add New Webhook to Workspace." Pick the channel you want alerts posted to (private channels also work, but see the troubleshooting section). Slack redirects you back to the app page with the new webhook URL listed.

Copy that URL and paste it into the "Webhook URL" field on the Digital Empire integrations page for your product (PixelProof, EntryProof, or TariffWatch), pick "Slack" as the channel type, set the severity floor, and save.

Screenshot placeholder -- Slack "Add New Webhook to Workspace" screen. Andy will upload the real screenshot after wire-up.



What we actually send to Slack

Once you save the webhook, our dispatcher formats every triggered alert as a Slack-native attachments array so it renders with color coding and inline fields rather than as a wall of text. Critical and high-severity alerts render in red (color: "danger"), medium in amber, low in green. This matches the Slack attachments legacy format documented at api.slack.com. The payload we post looks like this:

{ "text": "Pixel break on your-store.myshopify.com", "attachments": [{ "fallback": "Pixel break on your-store.myshopify.com", "color": "danger", "title": "Pixel break on your-store.myshopify.com", "title_link": "https://digital-empire-app.vercel.app/meta-monitor", "text": "The Meta Pixel is no longer firing PageView on your product pages.", "fields": [{ "title": "Severity", "value": "critical", "short": true }, { "title": "Event", "value": "pixel_missing", "short": true }], "ts": 1755993600 }] }

The fields array carries per-event context -- for PixelProof, the store domain and finding type; for EntryProof, the eFiling batch id; for TariffWatch, the HTS code that moved.

Severity filter, test-alert button, rate limits

On the integrations page you can set a severity floor -- alerts below that severity are silently skipped. If you pick "high," only high and critical alerts post to Slack; medium and low get suppressed. Every product uses the same four-tier ladder: critical, high, medium, low.

The "Send test alert" button on the integrations page fires a synthetic alert through the dispatcher so you can confirm the wire before a real event triggers. If it lands in the target Slack channel, the wire is working end to end.

We cap dispatched alerts to 10 per hour per webhook. If a burst of alerts exceeds that, the overflow is skipped and counted in the skipped_rate_limit metric on your integrations page. This is intentional -- Slack Incoming Webhooks have their own per-workspace rate limits documented in the Slack API rate limits reference at api.slack.com (approximately one message per second per webhook, with short bursts), and 10/hr keeps us well under that ceiling. As of Aug 2026 -- verify current if you rely on burst behavior.

Security -- a webhook URL is an API secret

The Slack webhook URL is not a public identifier. Anyone who has that URL can post messages into that channel as if they were you. Treat it like a database password: never paste it into a public repo, a client-side JavaScript bundle, or a public support ticket. If a URL leaks, delete the webhook in the Slack app dashboard and generate a new one -- Slack invalidates the old URL immediately.

Troubleshooting

The HTTP 429 status code we occasionally hit when Slack pushes back on burst posts is defined in RFC 6585 at rfc-editor.org -- our dispatcher treats a 429 as a rate-limit signal and does not retry.

The three most common Slack setup failures we see:

"Webhook posted 200 OK but no message in the channel" -- almost always a private channel that the webhook installer isn't a member of. Slack silently accepts the post but drops the message. Add the webhook installer to the private channel, or route to a public channel.

"App not authorized" during install -- your workspace admin has restricted third-party app installs. Ask an admin to approve the Digital Empire Alerts app (or any app you create for this purpose) in the Slack authentication best-practices reference at api.slack.com.

Alerts stopped posting after a burst -- our 10/hr rate limit fired and skipped the rest. Wait an hour, or raise your severity floor so fewer events qualify. The Slack side's own rate limit is much higher, so if you rely on lots of alerts per hour, consider Discord (much higher default limit) or PagerDuty (which dedupes automatically).

Bot Token path -- advanced

If you already have a Slack app with a Bot Token, you can use chat.postMessage with a bearer token instead of an Incoming Webhook. That path lets one Slack app post to any channel the bot is in, without provisioning per-channel URLs. The tradeoffs: bot tokens have wider blast radius if leaked, and you have to manage bot channel membership. The Slack authorization basics guide on api.slack.com covers scope requirements (chat:write at minimum). Most customers do not need this path -- the Incoming Webhook flow is simpler and equally supported.

Was this helpful?

Yes / No

Related articles

Send Digital Empire alerts to Microsoft Teams

Send Digital Empire alerts to PagerDuty

Send Digital Empire alerts to Discord

Custom webhook endpoints with HMAC verification

PixelProof customer webhooks admin

FAQ

Can I send different alert types to different Slack channels? Yes. Create one Incoming Webhook per channel in Slack, add each as a separate webhook row on the integrations page, and set a different event filter on each row.

Does Digital Empire retry failed Slack posts? Our dispatcher retries once on transient failures (5xx, timeout). If Slack rejects the payload as malformed (400) or the URL is deleted (404), we mark the webhook last_test_status failed and stop retrying until you re-save it.

Can I use one Slack webhook across PixelProof, EntryProof, and TariffWatch? Yes -- add the same URL as a Slack webhook on each product's integrations page. Alerts from all three products land in the same channel, distinguished by the title text.

What happens if my Slack workspace is deleted? The webhook URL 404s. Our dispatcher marks it failed and stops firing until you replace it with a working URL.

Still stuck? Email support@digitalempireholdings.com or support@digitalempireholdings.com.

FAQ

Can I send different alert types to different Slack channels?

Yes. Create one Incoming Webhook per channel in Slack, add each as a separate webhook row on the integrations page, and set a different event filter on each row.

Does Digital Empire retry failed Slack posts?

Our dispatcher retries once on transient failures (5xx, timeout). If Slack rejects the payload as malformed (400) or the URL is deleted (404), we mark the webhook last_test_status failed and stop retrying until you re-save it.

Can I use one Slack webhook across PixelProof, EntryProof, and TariffWatch?

Yes -- add the same URL as a Slack webhook on each product's integrations page. Alerts from all three products land in the same channel, distinguished by the title text.

What happens if my Slack workspace is deleted?

The webhook URL 404s. Our dispatcher marks it failed and stops firing until you replace it with a working URL.