# Why we are building Hatch

June 23, 2026

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:

1. 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.
2. 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.
3. Speed of setup. `docker compose up` is 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 up

The 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.