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
| Action | Effect |
|---|---|
| Delete one request | moves it to the bin, audited |
| Delete selected | moves each to the bin, audited as one event |
| Clear all requests | moves every stored request on the endpoint to the bin, and asks you to type the phrase first |
| Delete the endpoint | permanent, 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
| Call | Purpose |
|---|---|
DELETE /api/v1/endpoints/{id}/requests/{requestId} | move one request to the bin |
POST /api/v1/endpoints/{id}/requests/bulk-delete | move up to 500 to the bin |
DELETE /api/v1/endpoints/{id}/requests | move all of the endpoint's requests to the bin |
GET /api/v1/recycle-bin | what is in the bin, with purgesAt per row |
POST /api/v1/recycle-bin/restore | put 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.