Usa nuestra app, o construye la tuya encima.
Los dispositivos hablan MQTT o HTTP. Tus sistemas hablan REST con claves acotadas, y cada ruta está en un documento OpenAPI. Los webhooks llegan con un cuerpo que puedes procesar.
Primeros pasos
- 01Añade un dispositivo
Su usuario y contraseña MQTT se muestran una sola vez.
- 02Añade una medida
De ese dispositivo; apunta su ID.
- 03Publica una lectura
Aparece en la página del dispositivo y en cada panel abierto.
Una credencial, dos tópicos
Un dispositivo publica lecturas en devices/{deviceID}/data, o en …/process para pasarlas antes por un proceso. El contenido nombra la medida; la organización y la sede salen del dispositivo, nunca del mensaje.
- · El broker comprueba el acceso en cada conexión
- · Un dispositivo solo puede publicar en sus propios tópicos
- Los comandos llegan en un subtópico que tú eliges, como commands/unload
# publicar una lectura mosquitto_pub -h mqtt.kowiste.com -p 8883 \ -i dev_01J8F2K7QX -u dev_01J8F2K7QX -P "$DEVICE_PASSWORD" \ -t devices/dev_01J8F2K7QX/data \ -m '{"measureID":"m_cmp04_discharge", "time":"2026-10-21T10:13:08Z", "data":{"pressure":9.42,"oilTemp":78.6}}' # escuchar comandos mosquitto_sub … -t devices/dev_01J8F2K7QX/commands/#
Cuando MQTT no es una opción
Dale al dispositivo una clave de ingesta y enviará el mismo contenido por HTTPS. La clave identifica al dispositivo, no a un usuario; se aplican las mismas reglas de propiedad y un límite de peticiones por dispositivo.
curl -X POST https://api.kowiste.com/api/ingest \
-H "Authorization: Bearer $INGEST_KEY" \
-H "Content-Type: application/json" \
-d '{"measureID":"m_cmp04_discharge",
"data":{"pressure":9.42}}'Decodificadores en JavaScript
Un proceso recibe la lectura y un objeto de estado de su medida, y devuelve la lectura que quieres guardar. Se ejecuta en un entorno V8 aislado; guárdalo y el siguiente mensaje ya lo usa.
Cómo encajan los procesos en la automatización →Un contrato, no una suposición
Cada ruta está declarada en el documento OpenAPI y se comprueba contra él en nuestros tests. Las respuestas tienen una forma en la que puedes confiar.
- Éxito
- {"data": …}, listas paginadas con meta
- Datos no válidos
- 422, indicando el campo
- Fechas
- RFC 3339
- Nombres
- camelCase; los IDs acaban en ID
- Vacío
- [] y {}, nunca null
GET /api/incidents?status=active
Authorization: Bearer kw_live_••••4f2a
{
"data": [{
"incidentID": "inc_01J9A3…",
"severity": "critical",
"peakSeverity": "critical",
"deviceID": "dev_01J8F2K7QX",
"openedAt": "2026-10-21T09:11:04Z"
}],
"meta": { "page": 1, "total": 1 }
}Claves solo con el acceso que necesitan
Un administrador de la organización crea una clave con un nombre, los permisos que lleva y una caducidad opcional. Actúa en una sede. El secreto se muestra una vez; solo guardamos su hash.
Alertas en tus propios sistemas
Una acción de webhook envía la alarma — política, vinculación, disparador, activo, estados, gravedad, hora y lecturas — junto a tu propio contenido. Solo se puede llegar a servidores públicos en los puertos 80 y 443; las redirecciones no se siguen.
Verlo en automatización →POST https://maint.example.com/api/tickets
Content-Type: application/json
{ "policy": "Compressor overpressure",
"severity": "critical",
"readings": { "pressure": 9.42 },
"payload": { "priority": "P1" } }Tu primera lectura en cinco minutos.
Siguiente: instálalo en tu propio servidor →