Azure API Management now provides a generally available policy for sending messages to Azure Service Bus. Using the send-service-bus-message policy, an API request can send a message directly to a Service Bus queue or topic. This allows you to put a governed HTTP API in front of an asynchronous messaging solution, without adding an intermediary service just to translate and forward the request.

The API Management announcement explains how to configure the policy. In this post, we look at the Service Bus patterns you can use behind that API.

Add an asynchronous boundary to your API

An API often needs to accept a request without making the caller wait for all the work behind it to finish. For example, submitting an order might start inventory checks, payment processing, fulfillment, and customer notifications. A file upload might start validation and several other workflows.

API Management handles the synchronous API boundary. It can authenticate and authorize callers, validate or transform requests, and apply quotas and rate limits. The policy then sends the message to a pre-created Service Bus queue or topic, where consumers can process it independently.

This means the API can return an acceptance response while Service Bus holds the work for downstream processing. Producers and consumers can run at different rates, and a temporary issue in a consumer does not have to become an API failure.

API Management authenticates to Service Bus using a system-assigned or user-assigned managed identity with the Azure Service Bus Data Sender role. Applications calling the API only need access to the API, not to the Service Bus namespace.

Queue-backed APIs for commands and work items

A queue fits when an API request represents a command or work item that one consumer should complete. Examples include process this order, generate this document, or import this file.

The producer and consumer do not have to be available at the same time. Once Service Bus accepts the message, the consumer can process it independently of the original API request. This is useful for long-running work and integrations where the downstream system has limited availability.

A queue also provides load leveling. It absorbs bursts of requests while consumers process messages at a sustainable rate. Multiple competing consumers can share the work, and you can scale those consumers without changing the public API.

For workflows where the caller needs the final result, the API can expose a status endpoint or the application can send a notification when processing completes.

Send commands to the right processor

A queue fits when every command follows the same processing path. Use a topic when the same API sends work to different processors. For example, a document API can add the document type, tenant, region, or priority to the message properties. Subscription filters then direct each message to the right processor while callers continue to use one HTTP API.

Each subscription has its own consumers and message state, so every processing path can scale independently. You can add or change the routing without changing the public API.

Carry messaging information across the API boundary

The policy can set the message body, application properties, message ID, session ID, and time-to-live. This allows the API to include information that Service Bus and downstream consumers can use:

• Add properties such as command type, tenant, region, or schema version for routing and filtering.
• Set a valid GUID as the message ID, such as the API Management request ID, when using Service Bus duplicate detection. Consumers should still process messages idempotently, as retries can happen elsewhere in the workflow.
• Set a valid GUID as the session ID to process related messages in order. The queue or topic subscription must have sessions enabled, and the consumer must accept the session.
• Set a time-to-live when work is no longer useful after a specific period.

API Management can also store the result of the send in a policy variable. A send failure normally enters API Management error handling, or you can configure the policy to continue and handle the result in the API flow.

Where this pattern fits

This integration is useful when callers use HTTP while the system behind the API uses asynchronous messaging. Partners, web applications, mobile applications, and webhook producers can call a governed API without needing an AMQP library or access to Service Bus. Behind the API, you can use queues and topics for buffering, independent scaling, competing consumers, and command routing.

The policy covers the send side of the integration. Consumers use the Service Bus SDKs or supported protocol integrations to receive and process the messages.

More information can be found in the API Management policy reference, the configuration guide, and the Service Bus queues, topics, and subscriptions documentation.