Introduction

Catchook sits in front of the webhooks you receive. A provider — Stripe, GitHub, Shopify, Linear — posts to a Catchook URL instead of yours. Catchook verifies the signature, records the event, and fans it out to every destination you have configured, with retries and rate limiting on each one.

Because every event passes through, Catchook can also tell you how each integration is behaving over time: what share of deliveries succeed, how long they take, and when one goes quiet.

Why not point the provider straight at your service#

You can, and plenty of teams do. What you give up is everything that happens around the request:

• A failed delivery is gone. Most providers retry on their own schedule, some barely at all, and none of them let you re-send on demand once they have given up.
• One URL, one consumer. Sending the same Stripe event to your API and a staging environment and an internal audit service means writing that fan-out yourself.
• You find out late. An integration that silently stops sending looks exactly like an integration with nothing to report.

The shape of it#

Provider ──▶ https://events.catchook.com/e/<endpoint_id>
                  │
                  ├── verify signature        (401 if it fails)
                  ├── record the event        (queryable for 14 days)
                  └── fan out ──▶ Destination A   retry + rate limit
                                ├▶ Destination B
                                └▶ Destination C

An Endpoint is one inbound URL, belonging to one provider, with one verification method. A Destination is one place an endpoint’s events get delivered to. One endpoint can have many destinations, and each one carries its own retry policy, rate limit and signing secret.

Where to go next#

• Quickstart — an endpoint receiving a real webhook, in about five minutes.
• How it works — the receive and delivery paths in detail, including what is guaranteed and what is not.
• CLI — put live webhooks on your laptop without a public URL.