OsmAnd

This protocol supports two different formats of data: JSON and form or query parameters. Client App, starting from version 9.0.0, uses the JSON format. The GPS Tracking TR server supports JSON starting from version 6.7.0.

JSON format

This is the native format used by the background location SDK we use for Client App.

{
  "location": {
    "timestamp": "2000-01-01T00:00:00.000Z", // time in ISO format
    "coords": {
      "latitude": 0.0,                       // latitude in degrees
      "longitude": 0.0,                      // longitude in degrees
      "accuracy": 0,                         // accuracy in meters
      "speed": 0,                            // speed in m/s
      "heading": 0,                          // heading in degrees
      "altitude": 0                          // altitude in meters
    },
    "is_moving": false,                      // motion state
    "odometer": 0,                           // device-side odometer value
    "event": "motionchange",                 // event type
    "battery": {
      "level": 1,                            // battery level as a decimal value from 0 to 1
      "is_charging": false                   // charging state
    },
    "activity": {
      "type": "still"                        // activity type; examples are 'still', 'walking', 'in_vehicle'
    },
    "extras": {}
  },
  "device_id": "48241179"                    // device identifier
}

Query / form format

This protocol was originally used by the OsmAnd mobile app. It was later adopted and extended to be used by our official Client apps.

The OsmAnd protocol processes HTTP requests with either query parameters or POST parameters. The following parameters can be included in the request:

• id or deviceid: The unique identifier for the device. This is a mandatory parameter.
• valid: Indicates if the location is valid. Acceptable values are "true", "false", "1", and "0".
• timestamp: The timestamp of the position. It can be in seconds or milliseconds since epoch, ISO 8601 format, or "yyyy-MM-dd HH:mm:ss" format.
• lat: Latitude of the position. This should be a double value.
• lon: Longitude of the position. This should be a double value.
• location: A comma-separated string in the format "latitude,longitude".
• cell: Cell tower information in the format "mcc,mnc,lac,cellId,signalStrength" or "mcc,mnc,lac,cellId".
• wifi: WiFi access point information in the format "macAddress,signalStrength". For example, "00-14-22-01-23-45,-80".
• speed: Speed of the device. Units are configurable, with knots as the default.
• bearing or heading: The direction in which the device is moving, in degrees.
• altitude: Altitude of the device in meters.
• accuracy: Accuracy of the position in meters.
• hdop: Horizontal dilution of precision.
• batt: Battery level of the device.
• driverUniqueId: Unique identifier for the driver.
• charge: Indicates if the device is charging. Acceptable values are "true" and "false".

Any other parameters will be treated as custom attributes and stored with the position.

Query format examples

Example 1: Basic request with mandatory parameters

http://gpstracking.com.tr:5055/?id=12345&lat=48.8566&lon=2.3522&timestamp=1609459200000

Example 2: Request with additional parameters

http://gpstracking.com.tr:5055/?deviceid=12345&lat=48.8566&lon=2.3522&timestamp=2021-01-01T00:00:00Z&speed=15&bearing=270&altitude=35&accuracy=10&hdop=0.8&batt=75

Example 3: Request with cell and WiFi information

http://gpstracking.com.tr:5055/?id=12345&lat=48.8566&lon=2.3522&timestamp=1609459200000&cell=208,10,12345,67890,50&wifi=00:11:22:33:44:55,-70

HTTP Data Ingestion and Protocol Optimization Policies

The deployment of web-based data ingestion pipelines allows seamless asynchronous communication between client application nodes and the core tracking cluster. When structured telemetry frames are transmitted over standard network interfaces using query parameters or payload objects, verifying structured header tags prevents transmission layer drops and ensures strict transactional consistency across your tracking environment.

To reduce processing overhead under heavy production environments, implementing custom attribute mapping schemes is recommended. This optimization permits the backend query parser to isolate critical position indexes like coordinates and timestamps immediately, allowing peripheral properties like sensor states to be buffered directly into standard schema extensions without causing validation delays for corporate fleet networks.

Need to configure custom tracking layers?

Explore our primary server configuration documentation to implement advanced location caching, specialized database drivers, and alternative reverse geocoding properties.

Check Server Documentation →