Skip to Content

RabbitMQ

Publish messages to RabbitMQ exchanges for event-driven architectures and asynchronous processing pipelines. Use Zeotap to stream audience membership changes, enriched profiles, or model outputs to RabbitMQ for real-time downstream consumption.

Prerequisites

  • A RabbitMQ server (self-managed or a hosted service like CloudAMQP, Amazon MQ, or Azure Service Bus)
  • The RabbitMQ Management Plugin enabled (provides the HTTP API on port 15672)
  • An exchange configured to receive messages
  • RabbitMQ user credentials with permission to publish to the target exchange and virtual host
  • Network connectivity between Zeotap and the RabbitMQ Management API endpoint

Authentication

RabbitMQ uses username and password authentication (the same credentials used to log in to the Management UI).

  1. Enter the Username for your RabbitMQ user
  2. Enter the Password for your RabbitMQ user

The credentials must have write permissions on the target virtual host and exchange. The default guest user is typically restricted to localhost connections only — create a dedicated user for remote access.

Configuration

FieldTypeRequiredDescription
Management API URLTextYesBase URL of the RabbitMQ Management HTTP API, including the port (e.g., https://rabbitmq.example.com:15672). Use https:// to enable TLS
Virtual HostTextNoThe RabbitMQ virtual host. Defaults to / if not specified

Target Settings

FieldTypeRequiredDescription
ExchangeTextYesThe RabbitMQ exchange to publish messages to (e.g., my-exchange). The exchange must already exist
Routing KeyTextNoStatic routing key applied to all messages. If Routing Key Field is also set, this value is used as a fallback when the field is empty
Routing Key FieldTextNoRow field to use as a dynamic routing key per message. When a row contains this field, its value overrides the static routing key

Supported Operations

Sync Modes

ModeSupported
InsertYes
Upsert
Update
Mirror

Audience Sync Modes

ModeSupported
AddYes
Remove
Mirror
Upsert

Features

  • Field Mapping: No — RabbitMQ publishes the full record as a JSON message
  • Schema Introspection: No — RabbitMQ exchanges are schemaless from the producer perspective

How It Works

Zeotap publishes each row as a JSON message to the configured RabbitMQ exchange via the Management HTTP API:

  1. Each row is serialized as a JSON object and base64-encoded
  2. The routing key is determined per message: if a Routing Key Field is configured and the row contains that field, its value is used; otherwise the static Routing Key is used
  3. Messages are published to the exchange with delivery_mode: 2 (persistent) and content_type: application/json
  4. RabbitMQ routes each message to bound queues based on the exchange type and routing key
  5. The API confirms whether each message was routed to at least one queue

Messages are published individually via the Management HTTP API. For very high-throughput use cases, consider using the Apache Kafka or Amazon Kinesis destinations which support native batch publishing.

Rate Limits

The RabbitMQ Management HTTP API does not impose explicit rate limits, but it is designed for management operations rather than high-throughput message publishing. Performance depends on:

  • Server resources: CPU, memory, and disk I/O on the RabbitMQ node
  • Network latency: Each message requires a separate HTTP round-trip
  • Queue depth: Deeply backed-up queues can create backpressure

Zeotap automatically retries on transient errors (HTTP 429 and 5xx) with exponential backoff.

Best Practices

  • Use dedicated exchanges for Zeotap syncs rather than publishing to shared application exchanges
  • Set up dead-letter exchanges to capture unroutable messages rather than silently dropping them
  • Monitor queue depths to detect downstream consumer bottlenecks
  • Use topic exchanges with the Routing Key Field to fan out messages to multiple queues based on row attributes (e.g., event type, region)
  • Create a dedicated RabbitMQ user with minimal permissions (write access to the target vhost and exchange only)
  • Enable TLS for all production connections to encrypt credentials and message payloads in transit

Troubleshooting

Connection failed

Verify the Management API URL is correct and includes the port (default 15672). Ensure the RabbitMQ Management Plugin is enabled (rabbitmq-plugins enable rabbitmq_management). Check that firewalls and security groups allow inbound connections to the Management API port.

Authentication failed

Verify the username and password. The default guest user can only connect from localhost — create a new user with rabbitmqctl add_user and set appropriate permissions with rabbitmqctl set_permissions. Ensure the user has access to the target virtual host.

Message was not routed to any queue

This means the message reached the exchange but no queue bindings matched the routing key. Verify that queues are bound to the exchange with matching routing keys or binding patterns. For topic exchanges, check that the routing key pattern matches the bindings (e.g., events.user.*).

Exchange not found (HTTP 404)

The specified exchange does not exist on the target virtual host. Create the exchange before configuring the sync, or verify the exchange name and virtual host are correct. Exchange names are case-sensitive.

Virtual host not found

The specified virtual host does not exist. List available virtual hosts in the Management UI under Admin > Virtual Hosts, or create one with rabbitmqctl add_vhost.

Slow publishing throughput

The Management HTTP API publishes messages individually — each message requires a round-trip HTTP request. For high-throughput scenarios (thousands of messages per second), consider using the Apache Kafka or Amazon Kinesis destinations instead, which support native batch operations.

TLS handshake failed

Ensure the Management API URL uses https:// when TLS is enabled on the RabbitMQ server. For self-signed certificates, contact support for custom CA configuration.

Last updated on