Recycle bin

Deleting a captured request moves it to the workspace recycle bin, restorable for up to 7 days or until the plan's retention window ends. Only the retention sweep or a purge applied by WebhookVault support removes it for good.

WebhookVault does not lose what it captured because someone clicked the wrong row. Every delete, whether one request, a selection, or the endpoint's whole history, moves the request to the workspace's recycle bin. It leaves the endpoint immediately and can be put back for up to 7 days: or until your plan's retention window ends, whichever comes first, because a deleted request is still stored and retention still governs it. After that the sweep removes it.

There is no "empty the bin" button, in the app or in the API. Nothing a customer does removes a captured request before the window closes.

What a delete does

ActionEffect
Delete one requestmoves it to the bin, audited
Delete selectedmoves each to the bin, audited as one event
Clear all requestsmoves every stored request on the endpoint to the bin, and asks you to type the phrase first
Delete the endpointpermanent, including anything of its in the bin, and asks you to type the endpoint name

Deleted requests still count toward your stored bytes until they leave the bin, because they are still stored. They do not count toward the endpoint's stored-request number, and they never come back in a list, a search, a replay or the API.

Two things are not recycle-bin deletes, because neither is a customer deleting anything:

  • Retention. A request older than your plan's retention window is removed by the sweep.
  • The stored-request cap. When an endpoint is at its plan cap, the oldest stored request is removed as the newest arrives. The vault never refuses a capture to stay under a cap.

Restoring

The Recycle bin page lists everything deleted in the workspace, newest deletion first, filterable by endpoint, method, path, size, when it was deleted, who deleted it and how. Select rows and restore them, or restore everything at once. A restored request goes back to the endpoint it came from, with its delivery history intact.

A request stays in the bin if its endpoint is already holding as many requests as your plan allows. Restoring past that limit would only hand it to the next capture's eviction, which is permanent, so the bin keeps it and tells you how many stayed behind. Clear some live requests on that endpoint, or move to a plan that stores more, and restore again.

Asking for a permanent deletion

Sometimes a week is too long: a payload arrived with a card number in it. Use Request permanent deletion on the recycle bin page. It covers the bin items you selected, or everything in the bin if you selected nothing, and nothing else. Nothing is removed when you send it: you confirm by typing the phrase, the request goes to WebhookVault support, and they apply or decline it. The outcome appears in your activity log with their note.

Deleting data that is not in the bin, or closing the account, is a different decision and lives somewhere else on purpose. Both are on the Security page under Danger zone:

  • Delete every captured request removes everything the workspace has captured, on every endpoint, bin included. Your endpoints, keys and settings stay and keep capturing.
  • Close this account removes the captured data and then the account itself.

Each has its own confirmation and its own phrase to type, and WebhookVault support confirms either with you by email before acting.

API

CallPurpose
DELETE /api/v1/endpoints/{id}/requests/{requestId}move one request to the bin
POST /api/v1/endpoints/{id}/requests/bulk-deletemove up to 500 to the bin
DELETE /api/v1/endpoints/{id}/requestsmove all of the endpoint's requests to the bin
GET /api/v1/recycle-binwhat is in the bin, with purgesAt per row
POST /api/v1/recycle-bin/restoreput requests back by id

An integration that deletes by mistake has the same way back as the app does. Purge requests are raised from the app, not the API, because a person has to give a reason.

On this page