Since you’ve got it working over BPUP: the MQTT message payload would be the same as the BPUP payload, so, most importantly, "m" the HTTP-equivalent method, "b" the body, and "s" is the HTTP-equivalent status. We’ll get around to testing the api/mqtt endpoint so that you could use a custom broker, and making this clear in the docs.
There’re two differences I can think of: the "B" (Bond ID) is not necessary for anything other than BPUP, and the "t" (topic) is not needed, as it is extracted from the MQTT topic.
The Bond will subscribe to v2/<Bond ID>/down/#, where the wildcard # is equivalent to the HTTP endpoint less v2/, and publish to v2/<Bond ID>/up/<topic>
One example: the MQTT equivalent to HTTP GET v2/devices is an MQTT message on the topic v2/<Bond ID>/down/devices with a payload of {"m": 0} (but 0 (GET) is the default for "m" (method), so this payload could simply be {})
If you have a device, the Bond would then publish an MQTT message on the topic v2/<Bond ID>/up/devices with a payload of {"s": 200, ..., "b": {<dev_id>: <dev_hash>}}
You can add request IDs with "i", which is especially useful if you intend to use multiple transports, as our mobile apps do, or in general to link “requests” to “responses”.
Note: you can also send “requests” over BPUP this way, it’s not just a push protocol.