When to Use an Inspector with Local History
Use IndexedDB history and a 24-hour encrypted share when you need the last events on your machine. Not a public bin, not a compliance log.
Some inspectors store every request on their servers so you can leave and come back. OpenWebhook does not, unless you opt in to a share. History is local. That is a decision, not a missing feature. Use it when it fits. Skip it when it does not.
A competitor table lives on webhook.site alternative. This page is only “does local history solve my job?”
What you get
Open openwebhook.co and send a request:
curl -X POST \
'https://hooks.openwebhook.co/YOUR_UUID/local' \
-H 'content-type: application/json' \
--data '{"id":"evt_1"}'
The live stream needs the tab. After the event arrives, the browser keeps the latest 200 requests in IndexedDB on this origin. Refresh keeps them. Another laptop does not see them.
Share (optional) uploads an encrypted copy to Redis for 24 hours. The decryption key stays in the URL fragment (/s/{id}#key). The server never receives that key. The share link is a snapshot of one request, not a public bin.
Use local history if…
You are iterating on one provider in one browser. You need the last few deliveries after a refresh. You might send a teammate a single encrypted link and then let it expire. You do not want another durable copy of card numbers or OAuth codes on a third-party disk.
Do not use it if…
You will close the tab and come back tomorrow without sharing. Clearing site data wipes IndexedDB. You need a URL that accumulates retries while your laptop is shut. You need an audit log for compliance. You need two people to watch the same live list without passing a share link.
Those jobs want a hosted bin. Use one. The one-minute inspect loop is still the right first step; store the request elsewhere afterward.
For a handler on 127.0.0.1, local history in the browser is optional. The CLI without an account never writes payloads to disk.
