Skip to content

Build governed asynchronous APIs with Azure API Management and Azure Service Bus

Many applications use Azure Service Bus to decouple services, handle traffic spikes, and process workloads asynchronously. However, securely exposing messaging capabilities to applications, partners, and internal teams can require custom middleware or messaging-specific client implementations. Today, we’re announcing the general availability of native Azure Service Bus integration in Azure API Management.


With the send-service-bus-message policy, developers can publish messages directly from an Azure API Management gateway to an Azure Service Bus queue or topic. This provides a secure and governed HTTP interface for Service Bus workloads—without requiring teams to build and operate a separate adapter service.


Connect APIs directly to Azure Service Bus


Azure API Management can act as the governed entry point for applications that submit work to Azure Service Bus.


A client sends a standard HTTP request to API Management. The gateway can authenticate and authorize the caller, validate or transform the request, and apply policies such as rate limits and quotas before publishing the message to a Service Bus queue or topic. Once the message is accepted, API Management can immediately respond to the caller while downstream services process the message asynchronously. Alternatively, message publication can be added to an existing API flow while the request continues to its primary backend. This integration brings together API governance in Azure API Management and reliable asynchronous messaging in Azure Service Bus—without adding another intermediary service.



Greater control over Service Bus messages


As part of general availability, we’re introducing additional controls for building production messaging workflows.


1. Control how messages are processed

Developers can configure the following Service Bus message properties directly in the policy:





    • Message IDs to correlate messages and support duplicate-detection or idempotent processing patterns.

    • Session IDs to group related messages for ordered or stateful processing.

    • Time-to-live to prevent messages from being processed after they are no longer relevant.




These values can be generated dynamically using API Management policy expressions, allowing them to reflect request IDs, customer identifiers, transactions, or other application context.


2. Capture the send result

The response-variable-name attribute captures information about the Service Bus send operation in an API Management context variable.


Subsequent policies can use the result to add correlation information to an API response, emit telemetry, record an operational event, or apply conditional logic when a message cannot be sent.


3. Choose how failures affect the API

Different messaging scenarios require different failure behavior.





    • When publishing the message is the primary purpose of an API, a send failure can stop policy execution and invoke the API Management error-handling path.

    • When publishing is secondary—such as sending an audit event or initiating optional downstream processing—the ignore-error option can allow the primary API request to continue. Information about the send operation remains available through the response variable for logging or subsequent policy logic.




4. Secure access with managed identity

API Management authenticates to Azure Service Bus using a Microsoft Entra managed identity. Customers can use the system-assigned identity of the API Management service or specify a user-assigned managed identity. The selected identity is granted the Azure Service Bus Data Sender role for the appropriate namespace, queue, or topic. This removes the need to store Service Bus connection strings or shared access keys in API policies and makes it easier to apply least-privilege access using Azure role-based access control.


Send a message with an API Management policy


The following example sends the incoming request body to an orders queue. It assigns a message ID and expiration time, captures the result of the send operation, and treats successful publication as a required part of the API request.


<send-service-bus-message
queue-name=”orders”
namespace=”contoso-messaging.servicebus.windows.net”
message-id=”@(context.RequestId.ToString())”
time-to-live=”00:10:00″
response-variable-name=”serviceBusResult”
ignore-error=”false”>

<payload>
@(context.Request.Body.As<string>(preserveContent: true))
</payload>
</send-service-bus-message>


A session ID can also be added when related messages need to be grouped for ordered or stateful processing. For a fully asynchronous API, the policy can be followed by return-response so that API Management acknowledges the request immediately after sending the message. For an existing API, the request can continue to its configured backend after the message is published.


Common integration scenarios



  1. Create asynchronous APIs: Accept an order, document, or processing request through an HTTP API, publish it to a queue, and return immediately while downstream services complete the work.

  2. Govern partner integrations: Provide partners with a managed API contract instead of exposing the underlying Service Bus namespace. API Management can authenticate callers, validate requests, and apply quotas before publishing messages.

  3. Publish business events: Publish events to a Service Bus topic so multiple subscriptions and downstream services can process them independently.

  4. Handle bursts of incoming traffic: Use Service Bus to buffer messages when incoming API traffic temporarily exceeds the rate at which downstream services can process requests.

  5. Add events to existing API operations: Publish audit, notification, analytics, or workflow events while allowing the primary API request to continue to its configured backend.

  6. Preserve workflow affinity: Use Service Bus sessions to group related messages for ordered or stateful processing based on a customer, transaction, order, or workflow identifier.


Get started


To send messages from Azure API Management to Azure Service Bus:



  1. Create or select an Azure Service Bus queue or topic.

  2. Enable a system-assigned or user-assigned managed identity on the API Management service.

  3. Assign the identity the Azure Service Bus Data Sender role.

  4. Add the send-service-bus-message policy to an API operation.

  5. Configure the message payload, processing properties, output variable, and failure behavior.


With native Azure Service Bus integration, Azure API Management provides a secure and governed way to connect HTTP APIs with asynchronous messaging workloads—without requiring additional middleware.


Learn more


Microsoft Tech Community originally posted this article on 31 August 2026 at 7:38 PM.

Leave a Reply