How capture works

catchbin’s cloud receiver is always on. It accepts a webhook, stores it, and answers the provider immediately — separately from anything happening on your machine.

Two independent transactions

The provider’s request and the delivery to your local server are two separate HTTP transactions. catchbin answers the provider first and worries about your server second:

t≈0ms   Provider opens a connection and POSTs the webhook
t≈2ms   catchbin writes the request to storage
t≈3ms   catchbin responds 200 OK → the provider is satisfied, connection closes
t≈5ms   catchbin pushes the event to any connected CLI session
t≈6ms   CLI POSTs the same bytes to localhost:3000
t≈8ms   Your server responds; the CLI logs the code + latency and reports it back

The provider gets its 200 OK in a few milliseconds whether or not your local server — or your laptop — is running. Your server being slow or down never causes the provider to see a failure or a retry storm.

Capture when you’re offline

If no CLI is connected when an event arrives, catchbin still accepts and stores it. The event waits in your endpoint’s history. When you next run catchbin forward, the queued events are delivered to your target in the order they were received, then live events continue to stream.

What “permanent” means here

Two things about catchbin are permanent: the endpoint URL and (on the free plan) the price. Captured event history is not permanent — it is retained for the length of your plan’s retention window and then removed. Retention windows and storage limits are on the Security & privacy page and the pricing page.