# Undo window

> Refunds, sends to your buyers and bulk deletes wait 10 seconds before they happen, with an Undo button, so a slip of the mouse never refunds the wrong order or emails everyone.

Source: https://shopfa.st/docs/store/undo

Some actions cannot be taken back once they run: money leaves, an email reaches thousands of inboxes, a hundred
products disappear. For those, the dashboard waits **10 seconds** first and shows a toast with a countdown and
**Undo**.

## What waits 10 seconds

| Action | Where |
| --- | --- |
| A refund, in full or in part, to the payment method or as store credit | Orders → an order → Refund |
| Sending a campaign now | Email marketing → a campaign (early access, with email marketing) |
| Posting a product update to its owners | Catalog → Updates, or Notify owners in the product editor |
| Deleting several products at once | Products → select → Delete |
| Deleting several discounts at once | Discounts → select → Delete |

Everything else that deletes asks first, in a dialog or inline ("Delete 100 unsold keys for good?"), and a few small
removals (search synonyms and rules, customer notes, fraud list entries) offer Undo in their toast.

## How it works

- The action is **queued on the server**, not in your browser. When the 10 seconds are up, ShopFast runs it with
  the same checks as if it had run at once, and records it in the audit log. Closing the tab does not cancel it.
- **Undo** cancels it while it is still waiting. Once it has run, Undo is gone and the toast says it went out.
- **Reload and the toast comes back.** The dashboard asks for your actions that are still waiting, so the Undo button
  survives a reload. Only the teammate who queued an action gets its toast back.
- **Permissions stay the same.** Undoing needs the same permission as the action itself, so someone who cannot
  refund cannot cancel your refund either.
- If the action fails when it runs (the order was refunded meanwhile, for example), the toast says why, in plain words.

## From the API

The API keeps its direct endpoints (`POST /v1/store/orders/{orderId}/refunds` refunds at once). The queued forms are
there for tools that want the same safety net:

| Queued endpoint | Runs like |
| --- | --- |
| `POST /v1/store/orders/{orderId}/refunds/queue` | A refund |
| `POST /v1/store/products/{productId}/broadcasts/queue` | Posting a product update |
| `POST /v1/store/products/bulk-delete-queue` | Deleting products (up to 500) |
| `POST /v1/store/discounts/bulk-delete-queue` | Deleting discounts (up to 200) |

Each answers with the pending action: its `id`, `kind`, `label`, `state` (`pending`, then `committed`, `cancelled`
or `failed`) and `commitAt`. Cancelling a queued action is done from the dashboard, where its toast shows.