Repost sits between webhook senders and your application. Providers send events to a bucket, Repost records the request, and forwarders deliver it to the services that should act on it.

Explore concepts Compare modes

Repost is built around a few ideas: where events enter, where they go, and how the bucket responds, then how you inspect, search, replay, and recover the traffic that flows through.

} > The public ingress point for webhook traffic. } > A destination attached to a bucket. } > Queue or proxy the request response path. } > A record of requests and delivery outcomes.

} > Filter history with a powerful field, range, and JSON-path query language. } > Redeliver selected, filtered, or failed events through a forwarder. } > Exhausted deliveries park here to replay or archive.

A bucket is the address you give to a webhook provider. It owns the event history, forwarding rules, and response behavior for that stream of traffic. Use one Repost endpoint instead of wiring every provider directly to your application. Split buckets by provider, environment, product area, or any other operational boundary. Choose a bucket mode before sending traffic so the provider gets the right response.

A forwarder connects a bucket to a destination. A destination can be your production API, a worker, an internal service, or a local development session. A provider sends the webhook to the bucket URL. Repost stores the inbound request with the bucket event history. Each active forwarder sends the event to its destination. The event page shows the request, forwarders, and responses in one place.

Bucket mode decides what the webhook sender receives after it calls Repost. } > Repost answers the provider right away, then delivers in the background. Send the same event to your API, a worker, analytics, or local development. Retries with backoff, a dead-letter queue and replay, functions, secrets, and rate limiting. } > The sender receives your application's actual status code and body. No asynchronous retries or dead-letter recovery; the bucket has a single destination. The original request and downstream response are saved in event history.

Feature comparison

Capability	Queued	Proxy

Every event a bucket receives is recorded with its delivery outcomes, so you can confirm what the provider sent, where it went, and what each destination returned. Method, headers, body, source, timestamp, and the bucket that received the event. Forwarders, destination responses, and whether an event should be sent again.

Set up your first end-to-end flow, from a bucket to your destination. Define where webhook traffic enters Repost. Queue an acknowledgement, or proxy the destination's response. Route events to your production API, a worker, or an internal service. Receive live webhook traffic on your machine with the Repost CLI. Follow a request from sender to destination in event history. Redeliver failed or filtered events through a forwarder.