Every team that integrates with a third-party API ends up needing a webhook inspector. The hosted tools — webhook.site, RequestBin (now Pipedream), Beeceptor, Hookdeck — work fine. They also send your payloads to someone else's server, which is a non-starter for the compliance-, privacy-, and "we'd rather not" set.
+ +We are building Hatch for the set.
+ +If you're looking for a requestbin alternative that keeps your data on your own network, Hatch is the answer.
+ +Hatch is a self-hostable HTTP request inspector and mocker. One Go binary. SQLite under the hood. docker compose up, and you have an inspection endpoint and a live feed in under 30 seconds. Your payloads never leave your box.
Who this is for
+ +You are a backend or platform engineer. You integrate with one or more third-party APIs that send you webhooks. You have tried webhook.site or RequestBin; they are fine for an afternoon. You want the same UX, but you want the data on your own infrastructure, on your own laptop, on a $5 VPS, or in your CI. You do not want a hosted dashboard logging every payload to someone else's database. Hatch is for that job.
+ +What it does
+ +Three things, and nothing else:
+ +-
+
- Capture. Method, path, headers, query, body. Persists across restarts because the storage is SQLite on disk, not a hosted queue. +
- Inspect. A live SSE feed of incoming requests. Click any captured request to see the headers, the body, the timing. +
- Mock. Return a 200, a 500, or a custom JSON payload. For testing your own retry, backoff, and error-handling logic without spinning up a separate mock server. +
That is the whole v0.1.
+ +What it does not do
+ +-
+
- No auth, no teams, no SSO. +
- No search-across-history. +
- No multi-tenant cloud, no billing, no per-request fee. +
- No production webhook reliability primitives (retries, ordering, dedup). That is Hookdeck's lane. +
- No TCP/UDP tunneling. That is ngrok's lane. +
Saying no is a feature. Every feature in v0.1 has to be something we can keep simple. A request inspector and a mocker are simple. Auth, teams, search, and cloud are not. So they are not in v0.1.
+ +Why a single binary, not a SaaS
+ +Three reasons, in order of importance:
+ +-
+
- Compliance and privacy. Some teams cannot legally send webhook payloads to a hosted SaaS. The current options for them are "build your own" (a week the first time, a day every time after) or "use a SaaS and accept the risk." Hatch is the third option — a self-hostable requestbin alternative that keeps the data on your own network. +
- Cost. A hosted inspector charges per request, per seat, or per retention day. Hatch is one Go binary on a $5 VPS. There is no per-request fee because there is no one to charge it. There is no free-tier cliff because there is no free tier. +
- Speed of setup.
docker compose upis faster than signing up for a SaaS, verifying your email, configuring your first bin, and pasting the URL into your webhook config. We have done the local-setup dance enough times to know.
+
What is open and what is not
+ +The code is open source. The license is MIT. The repo lives at github.com/elfoundation/hatch. The README is the spec; the quickstart is one command; the issues tab is the roadmap.
+ +We do not have a hosted cloud offering. We do not have a paid tier. We do not have a roadmap with a public date for either. When we do, the self-hosted build will keep working the same way it does today. We will not silently take a feature away from the OSS build to push it into a paid tier; that is a written promise, and the diff is the proof.
+ +How to try it
+ +git clone https://github.com/elfoundation/hatch
+cd hatch
+docker compose upThe README has the full quickstart, the API reference, and the limits of v0.1. If you find a bug, open an issue. If you want a feature that is not on the v0.1 list, open an issue anyway — we read every one, and "we do not do X yet" is a real answer.
+ +Star the repo: github.com/elfoundation/hatch.
+