What Is MQTT Request/Response with a Response Topic?
MQTT is built for one-way publish/subscribe, but real control systems need to ask a question and get an answer, a write command that returns success or failure. MQTT 5 makes that pattern first-class with two properties: response topic and correlation data. For an engineer wiring operator writebacks, they turn ad hoc reply schemes into a standard. This page explains how the pattern works and where it fits control workflows.
MQTT Request/Response Pattern in one line: The MQTT request/response pattern uses two MQTT 5 properties. The requester includes a response topic, telling the responder where to publish its reply, and correlation data, an opaque token the responder echoes so the requester can match the reply to the original request. This lets a client send a command and reliably receive the corresponding answer over an inherently one-way pub/sub protocol.
How Response Topic and Correlation Data Work Together
The response topic property is set by the requester on its request PUBLISH. It carries the name of the topic on which the requester expects the reply, so the responder does not have to know in advance where to send its answer; the request tells it. The requester subscribes to that response topic first, then publishes the request. The responder processes the request, then publishes its result to the response topic named in the request. This is the piece that gives pub/sub a return path without hard-coding reply routing.
Correlation data is the second half, and it solves matching rather than routing. It is an opaque binary token the requester attaches to the request; the responder must copy it, unchanged, onto the reply. When several requests are in flight on the same response topic, the requester uses the correlation data to pair each incoming reply with the specific request it answers. Without it, a client that issued three commands could not tell which of three replies belongs to which command. It is functionally a correlation identifier, familiar to anyone who has built request/reply over messaging.
Together the two properties turn a pattern people used to hand-roll into a supported convention. Before MQTT 5, engineers built request/reply by inventing their own reply-topic and request-id fields inside the payload, and every system did it differently. Standardizing them as protocol properties means a responder can implement the pattern generically, and it composes with other MQTT 5 features like user properties for additional context on the request.
Where the Pattern Fits Control Workflows
The obvious control use is an operator writeback that needs confirmation. An operator changes a setpoint from a cloud HMI; the request carries the new value and a response topic; the edge device applies it and replies on that topic with success, a failure reason, or the accepted value. The correlation data ties the confirmation to the exact write the operator issued, so the HMI can show a definitive result rather than optimistically assuming the write landed. That confirmation loop is what makes remote writes trustworthy.
There is an important relationship with Sparkplug. Sparkplug defines its own command channel through the DCMD and NCMD commands for writing to metrics, so a pure Sparkplug system typically uses that mechanism rather than the generic request/response properties. The MQTT 5 request/response pattern is more at home in plain-MQTT designs, or for control-plane operations that sit outside the Sparkplug metric model, such as asking a gateway to report its firmware version or trigger a diagnostic.
A few cautions keep the pattern safe. The requester should apply a timeout, because a reply may never come if the responder is offline, and it should not block forever waiting. Response topics should be chosen so replies are not accidentally seen by clients that should not see them, since a reply may carry sensitive result data. And the correlation data must be genuinely unique per outstanding request, or two concurrent requests could be confused. Handled with those disciplines, request/response gives control workflows a clean, standard shape.
Frequently Asked Questions
Does the responder need to know the reply topic in advance?
No, and that is the point of the response topic property. The requester includes the topic it wants the reply on inside the request message itself, so the responder simply reads the response topic property and publishes its answer there. This decouples the responder from any hard-coded reply routing and lets each requester choose its own reply topic, which is what makes the pattern work generically across many requesters and a single responder without prior agreement on topic names.
Should I use MQTT request/response or Sparkplug commands for writes?
It depends on your stack. In a Sparkplug B system, writes to metrics go through the defined DCMD and NCMD command messages, which fit the Sparkplug model and its birth-defined metric set, so you would normally use those rather than the generic request/response properties. The MQTT 5 request/response pattern suits plain-MQTT designs, or control-plane operations outside the Sparkplug metric model such as querying a gateway or triggering a diagnostic, where the standard response-topic and correlation-data properties give you a clean reply channel.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.