Azure API Management: Directly Publish REST Messages to Service Bus

Azure API Management can now push messages directly into Azure Service Bus using a built‑in policy, removing the need for custom SDKs or middleware and making it far easier to build REST‑driven, event‑oriented integrations from API endpoints to asynchronous backends.

Background​

Azure API Management (APIM) has long served as the central gateway for securing, governing, and observing API traffic across cloud and hybrid environments. APIM policies let operators transform requests, enforce quotas, and call external systems without changing backend code. Until now, pushing messages into Azure Service Bus typically required application code, an intermediary service, or an SDK-based integration using AMQP or the Service Bus REST APIs. The new policy removes much of that friction by letting the gateway itself act as a REST-based publisher to Service Bus, using managed identities for secure authentication. This capability is delivered as a policy named send-service-bus-message (currently in preview), and it supports sending a message payload plus optional message properties to either a Service Bus queue or topic. The policy is intended for outbound eventing scenarios — APIM sends messages; it does not replace AMQP publishers or Service Bus SDKs for advanced messaging features.

---

What changed: the new send-service-bus-message policy​

The policy at a glance​

• Policy name: send-service-bus-message
• Supported targets: Service Bus queue or topic (queue-name or topic-name attribute)
• Authentication: Uses APIM managed identity (system-assigned or user-assigned). You may specify a user-assigned identity by client-id; otherwise the system-assigned identity is used. The identity must be granted the Service Bus Data Sender role.

Key attributes and elements​

• Attributes:
• queue-name or topic-name — choose one to identify the Service Bus destination.
• namespace — the fully qualified domain name of the Service Bus namespace (optional if resolvable by subscription context).
• client-id — (optional) client ID of a user‑assigned managed identity to use for access; if omitted APIM uses its system identity.
• Child elements:
• payload — the message body (must evaluate to a string).
• message-properties — optional name/value metadata pairs to accompany the message.

Example (policy snippet)​

The policy can be inserted into inbound or outbound policy sections. A common pattern is to publish the incoming request body to a queue while forwarding the request to the backend:

<send-service-bus-message queue-name="orders" namespace="my-sb.servicebus.windows.net" client-id="00001111-aaaa-2222-bbbb-3333cccc4444"> <payload>@(context.Request.Body.As<string>(preserveContent: true)</payload> <message-properties> <message-property name="source">api-gateway</message-property> </message-properties>
</send-service-bus-message>

This policy is active as soon as you save it; APIM will publish the message on each policy execution.

---

Why this matters: practical benefits for architects and developers​

• Simpler eventing from HTTP clients: Devices and external partners that can only call HTTP can publish reliably to Service Bus without embedding AMQP libraries or creating separate relay services. APIM becomes the secure REST front door for Service Bus producers.
• Centralized policy and governance: Authentication (managed identity), throttling, validation, transformation, and logging continue to run through APIM policies — so security and operational guardrails remain consistent. This reduces integration sprawl and makes partner onboarding easier.
• Decoupling and scaling: Using Service Bus queues and topics allows backends to process messages asynchronously and scale independently, improving resilience for bursty workloads and long‑running work. This is especially useful for order processing, telemetry ingestion, or partner message ingestion.
• No extra infrastructure required: There’s no need for a dedicated function or microservice to receive HTTP requests and then publish to Service Bus; the gateway performs that publish action directly, lowering operational overhead.

---

Supported scenarios and common use cases​

Typical patterns​

• Fire‑and‑forget APIs: The API accepts a request and publishes the payload to a queue, then returns 201 to the client while processing is handled asynchronously. This reduces latency for the caller and smooths backend load.
• Partner/third‑party integrations: Expose a governed REST endpoint for external systems to post events that become Service Bus messages consumed by internal workflows (Logic Apps, Functions, microservices).
• IoT/telemetry routing: Lightweight devices can POST telemetry to APIM; the gateway forwards messages to Service Bus where ingestion and analytics pipelines consume them.
• API‑first eventing: Existing synchronous APIs can be retrofitted with an APIM policy that publishes certain calls to Service Bus for downstream workflows, with zero backend code changes.

What’s not in scope​

• This capability is preview and supports only sending messages from APIM to Service Bus; it is not a full replacement for AMQP clients and does not yet provide advanced Service Bus client features like custom retry strategies, session handling, or transactional receives inside APIM. Treat it as a gateway‑side publisher for REST-based scenarios.

---

Security, identity, and access control​

Security is central to this integration. APIM publishes to Service Bus using managed identities rather than embedding credentials in policies or client apps.

• Managed identity options:
• System‑assigned managed identity — APIM’s system identity is automatically used if no client-id is provided.
• User‑assigned managed identity — specify the client-id attribute to use a user‑assigned identity. This is useful when the same identity needs to be shared across APIM instances or when role scope must be carefully limited.
• RBAC requirement: The managed identity must be assigned the built‑in role Azure Service Bus Data Sender scoped to the Service Bus namespace, queue, or topic being targeted. This grants only send permission and aligns with least‑privilege principles.
• Network and tenancy: The Service Bus resource can reside in a different subscription or tenant from APIM; however, role assignments and identity trust must be configured appropriately. Use Private Endpoints if you need to restrict Service Bus access to a VNet.

---

Operational considerations and monitoring​

• Observability: APIM already provides request logging and tracing; when you publish to Service Bus through APIM, make sure to capture message identifiers, correlation IDs, and message properties in logs so downstream processing can be traced end‑to‑end. Add message properties deliberately to surface business metadata (e.g., customerId, correlationId).
• Idempotency and retries: Because APIM acts as the publisher, design consumers to handle duplicates or use Service Bus deduplication features if needed. The preview policy does not expose full transactional guarantees, so architect for idempotency where message duplication would be harmful.
• Latency and error handling: If Service Bus is temporarily unavailable, APIM policy behavior and gateway timeouts determine error propagation to callers. Decide whether to return an error, queue the attempt in a retry buffer, or accept the request and log a failed publish for retry. Always test the failure modes in staging.
• Throughput and quotas: APIM and Service Bus have their own throughput characteristics and throttles. High‑volume ingestion should be load‑tested end‑to‑end: APIM tier, gateway performance, and Service Bus throughput (Standard vs Premium) all affect behavior. Use batching at the producer or scale out consumers to match ingestion.

---

Getting started — a practical checklist​

• Create or identify a Service Bus namespace and create the target queue or topic (choose Standard/Premium if you need topics/subscriptions).
• Enable a managed identity on your APIM instance (system‑assigned or create a user‑assigned identity and note its client ID).
• In the Azure portal (or via IaC), assign the identity the Azure Service Bus Data Sender role scoped to the specific queue/topic or namespace.
• Edit the APIM policy for the desired API/operation and add the send-service-bus-message policy into the inbound or outbound policy section. Use policy expressions to map request content to payload and set message properties for tracing.
• Save the policy and test. Consider adding an explicit return-response policy if you want to decouple the API’s HTTP response from backend forwarding behavior (for example return 201 immediately after publishing).

---

Best practices, caveats, and risk mitigation​

• Start small and pilot non‑critical flows. The feature is preview; test thoroughly in a staging environment before moving into production. Observe message loss, duplicate scenarios, and error modes.
• Use message properties for correlation. Add a correlationId and other trace metadata to message properties so downstream telemetry systems can stitch API calls to worker processing. This is especially valuable for distributed tracing and incident analysis.
• Prefer user‑assigned identities for predictable RBAC. If you have multiple APIM instances or need to delegate a single identity across automation flows, user‑assigned identities make role assignment explicit and portable.
• Plan for retries and idempotency. Because the gateway can return to callers independently of downstream processing, implement consumer‑side idempotency or Service Bus deduplication windows where applicable.
• Monitor costs and quotas. Service Bus Standard vs Premium has different pricing and throughput. APIM tiers also influence gateway capacity. Align your tier choices with expected throughput and latency SLAs.
• Security reviews and compliance checks. Even though APIM centralizes authentication, make sure message content does not violate data residency or compliance requirements; use encryption and data minimization where needed. Confirm where message metadata and payloads are persisted in partner or logging systems.

---

Integration examples and patterns​

Pattern: API as event ingress (recommended)​

• APIM receives HTTP POST from client.
• APIM policy validates payload, sets message properties (correlationId, source), and publishes to a Service Bus topic.
• Downstream subscribers (Functions, Logic Apps, microservices) pick up messages and process asynchronously.

Benefits: low client latency, scalable consumers, centralized policy controls.

Pattern: Hybrid tenancy and partner exchange​

• Third‑party partners call an APIM API to submit partner events.
• APIM enforces quotas and transforms messages before publishing to Service Bus.
• Internal systems subscribe to topic partitions for per‑partner routing.

Benefits: controlled partner access and isolation via APIM policies and Service Bus pub/sub.

---

Critical analysis — strengths and potential risks​

Strengths​

• Operational simplicity: The ability to publish to Service Bus directly from APIM drastically reduces the need for glue code or intermediary services for REST‑only producers. This lowers time‑to‑market and simplifies maintenance.
• Security posture: Managed identities plus Azure RBAC keep credentials out of code and reduce secret sprawl. Centralizing authentication and governance in APIM also helps with auditability.
• Event-oriented modernization: The policy supports common modernization patterns — decoupling synchronous front ends from asynchronous backends — enabling simpler migration of legacy APIs to event‑driven architectures.

Risks and limitations​

• Preview status: The feature is currently preview. API shape, behavior, or SLAs may change; preview features often lack production SLAs and can evolve. Don’t assume long‑term guarantees until the feature reaches general availability. Flag: use with caution in production.
• Operational edge cases: The gateway‑side publish model changes failure semantics. If Service Bus is unreachable, gateways must handle error propagation consistently. Teams must test failure and retry behavior thoroughly.
• Feature scope: The policy focuses on sending messages. It does not implement the full Service Bus SDK surface (sessions, transactions across receive/publish boundaries, advanced retry policies). For complex messaging needs, continue to use dedicated messaging clients or microservices.
• Throughput and bottlenecks: At very high ingress volumes, APIM gateway capacity and Service Bus tier selection become critical. The policy pushes work to Service Bus, but APIM must still handle and validate incoming requests; ensure capacity planning and load testing.

---

Migration and adoption roadmap​

• Pilot: Instrument a low‑risk flow (telemetry or batch orders) in a non‑production APIM instance and observe end‑to‑end behavior. Validate message delivery, error handling, and telemetry.
• Hardening: Add correlation properties, idempotency checks, and consumer‑side retries/deduplication as needed. Implement monitoring dashboards combining APIM logs and Service Bus metrics.
• Policy templates: Create reusable APIM policy snippets (payload mapping, message-property patterns, standard return-response behavior) so developers can enable the pattern safely and consistently.
• Governance: Define which APIs are allowed to publish, RBAC boundaries for managed identities, and auditing procedures for message content to meet compliance requirements.

---

Conclusion​

The new send-service-bus-message policy in Azure API Management is a pragmatic and useful addition for architects who want to expose REST endpoints that directly feed Service Bus‑based event pipelines. It simplifies integration for HTTP‑only clients, centralizes security and governance with managed identities, and accelerates adoption of asynchronous, decoupled architectures. However, it is a preview feature with scope limited to sending messages; teams should pilot cautiously, design for idempotency and error handling, and validate throughput and operational behaviors before relying on it for mission‑critical flows. The official Microsoft policy reference and deployment guidance provide the exact policy syntax, attributes, and examples to get started.

---

---

Source: Petri IT Knowledgebase Azure API Management Adds Built-In Policy for Direct Message Publishing to Service Bus - Petri IT Knowledgebase