Send events to RabbitMQ
AMQP exchange-and-routing-key delivery into a customer-owned RabbitMQ cluster.
What is RabbitMQ?
RabbitMQ is one of the most widely deployed open-source message brokers, used in finance, telecom, and any team that built on AMQP a decade ago. As a destination, it slots into a customer's existing event infrastructure when they already operate a cluster. Pushrail's RabbitMQ adapter publishes to a configured exchange with a configurable routing key so the customer's existing topology routes events to whichever queues they want.
Why deliver events to RabbitMQ
- Plugs into the customer's existing RabbitMQ topology, no new infrastructure to add.
- Routing keys give the customer fine-grained control over which queues receive which events.
- AMQP is decades-stable, most language ecosystems have mature clients.
- Works on self-hosted, CloudAMQP, or RabbitMQ Cloud.
How Pushrail delivers events to RabbitMQ
The adapter opens a long-lived AMQP 0-9-1 connection and publishes one message per event to the configured exchange with a configurable routing key (default `pushrail.<event_type>`). Headers include the envelope fields. Publisher confirms are enabled, so a message is only acknowledged after the broker confirms it accepted the message into the exchange.
Auth and credentials
Username/password over TLS (default) or SASL EXTERNAL with a client certificate. Credentials encrypted at rest. The customer creates a dedicated `pushrail` user with `write` permission on the destination exchange and no other ACLs.
Batching, retries, and replay
RabbitMQ publishes are one-at-a-time (no native batch API) but the adapter pipelines and uses publisher confirms to keep throughput high. Transient errors (connection reset, channel close) retry with exponential backoff. Permanent errors (auth failure, exchange not found) land in the DLQ. Replay re-publishes with the same headers; consumers using the `idempotency_key` header dedup at consumer-time.
Example payload
Pushrail accepts the canonical event shape on POST /v1/events. Below is the ingestion request your service makes.
{
"eventType": "order.completed",
"occurredAt": "2026-05-26T14:21:08.493Z",
"source": "billing-service",
"customerExternalId": "acct_8K2zRq",
"idempotencyKey": "order_38a91f-completed",
"correlationId": "req_4f30b2",
"payload": {
"orderId": "ord_38a91f",
"amount": 12900,
"currency": "USD",
"items": [
{ "sku": "PR-PRO-MONTHLY", "qty": 1, "price": 12900 }
]
},
"metadata": {
"tier": "pro",
"region": "us-east-1"
}
}Example configuration
The fields your customer fills in to point Pushrail at their RabbitMQ setup.
{
"type": "RABBITMQ",
"name": "Customer RabbitMQ cluster",
"url": "amqps://customer-cluster.acme.example:5671",
"vhost": "/pushrail",
"exchange": "pushrail.events",
"exchangeType": "topic",
"routingKeyTemplate": "pushrail.{eventType}",
"auth": {
"mode": "PASSWORD",
"username": "pushrail",
"password": "••••••••",
"tls": true
}
}Common use cases
- Slot into a customer's existing AMQP-based event topology.
- Route different event types to different queues via routing keys.
- Feed legacy systems that already speak AMQP without standing up Kafka.
- Bridge between your product and a customer's CloudAMQP-backed processing.
Related destinations
At-least-once delivery into a customer-owned SQS queue, standard or FIFO, native AWS SDK.
AMQP delivery into a customer-owned Azure Service Bus queue or topic, sessions, dead-letter, scheduled enqueue.
Native Kafka producer with SASL/TLS, deliver events into a customer's topic with configurable partitioning.
Frequently asked questions
How does Pushrail publish to RabbitMQ?
The adapter opens a long-lived AMQP 0-9-1 connection and publishes one message per event to the configured exchange with a configurable routing key (default pushrail.<event_type>). Publisher confirms are enabled, so a message is acknowledged only after the broker confirms it accepted the message into the exchange.
Can I control which queues receive which events?
Yes. Routing keys give fine-grained control, so your existing exchange-and-binding topology routes events to whichever queues you want. The default routing key is pushrail.<event_type>, and you can template it.
What authentication and deployments are supported?
Username/password over TLS (default) or SASL EXTERNAL with a client certificate. Credentials are stored encrypted at rest. It works on self-hosted RabbitMQ, CloudAMQP, or RabbitMQ Cloud. The customer creates a dedicated pushrail user with write permission on the destination exchange and no other ACLs.
What happens if a publish fails?
Transient errors like a connection reset or channel close retry with exponential backoff; permanent errors like an auth failure or missing exchange land in the dead-letter queue. Replay re-publishes with the same headers, so consumers using the idempotency_key header can dedup at consume time.