REST is HTTP based interface providing the following methods: GET, CREATE, UPDATE, DELETE. All methods along with the responses are encapsulated in JSON format and transferred as HTTP requests. With each request, a response is given from the server. The communication is based on request-response architecture, which means that the user needs to frequently request position updates to receive the positioning data.

Data Entities Terminology

Data entities within RTLS Software are divided into three basic groups:

  • Feed – it is the most general data representation of physical objects or devices such as Tag, buildings, Zone Definition, etc.
  • Datastream – it is a representation of physical phenomena such as position, battery level, orientation, etc.
  • DataPoint – it is a representation of discrete measurement of datastream equipped with timestamp

There are other entities derived from basic Feed such as:

  • Anchor - represents the physical anchor device and its data
  • Tag - represents the physical tag device and its data
  • Building - represents physical building and its data

When to use REST Interface?

REST Interface is mainly useful for applications with refresh intervals in seconds or to read static data from the database, like information about Tags, Anchors, Buildings, Zones, etc. It can also be used to read historic position data. REST interface should not be used to read fast real-time position data. The user authentication is done by the use of an API Key. Since the RTLS Studio provides multi-user access, the rights to data entities and requests themselves must be sent with an authentication key in HTTP headers. You can manage your API key in User Management.


Interactive API is available at the online Sewio DEMO - REST API. 

or your RTLS Studio native installation has available the same interactive REST documentation at the following path: YOUR_RTLSSTUDIO_IP_ADDRESS/documentation/api-rest

Storing Data to Database

In order to prevent server overloading with frequent DB position writes. The positions are stored in a queue and written in DB in batches of app. 200 positions or after one minute of inactivity for a tag.

This means that in the case of 1 second RI you can have in DB position which is 3 minutes older than the last successfully calculated position.