Environment: Teltonika RMS API, tested 2026-08-30. Authentication via an OAuth access token.
Create behaviour below was tested against https://api.rms.teltonika-networks.com. The list and filter behaviour in section 2 was verified identical on that host and on https://rms.teltonika-networks.com/api.
Context: building a Terraform provider, so the client has to record the identity of every object it creates in order to manage it later.
1. Create endpoints return no identifier
POST /companies and POST /tags both create the object and return a body with no identifier.
Request:
POST /companies
Content-Type: application/json
Accept: application/json
{"name": "Example Company", "parent_id": <PARENT_COMPANY_ID>}
Response:
HTTP/2 201
content-type: application/json
{"success":true}
There is no id and no data object in the body, and no Location header in the response. A subsequent GET /companies confirms the company was created and has an id.
POST /tags behaves the same way, so this is not specific to one endpoint:
POST /tags
{"company_id": <COMPANY_ID>, "name": "example-tag", "color": "#cccccc"}
HTTP/2 201
content-type: application/json
{"success":true}
The API overview defines 201 as “The request has been fulfilled and resulted in a new resource being created”, which does not state whether the body carries the resource. So this may be intended.
Impact: a client cannot learn the id of what it just created. For an infrastructure-as-code tool the object is created but cannot be recorded, so it is left behind unmanaged on every run.
Questions:
- Is there a supported way to obtain the id of a newly created object?
- Responses to
DELETEcarry ameta.channelvalue. Is that channel intended to convey the result of an operation, and does it apply to creates? - Would returning the created object in
data, or aLocationheader, be possible?
2. Unsupported query filters are silently ignored rather than rejected
The API overview states that “Some endpoints support a way of filtering the dataset”, with the documented form being field and value as query parameters (?status=online&tag=station,office). It does not list which endpoints support it.
On /companies, filtering by id works. Filtering by any other field returns the full collection rather than an empty result or an error.
Reproduction, in an account where the total number of companies is known:
| Query | Returned | Expected |
|---|---|---|
?id= an id that exists |
that one company | that one company |
?id= an id that does not exist |
0 rows | 0 rows |
?name= a name matching nothing |
the full collection | 0 rows |
?company_id= an id that does not exist |
the full collection | 0 rows |
Verified in an account containing exactly one company, on both hosts listed above.
If /companies is simply not one of the endpoints that supports filtering, that is a reasonable answer. The issue is the failure mode: an unsupported filter returns a full result set that is indistinguishable from a successful match, so a caller filtering by name silently operates on the wrong records. Rejecting the unknown parameter with a 400 would surface the mistake immediately.
Combined with section 1, there is no reliable way to locate an object that was just created: the id is not returned, and it cannot be looked up by name.
Questions:
- Which fields are filterable, on which endpoints?
- Would rejecting an unrecognised filter parameter with 400 be feasible, rather than dropping it?
3. Questions about endpoints and methods
These may be our own incorrect assumptions rather than defects. We could not find these paths in the API Reference, so we are asking rather than reporting.
| Request | Response |
|---|---|
POST /tasks |
404 RESOURCE_NOT_FOUND |
POST /task-groups |
404 RESOURCE_NOT_FOUND |
POST /users |
405 BAD_REQUEST_METHOD |
POST /alerts-configurations |
405 BAD_REQUEST_METHOD |
- What are the supported endpoints and methods for creating tasks, task groups, and alert configurations?
- For users,
POST /users/inviteexists and validates its input: an empty body returns 422 namingrole,company_idandemailas required. We have not completed an invitation end to end. Is invitation the intended path, and is direct user creation deliberately unavailable? GET /permissionsreturns 404, whileGET /roles/{id}/permissionsreturns the permission list for a role, withid,name,title,descriptionandcategoryper entry. Is per-role the intended access path, or is there a global permission catalogue endpoint?
Note on documentation
The API Reference at API Reference | Developers renders its content client side. A plain HTTP fetch of that page returns about 45 words, the navigation shell only, with no endpoint list; the same fetch of Teltonika RMS API | Developers returns roughly 1650 words of actual content. So the endpoint reference is not reachable without a browser and is not indexable by search engines, which is why the questions above were answered by probing rather than by reading. If an OpenAPI or Swagger document is available, that would answer most of them directly.