What are event destinations?

An event destination is the target end of an outbound event delivery: the place a product event lands after it leaves your platform. When your app emits an event and the delivery layer routes it, the destination is what actually receives the payload, an HTTP endpoint, a file in a bucket, a row in a warehouse, a message on a queue, and so on.

Every destination type has its own rules. Some accept one event per request; others expect events batched into files or inserts. Some authenticate with a signing secret, others with cloud credentials or a connection string. Some want the raw event JSON; others want it wrapped in a destination-specific envelope. Treating each type as a distinct integration, with its own auth, batching, schema, and error handling, is what makes reliable delivery possible.

Destinations group into a handful of categories. Webhooks are HTTP endpoints owned by the customer, the most universal and realtime option. Object storage, buckets in the major clouds, receives events as files, which suits archival and batch loading. Data warehouses receive events as rows for analytics and reporting.

Message queues and streams carry events to the customer's own processing systems for fan-out and decoupling. Databases receive events as inserts into tables the customer controls. Analytics tools receive events shaped for product and behavioral analysis. Each category trades off latency, batching, and downstream use, which is why customers often configure several at once for different purposes.

Different customers want their events in different places, and increasingly on infrastructure they own. A vendor that hardcodes a fixed set of integrations ends up writing bespoke code for every variation. Making destinations configurable, letting each customer pick a type, supply credentials, and define routing, turns that into self-serve configuration on a shared delivery path.

Per-customer configuration also keeps credentials and data ownership where they belong. Each customer's credentials are scoped to their own destinations, and tenant isolation keeps one customer's configuration and deliveries separate from another's. That is what lets the same platform serve many customers' destinations without leaking access across them.

Pushrail ships a catalog of event destinations across all of these categories, webhooks, object storage, data warehouses, message queues, streams, databases, and analytics tools. Customers browse the catalog, configure the destinations they need with their own credentials, and route event types to them from a dashboard or embedded portal.

Whatever the destination type, the same delivery guarantees apply: events are routed, optionally filtered and transformed, delivered, retried on transient failure, dead-letter-queued when exhausted, logged per attempt, and replayable. See the full catalog on the destinations page.