Send events to Azure Service Bus
AMQP delivery into a customer-owned Azure Service Bus queue or topic, sessions, dead-letter, scheduled enqueue.
What is Azure Service Bus?
Azure Service Bus is Microsoft's enterprise message broker, first-class on Azure, with sessions for ordering, scheduled enqueue, and built-in dead-letter queues. For Azure-native customers it is the canonical queue destination and pairs naturally with Azure Functions, Logic Apps, and Service Fabric. Pushrail's adapter speaks AMQP 1.0 against a queue or topic the customer owns.
Why deliver events to Azure Service Bus
- Azure-native, Functions, Logic Apps, and Container Apps all have built-in Service Bus triggers.
- Sessions preserve per-customer or per-resource ordering.
- Built-in dead-letter queues independent of Pushrail's DLQ.
- Enterprise feature set: scheduled delivery, deferral, message TTL, and auto-forward.
How Pushrail delivers events to Azure Service Bus
The adapter publishes one message per event to the configured queue or topic. The canonical event JSON is the message body. Envelope fields are set as application properties. When the destination is sessioned, `SessionId` defaults to `customerExternalId`. `MessageId` is the event's `idempotencyKey` so Service Bus duplicate detection (when enabled) catches repeat sends.
Auth and credentials
Customers authorize Pushrail with a Shared Access Signature on a Send-only access policy (recommended for granularity) or with an Azure AD service principal granted `Azure Service Bus Data Sender` on the namespace. Credentials encrypted at rest; SAS rotations are dashboard-driven.
Batching, retries, and replay
Service Bus supports `SendMessageBatchAsync` up to 1 MB per batch; the adapter uses it. Transient errors (`ServerBusy`, network) retry with exponential backoff. Permanent errors (`Unauthorized`, `MessagingEntityNotFound`) land in the DLQ. Replay re-sends with the same `MessageId`, so namespace-level dedup catches duplicates inside the configured window.
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 Azure Service Bus setup.
{
"type": "AZURE_SERVICE_BUS",
"name": "Customer Service Bus queue",
"namespace": "acme-prod.servicebus.windows.net",
"entityType": "QUEUE",
"entityName": "pushrail-events",
"sessioned": true,
"sessionIdField": "customerExternalId",
"auth": {
"mode": "SAS",
"keyName": "PushrailSender",
"primaryKey": "••••••••"
}
}Common use cases
- Trigger Azure Functions or Logic Apps on every event of a given type.
- Feed enterprise integration patterns (auto-forward, deferral, scheduled enqueue) that Service Bus uniquely offers.
- Session-ordered processing for per-customer or per-resource workflows.
- Bridge into a customer's BizTalk-replacement integration platform.
Related destinations
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.
Deliver events into a customer's EventBridge bus, rule-driven routing inside AWS.
Frequently asked questions
How does Pushrail deliver to Azure Service Bus?
The adapter speaks AMQP 1.0 and publishes one message per event to a customer-owned queue or topic. The canonical event JSON is the message body and envelope fields are set as application properties. It uses SendMessageBatchAsync up to 1 MB per batch.
Does it preserve ordering and catch duplicates?
When the destination is sessioned, SessionId defaults to customerExternalId, preserving per-customer or per-resource order. MessageId is set from the event's idempotency key, so Service Bus duplicate detection (when enabled) catches repeat sends inside the configured window.
Whose credentials are used?
The customer's. They authorize Pushrail with a Shared Access Signature on a Send-only policy (recommended for granularity) or an Azure AD service principal granted Azure Service Bus Data Sender on the namespace. Credentials are encrypted at rest and SAS rotations are dashboard-driven.
What happens if a send fails?
Transient errors like ServerBusy or network issues retry with exponential backoff; permanent errors like Unauthorized or MessagingEntityNotFound land in Pushrail's dead-letter queue. Every attempt is recorded in the delivery logs. The destination's own built-in dead-letter queue remains available independently.