Skip to main content

get_endpoint_config

ReferenceAudience: API consumerUse: read back the reader's MQTT endpoint configuration and saved endpoint names

Overview​

get_endpoint_config reads back the reader's MQTT endpoint configuration — a faithful view of what was provisioned with config_endpoint. It has two modes, chosen by whether you send endpointDetails.endpointName:

  • All-endpoints (omit endpointDetails): returns every active endpoint's full configuration under endpointResponse.activeEndpoints.epConfig[], plus the names of all saved endpoints under endpointResponse.savedEndpoints.epNames[].
  • Single-endpoint (send endpointDetails.endpointName): returns just that one endpoint's configuration.

It is a read-only command on the device-management (MGMT) endpoint.

The response includes broker credentials (mqttParams.password, and username where set) — treat it as sensitive. See the warning in Notes and Caveats. The examples on this page are the contract's, and carry placeholders rather than real credentials.

Details​

PropertyValue
Interaction PatternRequest / Response (app publishes a command; device publishes the correlated reply)
State ChangeREAD-ONLY
Required Request Fieldscommand, requestId (plus optional endpointDetails.endpointName)
Applies ToEndpoint: Management (MGMT). Reader: RFD40 series, RFD90 series
API VersionV1.1 (API Version Reporting)
Relatedconfig_endpoint, get_wifi, get_eth, config_events

When to Use​

Use get_endpoint_config to inspect or audit the reader's MQTT wiring:

  • Before config_endpoint — review the current configuration so you do not overwrite an active endpoint unexpectedly.
  • Confirm the plumbing — check url / port, protocol, verificationType, and the publishTopics / subscribeTopics a broker will see.
  • List saved endpoints — read savedEndpoints.epNames[] to see everything saved on the device (a superset of the active endpoints) before activating or deleting one.
  • Audit routing & security — review each endpoint's eventConfiguration and securityParams.

Topic Mapping​

MessageDirectionTopicNote
RequestApp → Reader<tenantId>/MGMT/clients/cmnd/<serial>On the management endpoint.
ResponseReader → App<tenantId>/MGMT/clients/resp/<serial>Correlated reply to the request above; the in-payload requestId links the twin topics.

Topics follow the pattern <tenantId>/<topic>/<serial> — the tenant id assigned to you at provisioning (a slot you fill in, never a literal), the base topic you configure on the endpoint, and the reader's serial number, which the reader appends itself in its model-prefixed form (for example RFD40-212735201D0053). App → Reader means your app publishes and the reader subscribes; Reader → App means the reader publishes and your app subscribes.

The publishTopics / subscribeTopics inside the response are base topics (e.g. MDM/clients/cmnd); on-wire they are wrapped to <tenantId>/<topic>/<serial>.

Credentials are presented once at CONNECT. The requestId you send is echoed in the response so you can pair reply to request. The endpoint's mqttParams govern QoS and retain, not this command.

See Topics and Channels.

Key Fields​

  • endpointDetails.endpointName (request) — omit for all endpoints; supply to target one (case-sensitive).
  • activeEndpoints.epConfig[] (response) — the full config of each active endpoint. Inactive (saved-but-not-activated) endpoints do not appear here. An endpoint appears here as soon as it is stored as active, which does not show that it connected: wait for a CONNECTED mqttConnEVT on the endpoint’s connection-state topic. See Saving an endpoint does not connect it.
  • savedEndpoints.epNames[] (response) — the names of all saved endpoints (active and inactive) — the active/saved distinction in one field.
  • configuration.mqttParams.password (response) — ⚠️ a broker credential is present in the response; see Response Payload and the credential warning below.
  • response.code (response) — read this to determine success vs failure (see Response Codes).

Request Payload​

To read all endpoints, send just command and requestId. Use the Schema tab for the full field reference and the Example tab for the all-endpoints request.

Request payload
Example: all endpoints
{
"command": "get_endpoint_config",
"requestId": "abc123"
}

Request Semantics​

  • Modes. All-endpoints (omit endpointDetails) returns every active endpoint plus all saved names; single-endpoint (endpointDetails.endpointName) returns just that one endpoint.

Response Payload​

On success the device returns the envelope (command, requestId, apiVersion, response) with the endpoint payload under endpointResponse — activeEndpoints.epConfig[] (full configs) and savedEndpoints.epNames[] (all saved names). The Example tab shows two active endpoints — an MDM endpoint and a DATA1 endpoint.

mqttParams.password and username in the example below are the broker credentials a read-back carries. The payload is taken verbatim from the contract, so it follows the contract's own placeholder policy rather than this page's: password reads xxxxxx, a placeholder, but username reads mqttuser — a value the contract ships unmasked. Treat both as placeholders, not as credentials to reuse.

Response payload
Example: all active endpoints
{
"command": "get_endpoint_config",
"requestId": "abc123",
"apiVersion": "V1.22",
"endpointResponse": {
"activeEndpoints": {
"epConfig": [
{
"configuration": {
"endpointName": "mdm_ep2",
"epType": "MDM",
"protocol": "MQTT",
"activate": true,
"url": "17L11-DS3362",
"verificationType": "VERIFY_NONE",
"port": 1883,
"qosCommon": 0,
"tenantId": "zebra",
"mqttParams": {
"keepAlive": 96,
"cleanSession": true,
"reconnectDelayMin": 5,
"reconnectDelayMax": 512,
"clientId": "",
"username": "mqttuser",
"password": "xxxxxx",
"publishTopics": [
{
"topic": "MDM/clients/resp",
"qos": 0,
"retain": false
},
{
"topic": "MDM/clients/event",
"qos": 0,
"retain": false
},
{
"topic": "MDM/clients/rfid",
"qos": 0,
"retain": true
}
],
"subscribeTopics": [
{
"topic": "MDM/clients/cmnd",
"qos": 0
}
]
},
"securityParams": {
"format": "PEM",
"caCertificateFile": "",
"clientCert": "",
"clientKey": ""
},
"eventConfiguration": {
"antenna": false,
"terminalConnection": false,
"firmwareUpdate": true,
"gpi": false,
"network": true,
"exceptions": false,
"ntp": true,
"userApp": false,
"heartbeat": false,
"power": true,
"battery": true,
"temperature": false,
"fileDownload": true,
"cpuUsage": false,
"flashUsage": false,
"ramUsage": false,
"cpuThreshold": 0,
"ramThreshold": 0,
"flashThreshold": 0,
"temperatureThreshold": 0
}
}
},
{
"configuration": {
"endpointName": "data1_ep",
"epType": "DATA1",
"protocol": "MQTT",
"activate": true,
"url": "17L11-DS3362",
"verificationType": "VERIFY_NONE",
"port": 1883,
"qosCommon": 0,
"tenantId": "zebra",
"mqttParams": {
"keepAlive": 96,
"cleanSession": true,
"reconnectDelayMin": 5,
"reconnectDelayMax": 512,
"clientId": "",
"username": "mqttuser",
"password": "xxxxxx",
"publishTopics": [
{
"topic": "DATA/clients/unused",
"qos": 0,
"retain": false
},
{
"topic": "DATA/clients/data1event",
"qos": 1,
"retain": false
}
],
"subscribeTopics": []
},
"securityParams": {
"format": "PEM",
"caCertificateFile": "",
"clientCert": "",
"clientKey": ""
},
"eventConfiguration": {
"antenna": false,
"terminalConnection": false,
"firmwareUpdate": true,
"gpi": false,
"network": true,
"exceptions": false,
"ntp": true,
"userApp": false,
"heartbeat": false,
"power": true,
"battery": true,
"temperature": false,
"fileDownload": true,
"cpuUsage": false,
"flashUsage": false,
"ramUsage": false,
"cpuThreshold": 0,
"ramThreshold": 0,
"flashThreshold": 0,
"temperatureThreshold": 0
},
"batching": {
"reportingInterval": 1000,
"maxPayloadSizePerReport": 1024
}
}
}
]
},
"savedEndpoints": {
"epNames": [
"mdm_ep",
"mdm_ep2",
"ctrl_ep",
"data1_ep",
"mgmt_ep"
]
}
},
"response": {
"code": 0,
"description": "Success"
}
}

Response Semantics​

Field Support. Each endpoint's configuration.eventConfiguration selects which events that endpoint emits. The contract declares the full set below, but only 7 of the boolean toggles are supported today; the remaining 13 keys are accepted by the firmware and returned in the read-back but have no effect yet (reserved for a future release). Enabling a reserved toggle silently does nothing.

FieldTypeStatusDescription
terminalConnectionboolean✅ SupportedTerminal connect/disconnect events.
firmwareUpdateboolean✅ SupportedFirmware-update events.
networkboolean✅ SupportedNetwork events.
heartbeatboolean✅ SupportedPeriodic heartbeat events.
powerboolean✅ SupportedPower-source events.
batteryboolean✅ SupportedBattery events.
temperatureboolean🔒 ReservedDeclared in the schema, but no temperature alert is emitted on V1.1 — the toggle is stored and read back, and does nothing.
fileDownloadboolean✅ SupportedFile-download events.
antennaboolean🔒 ReservedNot yet functional.
gpiboolean🔒 ReservedNot yet functional.
exceptionsboolean🔒 ReservedNot yet functional.
ntpboolean🔒 ReservedNot yet functional.
userAppboolean🔒 ReservedNot yet functional.
cpuUsageboolean🔒 ReservedNot yet functional.
flashUsageboolean🔒 ReservedNot yet functional.
ramUsageboolean🔒 ReservedNot yet functional.
cpuThresholdinteger🔒 ReservedNot yet functional (paired with cpuUsage).
ramThresholdinteger🔒 ReservedNot yet functional (paired with ramUsage).
flashThresholdinteger🔒 ReservedNot yet functional (paired with flashUsage).
temperatureThresholdinteger🔒 ReservedNot yet functional.
heartbeatConfigurationobject⚙️ Conditional{ interval, inventoryStatus, batteryStatus, userApps }. Returned only after config_events enables the heartbeat (not by default). userApps is not currently functional.

The 7 supported booleans are exactly the ones you can rely on today; configure event routing with config_events.

  • Active vs saved. activeEndpoints.epConfig[] contains a full configuration only for endpoints with activate: true. savedEndpoints.epNames[] lists every saved endpoint — so a name that appears in epNames but not in epConfig[] is saved but inactive.
  • verificationType reads back as you sent it. The reader returns the value you set with config_endpoint, such as VERIFY_HOST_AND_PEER; a plain-MQTT endpoint reads back VERIFY_NONE. Because one enum governs both directions, you can echo a read-back value in a later update.
  • Topic items and the protocol literal. Each publishTopics / subscribeTopics entry carries topic, qos, and retain. The contract requires qos and retain on a publish item, and topic, qos and retain on a subscribe item — but its own read-back examples omit retain on every subscribe item, and an MQTT subscription has no retain flag, so do not reject a subscribe entry that lacks it. The TLS protocol literal does not differ by direction: you send MQTT_TLS with config_endpoint and read the same MQTT_TLS back here, so a validator can hold one enum — MQTT or MQTT_TLS — for both directions.
  • Topic slots read back in configured order. publishTopics entries are returned in the order they were set with config_endpoint: [0] = command responses (…/clients/resp), [1] = events (…/clients/event), [2] = the endpoint's connection-event and Last Will topic (…/clients/rfid), with subscribeTopics[0] = command ingress (…/clients/cmnd). A DATA1 endpoint configured with a placeholder at [0] reads the tag-data topic back at [1], as the contract's DATA1 read-back shows. A read-back with a single entry is read from index 0 upward, so that entry sits in the reply slot and no tag data is flowing. Match entries by index, not base name — the resp / event / rfid names are conventions.

Response Codes​

get_endpoint_config returns response.code. The codes applicable to this command are below; for the full table see the Response Codes and Correlation and Request/Response Pairing.

CodeDescription
0Success — the endpoint configuration was retrieved.
3Not able to retrieve information (IOT_ERROR_INFO_NOT_AVAILABLE) — the device could not gather the configuration at this time. Retry after a short delay; if persistent, reboot.
101Default error — generic catch-all.

Examples​

Publish get_endpoint_config; the device replies with the envelope shown under Response Payload. The all-endpoints request (command + requestId) returns every active endpoint plus the saved-names list; the single-endpoint request (shown under Request Payload) targets one endpoint by name.

Active vs saved. In the response example, activeEndpoints.epConfig[] carries the full config of the two active endpoints (mdm_ep2 and data1_ep), while savedEndpoints.epNames lists all five saved (mdm_ep, mdm_ep2, ctrl_ep, data1_ep, mgmt_ep) — the three that are saved but not active appear only as names, with no config block. When more than one endpoint is active, epConfig[] holds one full configuration per active endpoint.

Notes and Caveats​

The response returns broker credentials

configuration.mqttParams.password (and username, when set) are part of the read-back. Redact them in logs, tickets, and screenshots; transport and store the response only over secured channels. The examples on this page carry placeholders, not real credentials.

Read get_endpoint_config before config_endpoint to review the current wiring and avoid clobbering an active endpoint. For the concept-level view, see Endpoints and Topic Slots.

Related: 📕 Endpoints and Topic Slots · 📕 config_endpoint · 📕 config_events · 📕 get_wifi · 📕 Response Codes

Was this helpful?