SUTRAN API: GPS frame format, payload and common errors

What format SUTRAN transmits in

SUTRAN receives each cargo and passenger vehicle's positions through two public REST APIs. The frame travels as JSON over HTTP with SSL, and each frame is identified by a token that corresponds to the Vehicle Monitoring Company (EMV) transmitting it.

The frame has an authentication header (the access-token that identifies the EMV) and a body with the position: plate, geoposition as an array of latitude and longitude, heading, event, speed in km/h and the device date-time in Peru local time (UTC-5).

The frame structure, field by field

The header carries the access-token (string), the identifier of the transmitting EMV. The body carries: plate (string, the vehicle plate); geo (array of [latitude, longitude]); direction (integer, the heading); event (string, with values ER for en route, PA for stop and BP for panic button); speed (integer, km/h); and time_device (date in yyyy-mm-dd hh24:mi:ss format, in Peru local time UTC-5).

The token does NOT go inside the JSON: it travels as an HTTP header (access-token). The body is the JSON object with the position. A sample body looks like this: plate as "HEN123", geo as [-11.410890, -76.9604001], direction 38, event "ER", speed 50 and time_device "2026-07-21 10:47:00". Any deviation in parameter order, format or expected value causes the frame to be rejected.

The two APIs and their limits

SUTRAN exposes two API versions, both JSON over HTTP with SSL. API v1 accepts packets of up to 149 frames per request; if you exceed that maximum it rejects the whole packet and returns a per-packet confirmation detailing which frames failed.

API v2 accepts 1 to 5000 frames per request and returns a CRC confirmation per frame, with an error code if any is rejected. The receiving infrastructure supports peaks of around 1000 connections per second.

• Create and deactivate tokens from the web management platform
• Authorize your server's IPs on SUTRAN's firewall
• Validate that the plate is in the MTC registry before transmitting
• Verify the CRC SUTRAN returns for each transmission

Required cadence and equipment

Under Directive 001-2014-MTC/15 (approved by RD 1811-2014-MTC/15), transmission must be permanent: one frame per minute in cellular mode and one every five minutes in satellite mode, with equipment homologated by the MTC.

Why SUTRAN rejects your frame

A frame is catalogued as incorrect — and not registered — for any of these reasons: invalid or unauthorized token; a structure that does not respect the parameter order, format or expected value; a format other than JSON; a time ahead of Peru local time; a plate error (not in the MTC registry or invalid format); or an error in the geo field.

After the date-time, the most common problem is speed: SUTRAN expects it in km/h, not knots. Coban and several Chinese devices report in knots and you must convert (multiply by 1.852) before transmitting.

The hard part isn't the format — it's sustaining it

The JSON above anyone can assemble in an afternoon. What's costly is everything after: uptime, because SUTRAN requires permanent transmission and if your server goes down the fine lands on your client; converting each protocol, because Teltonika, GT06, Coban and Sinotrack all speak differently and you must parse them all and normalize to the SUTRAN frame; token, IP and registry management; and retries with CRC reading when the API rejects a frame.

DiTrack already transmits to SUTRAN in production since 2012, over multi-brand equipment. If you run a GPS company and don't want to build or maintain this pipeline, we operate it for you per plate per month: you keep your client, your brand and your platform, and we deliver your stream to SUTRAN, OSINERGMIN and the ATU.