The webhook bug that silently duplicates your automations (and how to kill it) The problem: Webhooks retry. If Stripe, Typeform, or your CRM doesn't get a fast enough response from Make, it resends the same event — sometimes minutes later. If your scenario isn't built to notice, you get duplicate orders processed, duplicate emails sent, duplicate rows created. This is one of the most common "why did this run twice?!" issues in Make. The fix (step by step): 1. Add a Data Store at the very start of your scenario (Make has this built in — no external database needed) 2. Right after your webhook trigger, add a "Search Records" step that checks the Data Store for the event's unique ID (order ID, submission ID, whatever the source provides) 3. Add a Router: if the ID already exists in the Data Store → stop the scenario here (use a Filter set to only continue if NOT found) 4. If it's new, add an "Add/Replace Record" step to save that ID to the Data Store, then let the rest of your scenario run as normal Why this works better: Most people try to solve duplicates with "just make the scenario faster" — but that doesn't fix the root cause. The Data Store check makes your scenario idempotent: no matter how many times the same event fires, it only actually processes once. This is the same pattern real engineering teams use, just built with modules instead of code. 🔧 Try it: Pick your webhook-triggered scenario that matters most (order processing, lead capture, form submissions) and add this check first — it takes about 10 minutes to set up. 💬 Has a duplicate webhook ever caused you a real headache? What happened?

For anyone who already joined before, the price stays the same but now for new people the price is 28$. As more content comes the price will increase gradually.

⚡ The webhook bug that silently duplicates your automations (and how to kill it) The problem: Webhooks retry. If Stripe, Typeform, or your CRM doesn't get a fast enough response from Make, it resends the same event — sometimes minutes later. If your scenario isn't built to notice, you get duplicate orders processed, duplicate emails sent, duplicate rows created. This is one of the most common "why did this run twice?!" issues in Make. The fix (step by step): 1. Add a Data Store at the very start of your scenario (Make has this built in — no external database needed) 2. Right after your webhook trigger, add a "Search Records" step that checks the Data Store for the event's unique ID (order ID, submission ID, whatever the source provides) 3. Add a Router: if the ID already exists in the Data Store → stop the scenario here (use a Filter set to only continue if NOT found) 4. If it's new, add an "Add/Replace Record" step to save that ID to the Data Store, then let the rest of your scenario run as normal Why this works better: Most people try to solve duplicates with "just make the scenario faster" — but that doesn't fix the root cause. The Data Store check makes your scenario idempotent: no matter how many times the same event fires, it only actually processes once. This is the same pattern real engineering teams use, just built with modules instead of code. 🔧 Try it: Pick your webhook-triggered scenario that matters most (order processing, lead capture, form submissions) and add this check first — it takes about 10 minutes to set up. 💬 Has a duplicate webhook ever caused you a real headache? What happened?

🚨 The first fully autonomous AI ransomware attack just got documented What happened: Security firm Sysdig published a breakdown of "JADEPUFFER" — a ransomware attack where an AI agent, not a human, chained the entire attack lifecycle on its own. It found an exposed Nacos service (a config/service-discovery tool), connected to its database as root, moved laterally, and deployed ransomware — start to finish, no human clicking through each step. Why it matters for automation builders: This isn't about AI being scary in the abstract — it's about exposed services. The attack worked because a service was reachable from the public internet with root-level database access and no restrictions on outbound traffic. That's the exact same shape as a lot of self-hosted tools, webhooks, and databases people connect to Make/n8n/Zapier stacks. The bar for running an attack like this has dropped to "cost of running an agent" — it doesn't take a skilled human anymore. My take: If you're running anything with a public endpoint — a webhook listener, a self-hosted database, an admin panel — this is your reminder to check: is it actually exposed to the open internet? Does the account it uses have root/admin rights it doesn't need? Can the server "phone home" if it's compromised, or is outbound traffic restricted? Basic hygiene stops this exact attack pattern. 💬 Anyone here running self-hosted tools (databases, n8n, custom APIs) that talk to your automations? Worth doing a quick audit this week.

Lets keep going watch the lessons and implement !! ⚡️