# Reapply complete Axis event filters after a WebSocket reconnect > Axis event WebSocket sessions cannot continue after their connection ends, and only the latest event filter applies. Rebuild the intended subscription after reconnecting. - Canonical URL: https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:10:16+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 event WebSocket sessions cannot continue after their connection ends, and only the latest event filter applies. Rebuild the intended subscription after reconnecting. ## Potentially affected Axis devices exposing the documented Event streaming over WebSocket interface; confirm support and the installed API/software scope before applying the proposed checks. ## DSE recommendation DSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow. ## Article Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session. ## Source fact: documented behavior The [Event streaming over WebSocket](https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/) documentation says each connection is a separate session that ends when the connection terminates. Those sessions are stateless and cannot continue after connection termination. Sending a new configuration request updates the event filter, and only the latest filter applies. ## What the source does not establish Do not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article. ## Applicability questions - Where does the integration retain its complete intended event filter? - Which component sends and verifies subscription configuration after reconnecting? - Does a filter update contain the full desired selection or only an assumed addition? - How will operators recognize an interval when event coverage has not been established? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow. - Write the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready. - Use proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active. - In an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately. ## Verification and evidence Retain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration. Include a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee. ## Official references - [Event streaming over WebSocket](https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/) — 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 — Event streaming over WebSocket - Authority: Axis Communications - URL: https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reapply complete Axis event filters after a WebSocket reconnect,” DSE Security, https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/ 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.