Webhook and MongoDB: Idempotent Event Store Template
A Webhook trigger writes each inbound event to MongoDB exactly once by checking a unique event id first, so provider retries and replays never create duplicates.
What It Builds
This Spojit template starts with a Webhook trigger that receives an external HTTP POST, then uses a Connector node on the mongodb connector in Direct mode to look up the incoming event id with find-documents. A Condition node branches on whether the event already exists: if it is new, a second mongodb Connector node runs insert-documents to store the full event; if it already exists, the run ends without writing. The result is a durable event store where each event id appears once, no matter how many times the provider re-sends it.
The Prompt
Paste this into Miraxa and it builds the workflow, connecting the tools for you:
Build a workflow with a Webhook trigger that receives event payloads. First use a MongoDB Direct-mode Connector node to look up the incoming event id in the "events" collection. Add a Condition node: if no matching document was found, insert the full event into the "events" collection with its event id, type, payload, and received timestamp; if a match was found, stop without inserting so duplicate retries are ignored.
Connectors Used
- Webhook trigger - receives the external HTTP POST and exposes the parsed body as
{{ input }}. - mongodb -
find-documentschecks for the existing event id, andinsert-documentsstores the new event.
Customize It
Change the collection name (events) to match your store, and point the lookup at whichever field carries the provider's unique id, such as {{ input.id }} or {{ input.event_id }}. You can also enrich each stored document with extra fields from the payload (customer, amount, status) before the insert, or add a unique index on the event id field in MongoDB so the database rejects duplicates as a second line of defence.
Tips
- Keep both mongodb Connector nodes in Direct mode: the lookup and the insert are predictable single-tool calls, so you avoid AI cost and get the same behaviour on every run.
- For the strongest guarantee, enable the Webhook trigger's opt-in dedup via the event-id header so Spojit drops obvious replays before the workflow even runs, then rely on the MongoDB check for anything that slips through.
- Store the raw payload alongside parsed fields so you can replay or audit events later without losing data the provider sent.
Common Pitfalls
- Picking a field that is not actually unique (such as a customer id) lets real distinct events collapse into one record. Use the provider's event id, which is unique per event.
- Without a unique index on the id field, two near-simultaneous retries can both pass the lookup before either inserts. Add the index in MongoDB so duplicate inserts fail safely.
- Skipping HMAC verification on the Webhook trigger lets anyone post fake events. Always attach a signing connection so only your provider's signed requests are accepted.
Related
- How to Build a Webhook-Triggered Order Processing Workflow for the full step-by-step on consuming inbound webhooks.
- How to Export BigCommerce Orders to MongoDB shows another pattern for writing event data into MongoDB.
- Using Connector Nodes in Direct Mode covers the deterministic mode this template relies on.