What Is an MQTT Subscription Identifier?
A subscription identifier is a small MQTT 5 convenience that solves a real dispatch problem: when a message arrives, which of my subscriptions caused it? For a SCADA client that subscribes to many overlapping topic patterns, it is the header that tells the client exactly which handler to call. This page explains how a subscription identifier is set, how the broker echoes it, and why overlapping wildcard subscriptions make it useful.
MQTT Subscription Identifier in one line: An MQTT subscription identifier is an integer a client attaches to a SUBSCRIBE request in MQTT 5. The broker remembers it and includes it as a property on every PUBLISH that matches that subscription. When a message arrives carrying the identifier, the client immediately knows which of its subscriptions triggered the delivery and can dispatch the message to the correct handler without re-matching topics itself.
How the Identifier Is Assigned and Returned
The client chooses the identifier, a positive integer, and includes it as a property on the SUBSCRIBE packet. From then on the broker associates that number with the subscription. Whenever a published message matches the topic filter of that subscription, the broker copies the subscription identifier into the properties of the PUBLISH it delivers to the client. The client reads the identifier off the incoming message and uses it as a routing key. It is purely a client-side convenience implemented with broker cooperation; the publisher is unaware of it.
The value of this becomes obvious with overlapping subscriptions. A client might subscribe to a specific device's data topic and also to a plant-wide wildcard that includes that same device, using the plus and hash wildcards. A single published message can match both filters. Without subscription identifiers the client must re-run its own topic matching on every arrival to figure out why the message came, which duplicates work the broker already did. With identifiers the broker simply tells it, and where a message matches two subscriptions the broker returns both identifiers.
This ties into the retain-handling and no-local subscription options because all of them are configured per subscription on the SUBSCRIBE packet in MQTT 5. The subscription identifier is the one that most directly changes application code structure, because it lets you build a clean dispatch table keyed by integer rather than a chain of topic-pattern comparisons in the message callback. On a client that handles thousands of messages a second, avoiding a topic re-match on every one is not a trivial saving.
Where It Fits a SCADA Consumer
A cloud SCADA ingestion service is exactly the kind of client that subscribes to many patterns at once: one subscription for Sparkplug birth and death messages, another for data messages, another for command acknowledgements, perhaps a broad diagnostic wildcard. Each of these wants a different handler. Tagging each subscription with an identifier lets the message loop be a simple switch on the returned identifier, which keeps the hot path fast and the code readable, and it complements a clean database ingestion pipeline.
The identifier does not replace the topic; the message still carries its full topic, which the handler needs to know which specific device or metric the message concerns. What the identifier saves is the classification step, the decision about which category of message this is. You still parse the topic to extract the group, edge node, and device from a Sparkplug hierarchy, but you no longer have to guess which subscription pattern brought the message to you.
Support is not universal, and that is the practical catch. A broker advertises whether it supports subscription identifiers in its CONNACK. A well-written client must handle both cases: use the identifier for fast dispatch when the broker offers it, and fall back to matching the topic against its own subscription list when it does not. Designing the consumer so that the identifier is an optimization rather than a requirement keeps it portable across brokers of differing capability.
Frequently Asked Questions
Can one message carry more than one subscription identifier?
Yes. If a single published message matches several of a client's subscriptions, each of which was given its own identifier, the broker includes every matching identifier as a separate property on the delivered PUBLISH. The client then knows the message satisfied all of those subscriptions at once. This is precisely the overlapping-wildcard case that makes the feature worthwhile, since it tells the client the full set of reasons the message was delivered without the client re-running any topic matching.
Is a subscription identifier the same as a client identifier?
No, and the names invite confusion. A client identifier is the unique name a client presents in its CONNECT packet to identify its session to the broker. A subscription identifier is an integer the client attaches to one particular SUBSCRIBE, echoed back on matching messages, used only for routing incoming publishes to handlers. One names the whole session; the other labels a single subscription within it. They live in different packets and serve entirely different purposes.
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.