# Distinguish an active Axis MQTT client from a connected session

> Check the broker connection state separately from the MQTT client’s activation state when diagnosing missing camera messages.

- Canonical URL: https://update.dsesecurity.com/updates/axis-mqtt-active-versus-connected-client-status/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T00:43:15+00:00
- Modified: 2026-10-15T00:44:32+00:00
- Last reviewed by DSE: 2026-10-14
- Resource type: Guide
- DSE priority: Information
- Topics: Networks & Infrastructure, Video Surveillance
- Reading time: 2 minutes

## What you need to know

Check the broker connection state separately from the MQTT client’s activation state when diagnosing missing camera messages.

## Potentially affected

Use this guide for Axis devices exposing the MQTT client API. Confirm API discovery and supported versions on the actual device before relying on a particular integration.

## DSE recommendation

DSE recommends making broker connection state an explicit diagnostic field rather than interpreting an enabled toggle as message-delivery evidence.

## Article

Check the broker connection state separately from the MQTT client’s activation state when diagnosing missing camera messages.

## Source facts

Axis documents an MQTT client with active and inactive lifecycle states. An active client may already be connected or may still be trying to connect to the configured broker. Activation persists after a reboot. The getClientStatus operation returns status and configuration, while getSupportedVersions identifies API versions supported by the device. Configuration and activation are separate operations in the documented interface.

Source: [Axis Communications — VAPIX MQTT client API](https://developer.axis.com/vapix/network-video/mqtt-client-api/).

## Applicability

Use this guide for Axis devices exposing the MQTT client API. Confirm API discovery and supported versions on the actual device before relying on a particular integration.

## DSE recommendation

DSE recommends making broker connection state an explicit diagnostic field rather than interpreting an enabled toggle as message-delivery evidence. Record the intended broker, client identifier, transport, trust configuration, and authorized topic scope without saving passwords. Review camera-side state alongside broker-side logs. Keep MQTT connection checks separate from recording health so one successful subsystem does not conceal another failure. Define who responds when a client remains active but cannot establish its broker session, and preserve a supported recovery procedure.

## Verification

In an approved pilot, verify configuration, activation, broker connection, and receipt of a representative message as separate checkpoints. Restart the test device and observe reconnection. Include a controlled broker-unavailable case and record how monitoring distinguishes an activated client from a working message path.

## Official reference

[Axis Communications — VAPIX MQTT client API](https://developer.axis.com/vapix/network-video/mqtt-client-api/). Reviewed October 14, 2026.

## Primary reference

- Name: Axis Communications — VAPIX MQTT client API
- Authority: Axis Communications
- URL: https://developer.axis.com/vapix/network-video/mqtt-client-api/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish an active Axis MQTT client from a connected session,” DSE Security, https://update.dsesecurity.com/updates/axis-mqtt-active-versus-connected-client-status/
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.