How to Test MQTT with Postman

Yes, you can test MQTT with Postman: create a new request, choose MQTT, enter the broker URL, connect, add topics to subscribe and publish messages from the composer. It is a convenient way to poke at a broker if Postman is already your API tool — but it is a manual client, not an automated MQTT test runner. This guide walks through the workflow, the settings that trip people up, and where Postman stops being the right tool.

Create an MQTT request

1. In Postman, click New (or the + next to your tabs) and choose MQTT.
2. In the URL field, enter the broker address with scheme and port, for example mqtt://broker.connectmq.com:1883.
3. Open the request settings and set a client ID if you want a predictable one; otherwise Postman generates one.
4. If your broker requires authentication, add the username and password (use variables such as {{mqtt_user}} and {{mqtt_pass}} from an environment rather than typing secrets into the request).
5. Click Connect. The message pane shows the connection event, or an error if the broker refused.

The protocol version (3.1, 3.1.1 or 5) is selectable in the request settings. With MQTT 5 you also get fields for connect properties and user properties on published messages.

Not sure which port your broker uses? MQTT ports explained covers 1883, 8883, 8083/8084 and the alternatives behind proxies.

Subscribe to topics

Switch to the Topics area of the request, add a topic filter and pick a QoS. Wildcards work as usual — testmqtt/postman/# receives everything under that prefix, testmqtt/postman/+/status one level of devices. Incoming messages appear in the message list with topic, time and payload; JSON payloads can be expanded.

Use a unique prefix while testing. On a shared endpoint, subscribing to # or a generic name like test/# shows you other people's traffic and makes it hard to see your own. If a filter doesn't match what you expect, paste it into the topic matcher together with the topic you publish to.

Publish messages

The composer at the bottom of the request publishes to one topic at a time:

• Topic: for example testmqtt/postman/device-1/telemetry
• Payload: text or JSON such as {"temp": 21.5, "unit": "C"}
• QoS: 0, 1 or 2
• Retain: on if new subscribers should receive the last value immediately

Saved messages are handy for repeated checks — keep a "turn on", "turn off" and "malformed payload" message in the same request and fire them in turn. Because the request itself is subscribed, you see your own messages arrive, which confirms the round trip through the broker.

A useful hybrid: HTTP in, MQTT out

Postman shines when your system mixes HTTP and MQTT. Open two tabs:

1. An MQTT request subscribed to the topic your backend publishes to, e.g. testmqtt/postman/orders/#.
2. An HTTP request that calls your API — POST /orders, a webhook, a device command endpoint.

Send the HTTP request and watch the MQTT tab: you see whether the backend published, to which topic, with which payload and retain flag. This is the fastest manual check for "the API returns 200 but the device never reacts".

Troubleshooting Postman MQTT connections

Reason codes from the broker (for example 0x87 Not authorized in MQTT 5) can be looked up in the MQTT reason code tool.

Limitations to know

Postman's MQTT support is built for exploring, not for test automation. At the time of writing:

• No test scripts. HTTP requests can run pm.test assertions; MQTT requests cannot assert on incoming messages.
• No Collection Runner or Newman. You can save MQTT requests in collections, but you cannot run them in CI with Newman.
• One connection per tab. Simulating ten devices means ten tabs — or a different tool.
• Desktop-oriented. Non-HTTP protocols in the browser version of Postman may require the Postman Desktop Agent.

Postman evolves quickly, so check its documentation for your version. If you need any of the above today, pick a tool that does it natively.

Alternatives for MQTT testing

For a CI-friendly check that Postman cannot do, two mosquitto commands are enough:

TOPIC="testmqtt/postman/ci-$RANDOM"
mosquitto_sub -h broker.connectmq.com -p 1883 -t "$TOPIC" -C 1 -W 10 > out.txt &
sleep 1
mosquitto_pub -h broker.connectmq.com -p 1883 -t "$TOPIC" -m '{"ok":true}' -q 1
wait
grep -q '"ok":true' out.txt && echo "PASS" || { echo "FAIL"; exit 1; }

-C 1 exits after one message and -W 10 fails after ten seconds, so the script never hangs. More patterns are in mosquitto_pub and mosquitto_sub examples, and the best MQTT client tools compares the GUI options in depth.

Compare with the browser MQTT client

Postman's MQTT request is a good manual tool when your team already lives in Postman, especially for checking that HTTP actions produce the right MQTT messages. For anything repeatable — regression tests, load, many simulated devices — move the same checks into scripts or a dedicated MQTT client, and keep Postman for exploration.

Frequently asked questions