Practical guide

Prevent a double click from becoming duplicate work

Design submission feedback around one identifiable request.

Last materially reviewed 2026-09-18

Quick answerDisable conflicting actions while a request is pending and reconcile the original result before offering another submission.
What to know

Diagnose which duplicate would matter

A duplicate search is usually less consequential than two notifications, purchases or paid generations. List the actions in your app and identify which create records or external side effects. Give those actions an explicit pending state. A spinner is useful only if it reflects the state of the operation; it should not simply disappear after an arbitrary timer and invite another click while work may still be running.

What to know

Preserve the original request identity

Keep a supported request or record reference so the interface can check what happened after a slow response. A new browser request does not necessarily mean a new user intention. When the server supports a deduplication mechanism, use it according to its contract. Do not invent an exactly-once guarantee merely because a button is disabled. Reloads, multiple tabs and network retries can bypass a purely visual guard.

What to know

Test failure and uncertain outcomes locally

Use a harmless controlled responder to simulate delayed acknowledgement, clear rejection and connection loss after possible acceptance. Verify that the page explains each outcome differently and does not silently create a replacement operation. Do not test duplicate handling by repeatedly clicking a real paid action. Overskill’s API guidance distinguishes operation states, but the behavior of your generated app still needs its own scoped verification.

What to know

Make recovery understandable

If the original result can be retrieved, show it and continue from that identity. If it cannot be established, say that the outcome is unknown and identify a safe resolution path. Preserve the user’s brief or entered data where appropriate. A careful recovery message should reduce confusion without concealing uncertainty. The goal is not to prohibit all retries, but to make a retry depend on evidence that it is safe.

Continue when useful

Next: Plan a webhook without creating duplicate work

Design event identity, duplicate handling and bounded recovery before connecting real notifications.

Open Plan a webhook without creating duplicate work →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Overskill API error guidance — Merchant documentation · overskill.com · Merchant-controlled · checked 2026-09-18
  2. NIST Secure Software Development Framework — guidance, not product certification — Standards and certification reference · csrc.nist.gov · Publisher independence not verified · checked 2026-09-18