Make.com Scenario Retries (Running Twice)?
Fix Duplicate Execution with Idempotency

You searched for “Make.com scenario retries” or “Make.com scenarios running twice” because it happened: same data, same step, duplicated side effects — and nothing “looks broken.”

This usually isn’t a Make.com bug. It’s a reliability feature: at-least-once delivery. Make retries steps when it’s not sure the first attempt completed — and if your endpoint isn’t idempotent, retries become duplicate execution.

🚨 Make.com Scenario Retries: the behavior you’re seeing

Make.com is designed to complete work reliably across networks and third-party APIs. Networks fail. APIs time out. Providers rate limit. Webhook deliveries get repeated. The platform responds with retries.

• From Make’s perspective: “We didn’t get confirmation. Retry to avoid data loss.”
• From your API’s perspective: “Another request. Execute again.”

If the call creates side effects (create order, charge, send email, write row), a retry can produce duplicates unless the action is idempotent.

🤯 Why scenarios run twice (even when filters are correct)

Filters control logic flow. They don’t change delivery semantics. Duplicates happen when Make repeats the same step after:

• HTTP timeout / slow response (Make doesn’t know if your server applied the side effect)
• temporary 5xx / 429 rate limit
• connector/module retry rules
• webhook sender retries (Stripe, Shopify, etc.) plus Make retries

⚖️ Zapier vs Make.com: Duplicates Comparison

Developers often ask “Is Make worse than Zapier?” The reality: both are at-least-once systems. The difference is the UI model (steps vs modules), not the fundamental behavior.

💥 What duplicates look like in production

❌ Fixes that don’t work (and why)

✅ The architecture that actually stops duplicates

You need an idempotency layer between Make.com and your side-effect API: a boundary that converts retries into “same request → same result.”

Instead of Make.com → Your API, you do:

🔑 Idempotency key: the one thing that matters

The key must be stable for the same logical action. If the retry is the “same action,” the key must be the same. If it’s a new action, the key should change.

🔧 Make.com HTTP Module Example (copy/paste)

In Make, add a first HTTP module that calls OnceOnly /v1/check-lock with a stable key (like {{executionId}} + an order/webhook id). Then add a filter: only call your side-effect endpoint when OnceOnly returns status=locked.

POST https://api.onceonly.tech/v1/check-lock
Authorization: Bearer once_live_***
Content-Type: application/json

{
  "key": "make:{{executionId}}:order:{{order_id}}",
  "ttl": 86400,
  "metadata": {
    "source": "make",
    "execution_id": "{{executionId}}",
    "order_id": "{{order_id}}"
  }
}

{
  "success": true,
  "status": "locked",
  "key": "make:ex_123:order:ord_456",
  "ttl": 86400,
  "first_seen_at": null
}

🧩 If you prefer server-side idempotency (DIY)

If you don’t want a dedicated layer, you can implement idempotency directly: store the key, lock in-flight executions, and cache the result.

# Pseudocode: minimal server-side idempotency for a POST /create_order
# Store: key -> result; plus a short lease lock to avoid parallel executes.

def create_order_idempotent(idem_key: str, payload: dict):
    cached = db.get_result(idem_key)
    if cached:
        return {**cached, "duplicate": True}

    if not db.try_acquire_lease(idem_key, ttl_seconds=30):
        # Another worker is executing; either wait briefly or return a "processing" response.
        cached2 = db.wait_for_result(idem_key, timeout_seconds=5)
        if cached2:
            return {**cached2, "duplicate": True}
        raise RuntimeError("Still processing")

    # Execute side-effect once
    result = real_create_order(payload)

    db.store_result(idem_key, result, ttl_seconds=86400)  # cache for 24h
    return {**result, "duplicate": False}

🚀 The 5-Minute Fix

Make.com will retry. Zapier will retry. Webhooks will retry. Networks will fail. The only reliable solution is to make retries safe with idempotency keys and deduplication.

❓ Frequently Asked Questions