Why I built Pushrail

At every B2B company I worked at, the request was the same. A customer wanted the events our product already produced delivered somewhere they owned. A webhook. An S3 bucket. A warehouse table. A queue their team was watching.

Each ask was reasonable on its own. The trouble was that the destination they wanted was almost always one we had never built before.

So we would build it. A new integration, scoped to a single customer, wired up by hand: their endpoint, their credentials, their auth quirks. Then we owned it forever. The retries when their endpoint went down, the alert when deliveries stalled, the backfill when something slipped through, the 2am page for a customer's misconfigured bucket.

Multiply that by every customer and every destination they could think of, and forwarding customer data quietly became a permanent tax on the roadmap. Sales kept promising it. Engineering kept paying for it.

Pushrail is the thing I wanted instead. Your product sends its events to Pushrail once. From there your customers configure their own destinations through a portal you can embed directly in your app, and Pushrail handles delivery: routing, filtering, retries with backoff, replay, dead-letter handling, and delivery logs, with each customer's credentials stored and isolated.

Now a new destination is something your customer sets up on their own. It never has to reach your backlog.