Event Grid MQTT Broker - HTTP Publish and Retain

Author: spelluru

articles/event-grid/authenticate-with-namespaces-using-webhook-authentication.md

@@ -4,20 +4,18 @@ description: This article shows you how to authenticate with Azure Event Grid na
 ms.topic: how-to
 ms.custom:
   - build-2025
-ms.date: 04/30/2025
+ms.date: 07/30/2025
 author: Connected-Seth
 ms.author: seshanmugam
 ---
 
-# Authenticate with MQTT broker using custom webhook authentication (Preview)
+# Authenticate with MQTT broker using custom webhook authentication
 This article shows how to authenticate with Azure Event Grid namespace using webhook or Azure function. 
 
 Webhook authentication allows external HTTP endpoints (webhooks or functions) to authenticate MQTT connections dynamically. This method uses Microsoft Entra ID JWT validation to ensure secure access.  
 
 When a client attempts to connect, the broker invokes a user-defined HTTP endpoint that validates credentials such SAS tokens, usernames/passwords, or even performs Certificate Revocation List (CRL) checks. The webhook evaluates the request and returns a decision to allow or deny the connection, along with optional metadata for fine-grained authorization. This approach supports flexible and centralized authentication policies across diverse device fleets and use cases. 
 
-> [!NOTE]
-> This feature is currently in preview. 
 
 ## Prerequisites 
 

articles/event-grid/includes/limits.md

@@ -48,6 +48,16 @@ The following limits apply to MQTT in Azure Event Grid namespace resource.
 | Inbound MQTT bandwidth per session        | 1 MB per second                                                                   |
 | Inbound in-flight MQTT messages*        | 1000 messages                                                                   |
 | Inbound in-flight MQTT bandwidth*         | 64 KB                                                             |
+| Inbound HTTP publishing requests per Event Grid namespace | 500 messages per second per TU |
+| Inbound HTTP bandwidth per Event Grid namespace           | 512 KB per second per TU       |
+| Inbound HTTP publishing requests per session              | 500 messages per second        |
+| Inbound HTTP bandwidth per session                        | 512 KB per second              |
+| Inbound in-flight HTTP messages*                          | 500 messages                   |
+| Maximum Retain Message Size                               | 64 KB                          |
+| Maximum Retain Messages per Throughput Unit (TU)          | 10,000 messages or 640 MB (whichever is reached first) |
+| Total Retain Storage per TU                               | 640 MB                         |
+| Retain Message Expiry (MQTT 3.1.1)                        | 365 days (default)             |
+| Retain Message Expiry (MQTT 5.0)                          | Configurable using Message Expiry Interval, range: 0 to 31,536,000 seconds (365 days) |
 | Outbound MQTT publishing requests per Event Grid namespace | 1,000 messages per second per TU                                                         |
 | Outbound MQTT bandwidth per Event Grid namespace        | 1 MB per second per TU                                                            |
 | Outbound MQTT publishing requests per session| 100 messages per second                                                           |
@@ -80,6 +90,7 @@ The following limits apply to MQTT in Azure Event Grid namespace resource.
 | Permission bindings                          | 100                                                                               |
 
 \* For MQTTv5, learn more about [flow control support](../mqtt-support.md#flow-control).
+\* Retain messages count against the total MQTT storage quota for the namespace. When the quota is reached, publishing new retain messages will fail until existing messages are expired or deleted (e.g., via empty payload publish).
 
 ## Events limits in Event Grid namespace
 

articles/event-grid/mqtt-overview.md

@@ -2,7 +2,7 @@
 title: MQTT (PubSub) broker'
 description: Message Queuing Telemetry Transport (MQTT) PubSub broker feature in Azure Event Grid enables MQTT clients to communicate with each other and with Azure services.
 ms.topic: concept-article
-ms.date: 04/30/2025
+ms.date: 07/30/2025
 author: george-guirguis
 ms.author: geguirgu
 ms.subservice: mqtt
@@ -41,12 +41,14 @@ MQTT is a publish-subscribe messaging transport protocol that was designed for c
 	- **Clean start and session expiry** enable your clients to optimize the reliability and security of the session by preserving the client's subscription information and messages for a configurable time interval.
 	- **Negative acknowledgments** allow your clients to efficiently react to different error codes.
    	- **Server-sent disconnect packets** allow your clients to efficiently handle disconnects.
+   	- [MQTT Retain](mqtt-retain.md) ensures that the last published message on a topic is stored by the broker and automatically delivered to any new subscribers. This allows devices to instantly receive the latest known state without waiting for the next update, enabling faster and more reliable state synchronization across IoT systems. 
 
 - MQTT v3.1.1 features:
   	- **Last Will and Testament** notifies your MQTT clients with the abrupt disconnections of other MQTT clients. You can use this feature to ensure predictable and reliable flow of communication among MQTT clients during unexpected disconnections.
 	- **Persistent sessions** ensure reliability by preserving the client's subscription information and messages when a client disconnects.
 	- **QoS 0 and 1** provide your clients with control over the efficiency and reliability of the communication.
--  MQTT broker is adding more MQTT v5 and MQTT v3.1.1  features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: Retain flag, and QoS 2 aren't supported.  
+	- [MQTT Retain](mqtt-retain.md) ensures that the last published message on a topic is stored by the broker and automatically delivered to any new subscribers. This allows devices to instantly receive the latest known state without waiting for the next update, enabling faster and more reliable state synchronization across IoT systems. 
+-  MQTT broker is adding more MQTT v5 and MQTT v3.1.1  features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: QoS 2 isn't supported.  
 
 [Learn more about the MQTT broker and current limitations.](mqtt-support.md) 
 
@@ -77,7 +79,7 @@ Event Grid has a client registry that stores information about the clients permi
 - [Microsoft Entra ID authentication](mqtt-client-microsoft-entra-token-and-rbac.md), which is Azure's authentication standard for applications. [Learn more about MQTT client authentication.](mqtt-client-authentication.md)
 - Flexible authentications
     - [OAuth 2.0 JSON Web Token (JWT) authentication](oauth-json-web-token-authentication.md), which provides a lightweight, secure, and flexible option for MQTT clients that aren't provisioned in Azure.
-    - Custom Webhook authentication allows external HTTP endpoints (webhooks) to authenticate MQTT connections dynamically. It uses the Entra ID JWT validation to ensure secure access.
+    - [Custom Webhook authentication](authenticate-with-namespaces-using-webhook-authentication.md) allows external HTTP endpoints (webhooks) to authenticate MQTT connections dynamically. It uses the Entra ID JWT validation to ensure secure access.
 
 
 ### Access control
@@ -103,7 +105,7 @@ Route MQTT messages and Cloud Events from Event Grid Namespace to Fabric Event S
 
 
 ### Edge MQTT broker integration
-Event Grid integrates with [Azure IoT Operations](../iot-operations/manage-mqtt-broker/overview-broker.md) to bridge its MQTT broker capability on the edge with Azure Event Grid’s MQTT broker feature in the cloud. Azure IoT Operations provides a new distributed MQTT broker for edge computing, running on Arc enabled Kubernetes clusters. It can connect to Event Grid MQTT broker with Microsoft Entra ID authentication using system-assigned managed identity, which simplifies credential management. MQTT Broker provides high availability, scalability, and security for your IoT devices and applications. It's now available in [public preview](../iot-operations/manage-mqtt-broker/overview-broker.md) as part of Azure IoT Operations. [Learn more about connecting Azure IoT Operations MQTT Broker to Azure Event Grid's MQTT broker](../iot-operations/connect-to-cloud/howto-create-dataflow.md).
+Event Grid integrates with [Azure IoT Operations](../iot-operations/manage-mqtt-broker/overview-broker.md) to bridge its MQTT broker capability on the edge with Azure Event Grid’s MQTT broker feature in the cloud. Azure IoT Operations provides a new distributed MQTT broker for edge computing, running on Arc enabled Kubernetes clusters. It can connect to Event Grid MQTT broker with Microsoft Entra ID authentication using system-assigned managed identity, which simplifies credential management. MQTT Broker provides high availability, scalability, and security for your IoT devices and applications. [Learn more about connecting Azure IoT Operations MQTT Broker to Azure Event Grid's MQTT broker](../iot-operations/connect-to-cloud/howto-create-dataflow.md).
 
 ### MQTT Clients Life Cycle Events
 
@@ -114,6 +116,15 @@ Client Life Cycle events allow applications to react to events about the client
 Custom domain names support allows users to assign their own domain names to Event Grid namespace's MQTT and HTTP endpoints, enhancing security and simplifying client configuration. This feature helps enterprises meet their security and compliance requirements and eliminates the need to modify clients already linked to the domain. Assigning a custom domain name to multiple namespaces can also help enhance availability, manage capacity, and handle cross-region client mobility. Learn more about [Custom domain names](custom-domains-namespaces.md).
 
 
+### MQTT Retain (preview) 
+
+An MQTT retain message is used to store the last known good value of a topic on the broker, ensuring that new subscribers immediately receive the most recent message without waiting for the next publish. This is especially useful in scenarios like device state reporting, control signals, or configuration data where the latest message must always be available to clients on connect. For more information, see [MQTT retain support in Azure Event Grid](mqtt-retain.md).
+
+ 
+### HTTP Publish(preview) 
+
+HTTP Publish enables applications to publish MQTT messages to Azure Event Grid MQTT Broker over a simple HTTPS POST request, without maintaining an active MQTT session. It’s best suited for scenarios where MQTT clients are not feasible or necessary—such as serverless functions, cloud services, or backend applications—allowing event-driven architectures to inject MQTT messages reliably and securely. Common use cases include publishing device commands, alerts, or control signals from Azure Functions, Logic Apps, or API integrations. 
+
 ## Concepts
 See the following articles for concepts of MQTT broker in Azure Event Grid: 
 

articles/event-grid/mqtt-retain.md

@@ -0,0 +1,43 @@
+---
+title: MQTT Retain in Azure Event Grid (Preview)
+description: Learn how Azure Event Grid supports the MQTT Retain feature to store the last known good value of a topic so new subscribers get the latest message instantly.
+#customer intent: As a developer, I want to understand how MQTT Retain works in Azure Event Grid so I can ensure new subscribers get the latest message instantly.  
+ms.topic: concept-article
+ms.date: 07/30/2025
+ms.custom:
+  - ai-gen-docs-bap
+  - ai-gen-title
+  - ai-seo-date:07/30/2025
+  - ai-gen-description
+---
+
+## MQTT retain support in Azure Event Grid (preview)
+The MQTT Retain feature in Azure Event Grid (Preview) ensures that the last known good value of a topic is stored and readily available for new subscribers. This capability allows new clients to instantly receive the most recent message upon connection, eliminating the need to wait for the next publish. It is beneficial in scenarios such as device state reporting, control signals, or configuration data, where timely access to the latest message is critical. 
+
+This article provides an overview of how the MQTT Retain feature works, its billing implications, storage limits, message deletion methods, and retain management considerations.
+
+> [!NOTE]
+> This feature is currently in preview. 
+
+## Billing
+Each retained publish counts as two MQTT operations—one for processing the message, and one for storing it.
+
+## Storage limits: 
+
+- Up to 640 MB or 10,000 retain messages per Throughput Unit (TU). 
+- Maximum size per retain message: 64 KB. 
+
+For larger needs, contact Azure Support. 
+
+## Message deletion 
+
+**MQTT 3.1.1**: Publish an empty payload to the topic. 
+**MQTT 5.0**: Set expiry or send an empty message to remove it. 
+
+## Retain management 
+
+- Azure portal support for listing retain messages is currently not available. 
+- Preview doesn't include backfilling retain data for existing namespaces. 
+- To enable the Retain feature on an existing namespace, do one of the following operations: 
+    - Perform a control plane operation – Like Throughput Unit (TU) Updates. 
+    - Add or update the **Retain** tag on the namespace. 

articles/event-grid/mqtt-support.md

@@ -6,7 +6,7 @@ ms.custom:
   - ignite-2023
   - build-2024
   - build-2025
-ms.date: 04/30/2025
+ms.date: 07/30/2025
 author: george-guirguis
 ms.author: geguirgu
 ms.subservice: mqtt
@@ -15,7 +15,7 @@ ms.subservice: mqtt
 # MQTT features supported by Azure Event Grid’s MQTT broker feature
 MQTT is a publish-subscribe messaging transport protocol that was designed for constrained environments. It’s efficient, scalable, and reliable, which made it the gold standard for communication in IoT scenarios. MQTT broker supports clients that publish and subscribe to messages over MQTT v3.1.1, MQTT v3.1.1 over WebSockets, MQTT v5, and MQTT v5 over WebSockets. MQTT broker also supports cross MQTT version (MQTT 3.1.1 and MQTT 5) communication.
 
-
+MQTT broker in Azure Event Grid also supports devices and services sending MQTT messages over HTTPS, simplifying integration with non-MQTT clients. Event Grid allows you to send MQTT messages to the cloud for data analysis, storage, and visualizations, among other use cases. This feature is currently in preview.
 
 MQTT v5 introduced many improvements over MQTT v3.1.1 to deliver a more seamless, transparent, and efficient communication. It added:
 - Better error reporting.
@@ -134,7 +134,7 @@ MQTT v5 ensures in-order message delivery within per topic and per client when u
 
 However, it doesn't guarantee ordering across different topics or when messages are sent with varying QoS levels. To learn more, contact us [[email protected]](mailto:[email protected]).
 
-### Assigned Client Identifiers (Preview) 
+### Assigned Client Identifiers 
 MQTT v5 introduces support for assigned client identifiers, allowing the broker to generate and return a unique client ID when one isn't provided by the client. MQTT broker supports this feature, ensuring seamless client onboarding and reducing the need for clients to manage their own identifiers. It's especially useful in scenarios where client provisioning is dynamic or when devices have no preconfigured identity. Assigned client IDs can be retrieved from the CONNACK response and reused for future sessions to maintain consistent identification. 
 
 #### Managing client identifier and session limits in MQTT 
@@ -152,7 +152,6 @@ MQTT broker is adding more MQTT v5 and MQTT v3.1.1 features in the future to ali
 
 MQTT v5 currently differs from the [MQTT v5 Specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html) in the following ways:
 - Shared Subscriptions aren't supported yet.
-- Retain flag isn't supported yet.
 - Maximum Will delay interval is 300.
 - Maximum QoS is 1.
 - Maximum Packet Size is 512 KiB
@@ -166,7 +165,7 @@ MQTT v5 currently differs from the [MQTT v5 Specification](https://docs.oasis-op
 ### MQTTv3.1.1 current limitations
 
 MQTT v5 currently differs from the [MQTT v3.1.1 Specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) in the following ways:
-- QoS2 and Retain Flag aren't supported yet. A publish request with a retain flag or with a QoS2 fails and closes the connection.
+- QoS2 isn't supported yet. A publish request with a retain flag or with a QoS2 fails and closes the connection.
 - Keep Alive Maximum is 1,160 seconds.
 
 ## Code samples