Changelog

Reference·Audience: All personas·Use: check before an upgrade

What this documentation describes, and what changed on the reader itself.

Two different things are versioned

The MQTT API contract is versioned as an AsyncAPI document, and this page is authoritative for the contract baseline these pages describe.

The firmware is versioned by Zebra, in release strings such as SAAFKS00-013-R05. The two move independently: a firmware release can change what the reader does without changing the contract, and the contract can be reissued without a firmware release. Both records are below.

Current Baseline

Contract version described	1.22.0, the IoT Connector API version the contract describes
Contract file format	AsyncAPI 3.0.0, the standard format for describing event-driven APIs
Protocol the reader speaks	MQTT 3.1.1
apiVersion values the contract declares	V1.0, V1.1, V1.2, V1.21, V1.22
Latest firmware release recorded here	SAAFKS00-013-R05, released 15 July 2026
IOTC API version that firmware reports	Minor version 1.21, set in SAAFKS00-013-R02
Hardware in scope	RFD40 and RFD90 handheld RFID readers

apiVersion is reported by each command handler, not once for the reader, and the contract does not say which command reports which value. Don't use it to decide which features a reader supports. See API Version Reporting.

A reader's own firmware and IoT Connector versions come from get_version: readerVersion.firmwareVersion and readerVersion.detailedVersions.iotcVersion.

What Changed in the Firmware

The IoT Connector is firmware, so most of what a client notices changes here rather than in the contract. This is the IOTC-relevant part of Zebra's own record, from the RFD40/RFD90 release notes for SAAFKS00-013-R05 and the RFD40/RFD90 change log. It is not the whole firmware history: Bluetooth, scanning, charging and host-integration changes are in Zebra's documents.

SAAFKS00-013-R05

Released 15 July 2026. RFID module firmware 2.0.54, product code PAAFKS00-013-R05.

• Certificates are validated before they are installed, and the status alerts that report the outcome are clearer.
• MQTT recovers from TLS and certificate errors instead of stalling.
• Firmware updates over IoT Connect work in EU RED regions, through pre-authorized secure endpoints.
• Certificate and network-configuration handling was hardened against oversized payloads, and an IoT write failure for payloads longer than 128 characters was fixed.
• Invalid WPA2 and WPA3 Enterprise EAP combinations are rejected when the profile is created, rather than failing later.
• Wi-Fi is re-enabled automatically after a reboot, and after the sled is undocked from an Ethernet cradle.
• All 32 pre-filters are restored after a radio power cycle.
• Reading Axzon Magnus temperature sensor tags, and FastID for faster TID retrieval, are supported. FastID is not available in Gen2X inventory mode.

Two notes that affect integrations. Certificate validity is checked against the reader's own clock, so a reader whose time is wrong can reject a valid certificate as expired or not yet valid. And there is a known, intermittent reset when an IoT connection is established through the communication cradle.

SAAFKS00-013-R02

• The IOTC API minor version became 1.21.
• IoT API replies carry richer device identity metadata and additional battery telemetry fields.
• Certificate install accepts content-based input — the material can be supplied inline instead of by URL.
• Endpoint activation bugs were fixed, including false "No active EP" notifications.
• Error messages for unrecognized or malformed commands became structured and informative.
• New inventory modes were introduced: Gen2 (the existing default), Gen2X, and Hybrid. Gen2X is limited to inventory operations.
• Full support for the RFD40-M. It needs the latest 123RFID Desktop.

SAAFKS00-012-R00

• Link profiles M2/640K and M4/640K were added, to improve read performance and range. See Configure Advanced Radio Settings.
• The IoT API returns valid error responses for invalid commands.
• Support for the long-range RFD40-M.

SAAFKS00-011-R01 and SAAFKS00-011-R00

• Fixed: data endpoints could not be created through the IoT API.
• Fixed: post-filters for data endpoints during access-mode operation.
• DataWedge mode for the scanner over eConnex (CIO).

SAAFKS00-010-R00

• EU 18031-1 (RED) compliance, which introduces authorization enforcement for firmware updates and for loading saved offline configurations.
• IOTC fixes for alerts, endpoint configuration and the IOTC data channel.

SAAFKS00-009-R00

• When using IoT Connector with the communication cradle, Zebra's release notes recommend firmware 009-R00 or later.

SAAFKS00-008-R00

The release that gave the IoT Connector most of its network surface:

• Multiple Wi-Fi profiles, delete_wifi_profile, and marking a profile preferred.
• The generic MDM endpoint type.
• The IOTC API version became V1.2 in the connect, disconnect and Last Will messages.
• Notifications when an endpoint connects or disconnects — what mqttConnEVT carries.
• Offline configuration for Wi-Fi, endpoints and IoT Connector settings.
• Wi-Fi channel selection between 2.4 GHz and 5 GHz.

SAAFKS00-007-R00 and earlier

• 007-R00 added Wi-Fi on the reader for device management and monitoring: WPA/WPA2/WPA3 Personal, WPA/WPA2 Enterprise, and WPA3 Enterprise with GCMP 256.
• 006-R01 raised the pre-filter ceiling to 32, which is the limit the contract still declares.

What Changed in the Contract

Since version 1.22.0, the contract's version is the IoT Connector API version that it describes. Before that, the contract numbered its own revisions, from 1.23.0 to 1.26.0, so the number went down while the contract moved on. What each version means for a client:

1.22.0

The contract was regenerated from the IoT Connector API definition and now carries the API's version. Unlike the revisions before it, this version narrows what the contract accepts, so check your requests and your validation against it.

Changes that can break a client:

• config_endpoint requires seven configuration fields for every operation: endpointName, epType, protocol, activate, url, verificationType and port.
• Every reply's response object requires code, beside description.
• verificationType has four values: VERIFY_NONE, VERIFY_PEER, VERIFY_HOST and VERIFY_HOST_AND_PEER. The aliases NONE and VERIFY_HOST_PEER are gone.
• powerSource has three values: WALLCHARGER, USB and CRADLE. BATTERY, WALL_CHARGER and NONE are gone.
• The alerts id TEMPERATURE is gone.
• The heartbeat interval is at most 65,535 seconds, down from 604,799, and has no minimum.
• mqttConnEVT requires deviceModel, deviceSerialNo, apiVersion and mqttVersion, beside connectionState.

Relaxed:

• tenantId and endpointName carry no length limit in the schema. The limits the reader applies are on Limits.
• set_operating_mode no longer requires operatingMode, and set_post_filter no longer requires postFilterPayload.

Documented:

• DATA2 is currently not supported.
• Tag data travels at the QoS set on its topic, 0 or 1, and config_endpoint with activate: true connects the endpoint without a reboot.
• The DATA1 examples use two publish topics, and a new example deletes a post-filter.

The revisions below carry the contract's own earlier numbering.

1.26.0

• Documentation only. The command surface is 20 commands; the names set_eth, cloud_connect and config_alerts are not part of the contract.

1.25.0

• 0 in batching.reportingInterval or batching.maxPayloadSizePerReport clamps to the member's minimum (1000 ms, 256 bytes). It does not disable batching.
• Descriptions that called shipped examples unusable, or contradicted their own keywords, were corrected. No keyword validates differently.

1.24.0

• mqttParams.publishTopics is documented as a fixed-position slot array: the reader routes by position, not by topic text. See Endpoints and Topic Slots.
• securityType accepts OWEPublic and WPA2personal on a Wi-Fi read-back. If you switch on securityType, add cases for both.

1.23.0

• Ten members on messages the reader emits, and EPCid on a tag record, are no longer required. Firmware states that each is always sent; check for them in your own code. Request-side requirements are unchanged.
• powerSource accepts NONE.
• apiVersion and mqttVersion on mqttConnEVT accept a number or a string.
• The guarantee that the reader suppresses a repeated requestId is withdrawn: the reader executes every copy it receives. See Duplicates and Retries.
• The 40-record limit on a dataEVT batch is retired; the limit is 6144 bytes for the whole message.
• qos and retain are optional on a topic binding; the reader supplies QoS 0 and RETAIN false.
• New bounds: tenantId at most 48 characters, endpoint names at most 16, and the heartbeat interval 60 to 604799 seconds.
• Each command documents the response codes it can return.

Changes before 1.23.0 are not recorded in the available sources.

Before You Upgrade a Fleet

Read Roll Out Changes in Stages first. A firmware move across a fleet is a staged operation, not a single command, and the planning page covers the ordering, the verification step, and the rollback position.

Authoritative Sources

The firmware record above is read from Zebra's own documents, which remain authoritative for anything this page summarizes:

• RFD40/RFD90 Software Release Notes for the release you are running — SAAFKS00-013-R05, released 15 July 2026, is the one this page is written against.
• RFD40/RFD90 change log, which lists the per-issue detail behind each release.
• Zebra Support and Downloads — firmware, release notes, and the download for your model.
• Zebra Developer Portal — developer-facing announcements.

Related: 📕 Reserved and Deprecated Fields · ⚖️ Versioning and Compatibility · 🛟 Get Help · 📕 Glossary