Webhook and Slack: At-Least-Once to Exactly-Once Dedup Template

A Webhook trigger records each event id in MongoDB before doing anything else, so a retried or duplicated delivery never posts the same Slack alert twice.

What It Builds

This Spojit template starts from a Webhook trigger that an upstream system POSTs events to. The first step is a Connector node on mongodb in Direct mode that attempts to insert a record keyed on the event id. If the id is new the insert succeeds and the workflow continues to a Connector node on slack that posts the alert; if the id already exists the insert is rejected and a Condition node short-circuits the run so no duplicate side effect happens. The MongoDB record is your dedup key: it turns the webhook's at-least-once delivery into exactly-once notifications.

The Prompt

Paste this into Miraxa, the intelligent layer across your automation, and it builds the workflow, connecting the tools for you:

Build a workflow with a Webhook trigger that receives events. First add a MongoDB Connector node in Direct mode that inserts a document into a "processed_events" collection keyed on the incoming event id, treating that field as a unique dedup key. Add a Condition node: if the insert succeeded because the id was new, post a message to the #alerts Slack channel summarizing the event; if the id was already present, end the run without posting so the same event never notifies twice.

Connectors Used

Webhook trigger - external systems POST events to the workflow URL; enable the opt-in event-id header so each delivery carries a stable id to dedup on.
mongodb - stores one record per event id in a processed_events collection and rejects repeats, acting as the exactly-once gate.
slack - posts the alert to a channel with send-message only after the event is confirmed new.

Customize It

Change #alerts to your channel, rename the processed_events collection, and point the dedup key at whichever field your sender provides as a stable id (for example {{ input.id }} or an order number). To expire old records so the collection does not grow forever, store a timestamp alongside the id and prune on a schedule. To fan the notification out to email as well, add a Send Email node on the same success branch.

Tips

Keep the mongodb node in Direct mode: deduplication is a deterministic single-tool call, so it adds no AI cost and behaves predictably under load.
Insert the dedup record before the Slack post, not after, so a crash between steps still leaves the id marked and a retry stays silent.
Use the same field the sender guarantees is unique per event; if you dedup on a value that can repeat for distinct events, you will drop real alerts.

Common Pitfalls

If your sender does not include an event-id header, two genuine retries look identical only by body content; have it send a stable id, or build the key from fields that uniquely identify the event.
Without a unique index on the dedup field in MongoDB, two near-simultaneous deliveries can both insert and both notify; enforce uniqueness on the id field in the collection.
Posting to Slack first and recording the id second reopens the duplicate window; always write the dedup record first.