> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreflux.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Teltonika RMS

> Client-mode REST API connector for Teltonika RMS: list and inspect routers and gateways, read monitoring graphs, Data Collect values, locations, data usage and logs, reboot or refresh devices, run commands, push configuration, queue firmware updates, run task groups, read alerts and manage tags

Technical Preview

## Overview

One client-mode connector, **TeltonikaRMS**, for the [Teltonika RMS API](https://developers.rms.teltonika-networks.com/). 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`.

```lot theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
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`:

```json theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
{
  "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:

```json theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
{
  "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`:

```json theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
{
  "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`:

```json theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
{
  "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:

```lot theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
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.

## Related

* [REST API Connectors](/latest/lot-language/routes/rest-api-routes)
* [REST API app templates](/latest/lot-language/routes/rest-api-apps/index)
* [balena](/latest/lot-language/routes/rest-api-apps/balena)
* [Mender](/latest/lot-language/routes/rest-api-apps/mender)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.