Blog

API Idempotency: Preventing Duplicates in Automated Workflows (Includes n8n Template)

Par Rédaction Keerok ·09 Sep 2026 ·5 min
Sommaire
    API Idempotency: Preventing Duplicates in Automated Workflows (Includes n8n Template)

    A webhook triggers the same invoice twice, or a stock update is applied in duplicate after a network timeout. These errors are costly: duplicate payments, stock shortages, or corrupted data. Idempotency solves this problem by ensuring that an identical request executed multiple times produces the same result as the first execution.

    In this article, you’ll learn how to implement idempotency in your automated workflows, including a ready-to-use n8n template to block duplicate webhooks. We’ll cover the relevant HTTP methods, best practices for generating idempotency keys, and real-world examples with Shopify and Stripe to secure critical operations like billing and inventory management.

    What Is Idempotency and Why Is It Important?

    Idempotency is a property of operations that ensures an identical request executed multiple times produces the same result as the first execution, without additional side effects. For example:

    • GET /stock: Retrieving stock levels does not modify data, even after 10 calls.
    • PUT /stock/123: Updating a product’s stock with the same value changes nothing after the first execution.
    • DELETE /order/456: Deleting an already-deleted order does not generate an error.

    In contrast, POST and PATCH methods are not idempotent by default:

    • POST /invoice: Creating an invoice twice generates two identical invoices.
    • PATCH /stock: Applying the same stock update twice can corrupt data (e.g., decrementing stock twice instead of once).

    HTTP methods that are idempotent by design include GET, HEAD, PUT, DELETE, and OPTIONS . To make POST and PATCH idempotent, mechanisms like the Idempotency-Key header are used .

    Key Scenarios for Idempotency

    Idempotency is critical for:

    • Billing: Preventing duplicate invoices after a network timeout.
    • Inventory Management: Stopping stock updates from being applied twice (e.g., decrementing stock twice for the same order).
    • Payments: Blocking duplicate charges during request retries.
    • Resource Reservations: Ensuring a resource (e.g., delivery slot) is reserved only once.

    Idempotent vs Non-Idempotent HTTP Methods

    Method Idempotent? Example Use Case Risk Without Idempotency
    GET ✅ Yes Retrieving a list of products. None (read-only).
    HEAD ✅ Yes Checking resource existence without downloading it. None.
    PUT ✅ Yes Updating a product with complete data. None (fully replaces the resource).
    DELETE ✅ Yes Deleting an order. None (idempotent deletion).
    POST ❌ No Creating an invoice. Duplicate creation (e.g., two identical invoices).
    PATCH ❌ No (unless mechanisms added) Partially updating stock. Update applied multiple times (e.g., decrementing stock twice).

    For POST and PATCH, idempotency requires an external mechanism like the Idempotency-Key header. For example, a repeated PATCH /stock may apply the same update multiple times unless an Idempotency-Key header is used to block duplicates .

    Comparison table of idempotent and non-idempotent HTTP methods with examples.
    Comparison of idempotent and non-idempotent HTTP methods, with use cases and associated risks.

    Example with n8n: Workflow to Block Duplicate Webhooks

    Webhook providers (e.g., Stripe, Shopify) use at-least-once delivery: if a request fails or times out, they retry it. This can trigger the same n8n workflow twice, leading to unwanted side effects (e.g., duplicate invoices).

    Diagram of the n8n workflow to check webhook idempotency and prevent duplicates.
    Idempotency verification flow in an n8n workflow to block duplicate webhooks.

    Solution: An n8n Workflow with Idempotency Check

    The following n8n template, “Prevent Duplicate Webhook Executions”, adds an idempotency check before executing side effects:

    1. Webhook Reception: The workflow extracts an idempotency key from the payload (e.g., event.id).
    2. Database Check: The workflow queries an SQLite database to verify if the key already exists.
      • If the key does not exist: The workflow records the key and executes side effects (e.g., invoice creation).
      • If the key exists: The workflow stops to prevent duplicates and responds with 200 OK to avoid retries from the provider .

    Note: This code assumes an SQLite database to store idempotency keys .

    Key Code Snippet

    // Check for idempotency key existence
    await db.run(
      "INSERT INTO idempotency_keys (key, created_at) VALUES (?, ?)",
      [idempotencyKey, new Date().toISOString()]
    );
    
    // If the key already exists, SQLite throws a UNIQUE constraint error
    // The workflow stops here to prevent duplicates

    The workflow responds immediately with 200 OK to prevent the webhook provider from retrying the request, even if the key already exists and the workflow is blocked .

    Use Cases with the Template

    • Billing: Block duplicate invoice creation after a network timeout.
    • Inventory Management: Prevent stock updates from being applied twice (e.g., decrementing stock twice for the same order).
    • Payments: Avoid duplicate charges during request retries.

    Use Cases: Shopify and Stripe

    Shopify: Securing Payments and Billing

    Shopify uses idempotency keys for requests involving payments, billing attempts, or revenue capture. For example:

    • The subscriptionBillingAttemptCreate mutation accepts an idempotency key to avoid creating duplicate billing attempts .
    • Shopify recommends using unique identifiers like random UUIDs to avoid collisions .

    Stripe: Preventing Duplicate Payments

    Stripe supports idempotency for POST requests via the Idempotency-Key header. Here’s how it works:

    • Stripe stores the status and body of the first request’s response for a given key .
    • If the same key is reused within 24 hours, Stripe returns the same response without re-executing the request .
    • After 24 hours, a new request is generated if the key is reused .

    Best Practices for Generating and Managing Idempotency Keys

    1. Key Generation

    • Format: Use random UUID v4 (e.g., 550e8400-e29b-41d4-a716-446655440000) to avoid collisions .
    • Validity Period: Limit key validity (e.g., 24 hours, as in Stripe) to avoid conflicts after expiration .
    • Storage: Store keys in a database with a UNIQUE index to ensure uniqueness.

    2. Error Handling

    The server may return the following errors in case of issues :

    • 400 Bad Request: The Idempotency-Key header is missing for a required operation.
    • 409 Conflict: A request with the same key is already being processed.
    • 422 Unprocessable Content: The key is reused with a different payload.

    3. Alternatives to Idempotency-Key (Editorial Recommendation)

    If the Idempotency-Key header isn’t supported, you can use:

    • Natural Keys: Use a unique identifier already present in the payload (e.g., order_id).
    • Optimistic Locking: Add a version field to your resources and reject updates if the version doesn’t match.

    When Idempotency Isn’t Enough

    Idempotency is effective for simple operations but has limitations:

    • Complex Workflows: For processes involving multiple services (e.g., reservation + payment + notification), a pattern like SAGA (distributed transactions) may be necessary.
    • Non-Technical Side Effects: Idempotency doesn’t solve business problems (e.g., an email sent twice despite an idempotency key).

    Conclusion

    Idempotency is a simple yet powerful mechanism to prevent duplicates in automated workflows. By following the best practices outlined here—using random UUIDs, handling errors, and limiting key validity—you can secure critical operations like billing and inventory management.

    Next steps:

    Article préparé avec assistance IA et contrôlé à partir des sources consultées.

    idempotence API workflows automatisés n8n Shopify Stripe bonnes pratiques développement
    À lire ensuite
    Un sujet proche à cadrer ? Parlons-en. Prendre contact avec Keerok →
    © 2026 Keerok · Tous droits réservés Cran · le média de Keerok