API SUTRAN: formato de trama GPS, payload y errores comunes

En qué formato transmite SUTRAN

SUTRAN recibe las posiciones de cada vehículo de transporte de carga y pasajeros a través de dos APIs REST públicas. La trama viaja en JSON sobre HTTP con SSL, y cada trama se identifica con un token que corresponde a la Empresa de Monitoreo Vehicular (EMV) que transmite.

La trama tiene un header de autenticación (el access-token que identifica a la EMV) y un body con la posición: placa, geoposición como arreglo de latitud y longitud, rumbo, evento, velocidad en km/h y la fecha-hora del dispositivo en horario de Perú (UTC-5).

La estructura de la trama, campo por campo

El header lleva el access-token (string), que es el identificador de la EMV que transmite. El body lleva: plate (string, la placa del vehículo); geo (arreglo con [latitud, longitud]); direction (entero, el rumbo o sentido); event (string, con valores ER para en ruta, PA para parada y BP para botón de pánico); speed (entero, la velocidad en km/h); y time_device (fecha en formato yyyy-mm-dd hh24:mi:ss, en horario de Perú UTC-5).

El token NO va dentro del JSON: viaja como cabecera HTTP (access-token). El body es el objeto JSON con la posición. Un ejemplo de body tiene esta forma: plate como "HEN123", geo como [-11.410890, -76.9604001], direction 38, event "ER", speed 50 y time_device "2026-07-21 10:47:00". Cualquier desviación en el orden de los parámetros, el formato o el valor esperado hace que la trama se rechace.

Las dos APIs y sus límites

SUTRAN expone dos versiones del API, ambas JSON sobre HTTP con SSL. La API v1 admite paquetes de hasta 149 tramas por petición; si superas ese máximo rechaza el paquete completo y devuelve una confirmación por paquete con el detalle de las tramas que fallaron.

La API v2 admite de 1 a 5000 tramas por petición y devuelve una confirmación CRC por cada trama, con un código de error si alguna se rechaza. La infraestructura de recepción soporta picos de alrededor de 1000 conexiones por segundo.

• Crear e inactivar tokens desde la plataforma web de gestión
• Autorizar las IPs de tu servidor en el firewall de SUTRAN
• Validar que la placa esté en el padrón del MTC antes de transmitir
• Verificar el CRC que SUTRAN entrega por cada transmisión

Cadencia y equipo exigidos

Según la Directiva 001-2014-MTC/15 (aprobada por la RD 1811-2014-MTC/15), la transmisión debe ser permanente: una trama por minuto en modo celular y una cada cinco minutos en modo satelital, con equipo homologado por el MTC.

Por qué SUTRAN te rechaza la trama

Una trama se cataloga como incorrecta — y no se registra — por cualquiera de estas causas: token inválido o no autorizado; estructura que no respeta el orden de los parámetros, el formato o el valor esperado; formato distinto a JSON; hora adelantada respecto de la hora local de Perú; error en la placa (no está en el padrón MTC o formato inválido); o error en el campo geo.

Después de la fecha-hora, el problema más común es la velocidad: SUTRAN la espera en km/h, no en nudos. Los equipos Coban y varios chinos reportan en nudos y hay que convertir (multiplicar por 1.852) antes de transmitir.

La parte difícil no es el formato — es sostenerlo

El JSON de arriba lo arma cualquiera en una tarde. Lo que cuesta es lo que viene después: el uptime, porque SUTRAN exige transmisión permanente y si tu servidor se cae la multa le llega a tu cliente; convertir cada protocolo, porque Teltonika, GT06, Coban y Sinotrack hablan distinto y hay que parsearlos todos y normalizar a la trama SUTRAN; la gestión de tokens, IPs y padrón; y los reintentos con lectura del CRC cuando el API rechaza una trama.

DiTrack ya transmite a SUTRAN en producción desde 2012, sobre equipos de múltiples marcas. Si tienes una empresa GPS y no quieres construir ni mantener esta tubería, la operamos por ti por placa al mes: tú conservas tu cliente, tu marca y tu plataforma, y nosotros entregamos tu stream a SUTRAN, OSINERGMIN y la ATU.