MQTT follows a publish-subscribe model where publishers and subscribers are fully decoupled. This simplifies asynchronous messaging but introduces a challenge: a publisher has no built-in way to confirm whether the intended subscriber received or acted on a message.
Before MQTT 5.0, implementing request-response communication required workarounds. Requesters and responders had to agree on fixed topics in advance. When multiple requesters shared the same response topic, each requester received every response with no protocol-level mechanism to match a response to its original request.
MQTT 5.0 solves this with two new PUBLISH packet properties: Response Topic and Correlation Data. Together, they enable native request-response communication without custom topic conventions or external tracking.
How it works
A request-response exchange has four steps:
The requester subscribes to a response topic.
The requester publishes a message to a request topic with the Response Topic and Correlation Data properties set in the PUBLISH packet.
The responder receives the request, processes it, and publishes the result to the response topic specified in the request. The responder copies the correlation data from the request into the response.
The requester receives the response and uses the correlation data to match it to the original request.
MQTT 5.0 properties
Response Topic
A Response Topic is a UTF-8 string included in a PUBLISH packet. It tells the responder where to send the reply.
Unlike pre-5.0 workarounds, the requester sets the response topic dynamically per request. A common practice is to include the client ID in the response topic (for example, responses/client1234/result) to prevent different requesters from receiving each other's responses.
| Attribute | Value |
|---|---|
| Data type | UTF-8 string |
| Packet type | PUBLISH |
| Required | No. If omitted, the message is not treated as a request. |
Correlation Data
Correlation Data is binary data attached to a PUBLISH packet. It lets the requester match a response to a specific request when multiple requests are in flight.
The responder copies the correlation data from the incoming request into the outgoing response without modification. The requester then uses this data to identify which request the response belongs to.
| Attribute | Value |
|---|---|
| Data type | Binary |
| Packet type | PUBLISH |
| Required | No. Optional even when Response Topic is set. Useful when multiple concurrent requests share the same response topic. |
Use cases
Remote device control: Send a command to an IoT device and get a confirmation. For example, turn on a smart home light and receive an acknowledgment that the light is on.
Service invocation: Call a backend service and receive the result. For example, request the latest weather data from a weather service and get the forecast in return.
Remote Procedure Call (RPC): Invoke a remote function and wait for the return value, similar to a synchronous function call over an asynchronous transport.
Data retrieval: Query a dataset and receive the results. For example, request the current configuration of a device or the contents of a database record.
Example: query device configuration
The following example shows how to query the configuration of an IoT device using the request-response pattern.
All messages use the PUBLISH packet with the Response Topic and Correlation Data properties set.
Request (sent by the requester)
PUBLISH
Topic: requests/device1/getConfig
Response Topic: responses/device1/getConfig
Correlation Data: { "requestId": "abcdef12345" }
Payload: {}The empty payload signals a read operation -- the requester wants the current configuration without sending any update.
Response (sent by the device)
PUBLISH
Topic: responses/device1/getConfig
Correlation Data: { "requestId": "abcdef12345" }
Payload: { ...configuration data... }The device publishes the configuration to the response topic specified in the request. It includes the same correlation data so the requester can match this response to the original request.
Step-by-step flow
The requester subscribes to
responses/device1/getConfig.The requester publishes a PUBLISH message to
requests/device1/getConfigwith the Response Topic set toresponses/device1/getConfigand Correlation Data set to{"requestId": "abcdef12345"}.The device receives the request on
requests/device1/getConfig, reads its configuration, and publishes the result toresponses/device1/getConfigwith the same Correlation Data.The requester receives the response on
responses/device1/getConfigand matches it to the original request using the correlation data.
Best practices
Subscribe before publishing: Subscribe to the response topic before sending the request. Otherwise, the response may arrive before the subscription is active and get lost.
Use unique response topics: Include the client ID or a session identifier in the response topic (for example,
responses/<client-id>/getConfig). This prevents different requesters from receiving each other's responses.Set correlation data for concurrent requests: When sending multiple requests to the same response topic, use unique correlation data (such as a UUID) for each request to match responses correctly.
Verify topic permissions: Confirm that both the requester and the responder have the appropriate publish and subscribe permissions. The requester needs subscribe access to the response topic, and the responder needs publish access to it.
Handle timeouts: The MQTT protocol does not enforce a response timeout. Implement a client-side timeout to handle cases where the responder is unavailable or the response is lost.
With the request-response pattern, MQTT 5.0 extends beyond the traditional publish-subscribe model to support interaction patterns such as client-server architectures -- enabling synchronous-style communication over an asynchronous protocol.