Customer-configurable event destinations.
Webhooks, object storage, data warehouses, message queues, databases, and analytics. Send an event once, your customers configure where it goes.
Destination catalog
Grouped by category. Every destination supports routing, transforms, retries, and replay.
Object storage
Deliver events as NDJSON files into a customer-owned S3 bucket, batched, partitioned, and idempotent.
Stream batched NDJSON events into a customer-owned GCS bucket, same delivery model as S3, on GCP.
Batched NDJSON event delivery into a customer-owned Azure Storage container, parity with S3 and GCS.
Data warehouses
Stream events directly into a customer's BigQuery dataset, table per event type or single wide table.
Continuous ingest into a customer-owned Snowflake table via Snowpipe-style staging.
High-throughput row-shaped event delivery into a customer's ClickHouse cluster, one row per event.
Message queues
At-least-once delivery into a customer-owned SQS queue, standard or FIFO, native AWS SDK.
AMQP exchange-and-routing-key delivery into a customer-owned RabbitMQ cluster.
AMQP delivery into a customer-owned Azure Service Bus queue or topic, sessions, dead-letter, scheduled enqueue.
Streams
Native Kafka producer with SASL/TLS, deliver events into a customer's topic with configurable partitioning.
Ordered shard delivery into a customer-owned Kinesis Data Stream, configurable partition keys, native AWS SDK.
Topic delivery with ordering keys and dead-letter topics, native to GCP.
Fan-out to customer-owned SNS topics, one event to many subscribers.
Deliver events into a customer's EventBridge bus, rule-driven routing inside AWS.
Databases
How destinations work
Three primitives compose into every delivery.
Routing rules
Pick which events go to which destinations. Filter by event type, customer, environment, or any field in the payload.
Declarative transforms
Rename, drop, or wrap fields per destination. No code. Scripted transforms unlock for Growth and above when you need them.
Reliability primitives
At-least-once delivery, retries with backoff, DLQ, and replay, applied uniformly across every adapter.
Your customers configure their own destinations
Drop the embedded portal into your app. They wire up a destination to their own infrastructure. You stop building one-off integrations.
The embedded portal exposes destinations, routing, transforms, and the delivery log, scoped to the customer that's signed in. White-labelled, theme-aware, and isolated by sub-tenant.
See the embedded demo →Frequently asked questions
What kinds of destinations can I deliver to?
Webhooks, object storage, data warehouses, message queues, streams, databases, and analytics tools. You send an event once and your customers configure where it goes.
Do I send a different payload for each destination?
No. You send one canonical event to Pushrail's ingest API. Each destination's adapter shapes that event into the right format: NDJSON files for storage, streamed rows for warehouses, native messages for queues and streams, and so on.
Whose credentials are used to deliver to a destination?
The customer's. Destinations are configured with the customer's own credentials, stored encrypted at rest and scoped to that destination, so events are written under the customer's identity.
Are routing, retries, and replay the same across destinations?
Yes. Every destination supports routing rules, declarative transforms, at-least-once delivery with retries and backoff, a dead-letter queue, and replay, applied uniformly across every adapter.
Push events to anywhere your customers run
Sandbox is open. No credit card.