Teltonika RMS

Technical Preview

Overview

One client-mode connector, TeltonikaRMS, for the Teltonika RMS API. RMS (Remote Management System) is Teltonika’s cloud service for managing fleets of its industrial routers, gateways and modems, the boxes that often connect a plant cell, a substation or a remote pump station to the network. Use the connector to bring fleet health into your Unified Namespace: list every gateway and its online state, signal and temperature, pull monitoring graphs and Data Collect values, track location and mobile data usage, and raise alerts. It can also act on the fleet: refresh metrics, reboot a device, run a CLI command, push configuration, queue a firmware update, run a saved task group and organise devices with tags.

Event	Request	Notes
GetApiInfo	`GET /api/`	No auth; build and server time, a reachability check
ListDevices	`GET /devices?{query}`	Filters such as `status=online`, `model`, `tag_id`, `limit`, `fields`
GetDevice	`GET /devices/{device_id}`	Full device record: model, serial, firmware, signal, temperature, WAN state
UpdateDevice	`PUT /devices/{device_id}`	Name, description, monitoring intervals, user-set coordinates, tags
SetDevicesMonitoring	`PUT /devices/monitoring`	Turn monitoring on (`1`) or off (`0`) for many devices
GetDeviceStatistics	`GET /devices/statistics?{query}`	Counts per chart; `charts` is required (`status`, `model`, `signal`…)
GetOnlineDeviceStatistics	`GET /statistics/devices/online?{query}`	`start_date`, `end_date`, `company_id` required
GetDeviceGraphData	`GET /devices/{device_id}/information/{type}?{query}`	`type` is `dynamic`, `io` or `gps`; `start_date` / `end_date` required
GetDeviceCustomData	`GET /devices/{device_id}/custom-data?{query}`	Values gathered by Data Collect templates; dates required
GetDeviceLocation	`GET /devices/{device_id}/locations`	Last known position
GetDeviceLocationHistory	`GET /devices/{device_id}/locations/history?{query}`	Dates required
GetDeviceDataUsage	`GET /devices/{device_id}/data-usage?{query}`	Mobile data used; dates required
GetDeviceLogs	`GET /devices/{device_id}/logs?{query}`	`limit`, `offset`
ExecuteDeviceAction	`POST /devices/actions`	`reboot`, `update_metrics_data`, `download_backup`, `download_eventslog`, `download_troubleshoot`; returns a status channel
CancelDeviceAction	`POST /devices/actions/cancel`	By `device_id` and `job_id` lists
GetDeviceActionLogs	`GET /devices/actions/logs?{query}`	`device_id` and `tag_id` required
ExecuteDeviceCommand	`POST /devices/{device_id}/command`	Runs a shell command on the device; returns a status channel
GetActionStatus	`GET /status/channel/{channel}`	Polls the Status API; `404 CHANNEL_NOT_FOUND` once it expires
GetConfigSpecification	`GET /devices/configurator/specification?{query}`	Which settings RMS can configure on this device; `device_id` required
GetConfigValues	`POST /devices/configurator/configuration`	Read current values for configuration paths
SendConfiguration	`POST /devices/configurator/configure`	Push configuration to one or many devices
ListPendingUpdates	`GET /devices/updates/pending?{query}`	Queued firmware and backup jobs
SetUpdates	`POST /devices/updates/set`	Queue `update_firmware` or `upload_backup` with an RMS file id
ListTaskGroups	`GET /devices/tasks/groups?{query}`
ExecuteTaskGroup	`POST /devices/tasks/groups/{task_group_id}`	Run saved CLI tasks on a device list
ListAlerts	`GET /alerts?{query}`	Filter by `device_id`, `type`, `company_id`
GetAlert	`GET /alerts/{alert_id}`
DeleteAlert	`DELETE /alerts/{alert_id}`
ListTags	`GET /tags?{query}`
CreateTag	`POST /tags`	Returns `201`
DeleteTag	`DELETE /tags/{tag_id}`
AssignDeviceTags	`PUT /devices/tags/assign`
UnassignDeviceTags	`PUT /devices/tags/unassign`

Topics are cloud-iot/teltonika-rms/<object>/<verb>; every reply goes to <topic>/response. Paths in the table are relative to /api, except GetApiInfo (/api/) and GetActionStatus (/status/channel/{channel}).

Authentication

Every authenticated event sends Authorization: {authorization}, so pass the whole header value: "Bearer <token>".

A Personal Access Token is the simple choice for one RMS account. Create it in RMS under account settings, Applications (RMS asks you to turn on two-factor authentication first) and tick only the scopes the connector needs, for example devices:read, device_actions:write, device_configurations:write, device_alerts:read and tags:write.
An OAuth 2.0 access token is for apps that act on behalf of many RMS users.

Keep it in a broker secret (suggested TELTONIKA_RMS_AUTHORIZATION) and map it in with GET SECRET. A missing, expired or wrong token returns 401 with {"success": false, "errors": [{"code": "UNAUTHORIZED"}]}; some endpoints return 403 when the token or user is not allowed to do that.

Basic Syntax

RMS is hosted by Teltonika, so BASE_ADDRESS is always https://rms.teltonika-networks.com.

DEFINE ROUTE TeltonikaRMS WITH TYPE REST_API
    ADD REST_API_CONFIG
        WITH BASE_ADDRESS "https://rms.teltonika-networks.com"
        WITH ENABLE_CLIENT "true"
        WITH USE_SSL "true"
        WITH REQUEST_TIMEOUT '30'
        WITH DEFAULT_CONTENT_TYPE "application/json"
    ADD EVENT ListDevices
        WITH SOURCE_TOPIC "cloud-iot/teltonika-rms/device/list"
        WITH DESTINATION_TOPIC "cloud-iot/teltonika-rms/device/list/response"
        WITH METHOD "GET"
        WITH ENDPOINT "/api/devices?{value.json.query}"
        WITH HEADERS
            ADD "Accept" "application/json"
            ADD "Authorization" "{value.json.authorization}"
    ADD EVENT ExecuteDeviceAction
        WITH SOURCE_TOPIC "cloud-iot/teltonika-rms/device-action/execute"
        WITH DESTINATION_TOPIC "cloud-iot/teltonika-rms/device-action/execute/response"
        WITH METHOD "POST"
        WITH ENDPOINT "/api/devices/actions"
        WITH HEADERS
            ADD "Accept" "application/json"
            ADD "Content-Type" "application/json"
            ADD "Authorization" "{value.json.authorization}"
        WITH BODY "{value.json.body}"
    ADD EVENT GetActionStatus
        WITH SOURCE_TOPIC "cloud-iot/teltonika-rms/action-status/get"
        WITH DESTINATION_TOPIC "cloud-iot/teltonika-rms/action-status/get/response"
        WITH METHOD "GET"
        WITH ENDPOINT "/status/channel/{value.json.channel}"
        WITH HEADERS
            ADD "Accept" "application/json"
            ADD "Authorization" "{value.json.authorization}"

The full template, with all 33 events, is TeltonikaRmsRestApi.lot in the REST API app.

MQTT examples

Request bodies go under body, so control fields like authorization, device_id and query are not sent to RMS. device_id is the numeric RMS id from ListDevices, not the serial number or IMEI. List online gateways: publish to cloud-iot/teltonika-rms/device/list:

{
  "authorization": "Bearer <RMS token>",
  "query": "status=online&limit=100&fields=id,name,serial,model,status,signal,temperature"
}

Send "query": "" when you do not need filters. Read the last 6 hours of monitoring data: publish to cloud-iot/teltonika-rms/device-graph/get. type is dynamic (signal, temperature, traffic), io or gps, and the dates must be URL-encoded:

{
  "authorization": "Bearer <RMS token>",
  "device_id": 46920,
  "type": "dynamic",
  "query": "start_date=2026-10-05%2000%3A00%3A00&end_date=2026-10-05%2006%3A00%3A00"
}

Refresh or reboot a device: publish to cloud-iot/teltonika-rms/device-action/execute:

{
  "authorization": "Bearer <RMS token>",
  "body": {"action": "update_metrics_data", "device_id": [46920]}
}

RMS answers straight away with {"success": true, "meta": {"channel": "private-status.1...."}}. Publish that channel to cloud-iot/teltonika-rms/action-status/get as {"authorization": "...", "channel": "<channel>"} and repeat until each device’s last entry has "status": "completed". Use "action": "reboot" to restart the device. Run a command on a gateway: publish {"authorization": "...", "device_id": 46920, "body": {"command": "gsmctl -q"}} to cloud-iot/teltonika-rms/device-command/execute and poll the returned channel the same way. Tag a device: create a tag on cloud-iot/teltonika-rms/tag/create with "body": {"name": "porto-line-1", "company_id": 125, "color": "#4287f5"}, then assign it on cloud-iot/teltonika-rms/device-tags/assign:

{
  "authorization": "Bearer <RMS token>",
  "body": {"data": [{"device_id": 46920, "tag_id": [7841]}]}
}

Helper actions

Keep the token in a broker secret, poll fleet status every few minutes, and refresh metrics on demand:

DEFINE ACTION TeltonikaRmsPollFleet
ON EVERY 5 MINUTES DO
    SET "auth" WITH GET SECRET "TELTONIKA_RMS_AUTHORIZATION"
    PUBLISH TOPIC "cloud-iot/teltonika-rms/device/list" WITH { "authorization": {auth}, "query": "limit=100&fields=id,name,serial,model,status,signal,temperature" }

DEFINE ACTION TeltonikaRmsRefreshDevice
ON TOPIC "porto/network/+/refresh" DO
    SET "auth" WITH GET SECRET "TELTONIKA_RMS_AUTHORIZATION"
    SET "device" WITH GET JSON "rms_device_id" IN PAYLOAD AS INT
    PUBLISH TOPIC "cloud-iot/teltonika-rms/device-action/execute" WITH { "authorization": {auth}, "body": { "action": "update_metrics_data", "device_id": [{device}] } }

Restrict who can publish to cloud-iot/teltonika-rms/# with a rule: its payloads carry the token, and events such as ExecuteDeviceAction, ExecuteDeviceCommand, SendConfiguration and SetUpdates can reboot, reconfigure or reflash devices in the field.

Notes

Errors come back on the response topic: 401 for a missing, expired or wrong token (or a resource that belongs to another company), 403 when the token or user is not allowed, 404 for an unknown device, alert, tag or channel, 422 for validation errors such as a missing start_date (the OpenAPI spec does not document rate limits, so keep polling coarse).
Long-running actions (reboot, backups, firmware, commands, configuration) return a status channel instead of the result. RMS also streams these statuses over Socket.IO; this template uses the HTTP polling endpoint only.
GetDeviceStatistics needs charts, and the graph, Data Collect, location history, data usage and online statistics events need start_date and end_date; RMS rejects the call with 422 otherwise.
API calls act on the same devices, companies and credits as the RMS web interface, so a token sees exactly what its user sees.
To talk to a single router on the local network instead of through RMS, use the device’s own RUTOS API; this template covers the RMS cloud API only.

Quick Start

Coreflux MQTT Broker

LoT Language

Coreflux HUB

VS Code - LoT Notebooks

Coreflux Portal

Using AI with Coreflux

Product Updates

Overview

Authentication

Basic Syntax

MQTT examples

Helper actions

Notes

​Overview

​Authentication

​Basic Syntax

​MQTT examples

​Helper actions

​Notes

​Related

Overview

Authentication

Basic Syntax

MQTT examples

Helper actions

Notes

Related