# Keep Axis MQTT event publication filters at the topic layer > Axis MQTT Event Bridge publication filters apply to event topics, not payload content. Design event selection at that documented boundary before connecting downstream automation. - Canonical URL: https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:28+00:00 - Modified: 2026-10-29T00:10:34+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Axis MQTT Event Bridge publication filters apply to event topics, not payload content. Design event selection at that documented boundary before connecting downstream automation. ## Potentially affected Axis devices exposing the documented MQTT Event Bridge interface; confirm support and the installed API/software scope before applying the proposed checks. ## DSE recommendation DSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation. ## Article Bottom line: Choose the event topics at the Axis bridge, then place any required payload decision in a separately designed consumer. ## Source fact: documented behavior The [MQTT Event Bridge](https://developer.axis.com/vapix/network-video/mqtt-event-bridge/) documentation says event publications are enabled only after filters have been set. Those publication filters apply only to topics; payload filtering is not possible through that filter configuration. The documented configuration-read operation returns the current event publication configuration. ## What the source does not establish Do not assume that a topic filter expresses a condition on a field inside an event payload. Keep bridge selection separate from the broker connection checks and application rules. Require the actual event-topic contract for the device and integration before approving a topic pattern. Do not present the proposed consumer design as a feature supplied by this API. ## Applicability questions - Which device events must leave the camera, and which topics represent them? - Does the requested business condition depend on a topic or a value inside the payload? - Where will any additional payload-based decision be implemented and reviewed? - How will the team verify that unrelated topics remain outside the publication selection? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation. - Describe the desired input without starting from a wildcard. For a proposed pilot, select one required event topic and one nearby topic that should remain excluded. Write the operational reason for each selection. If the requirement refers to a payload value, put that condition in the consumer column and assign an owner to design it. Do not relabel the payload requirement as a bridge filter. - Apply the supported topic selection on a test device, then read the current publication configuration back. Compare that returned configuration with the intended topic list. Keep this evidence separate from proof that the MQTT client connects to its broker. An integration worksheet should give each of those checks its own result and owner. - Exercise representative included and excluded events through an authorized test arrangement. At the consumer, compare the received event topic and payload with the written contract before allowing a consequential action. Use a logging-only destination first where practical. Review unexpected traffic as a selection or interpretation problem, rather than widening filters until an application appears to work. ## Verification and evidence Preserve the intended topic list, returned bridge configuration, sanitized broker observations and consumer decision record. Use stable test labels so a reviewer can tell the deliberately excluded event from a missing required event. Record any payload logic as separately maintained application behavior. Repeat the proposed cases after changing topic filters, device software or the consumer’s event mapping. Include a requirement that cannot be expressed by topic selection alone and confirm that the design review routes it to the appropriate consumer work. These are proposed DSE verification steps, not a claim that any MQTT deployment or automation was tested. ## Official references - [MQTT Event Bridge](https://developer.axis.com/vapix/network-video/mqtt-event-bridge/) — Axis Communications; official VAPIX documentation. Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings. ## Primary reference - Name: Axis Communications — MQTT Event Bridge - Authority: Axis Communications - URL: https://developer.axis.com/vapix/network-video/mqtt-event-bridge/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep Axis MQTT event publication filters at the topic layer,” DSE Security, https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.