POST /login
y luego envías el token en la cabecera Authorization: Bearer <token> en
cada solicitud protegida.
Las credenciales de operador se emiten fuera de banda por tu administrador
de ResQ. No hay registro público — cada operador está asociado a una
organización y a un conjunto de scopes de misión.
El flujo
Lee la respuesta
Si todo va bien, la API devuelve un JWT y una expiración en segundos
Unix.En caso de fallo recibes un
401 con un cuerpo AuthError.Vida útil del token
expires_at es un timestamp Unix en segundos. Trátalo como autoritativo:
no parsees el cuerpo del JWT para deducir la expiración.
Un cliente robusto debería:
- Mantener el token solo en memoria (nunca en disco en texto plano).
- Refrescarlo proactivamente cuando queden menos de 60 segundos.
- Reautenticarse desde credenciales en cualquier
401 Unauthorized.
Almacenar credenciales con seguridad
Rotación
Rota las credenciales de operador al menos trimestralmente, e inmediatamente si un token pudiera estar expuesto. La revocación se gestiona del lado servidor; el cliente solo necesita repetir el login.API de coordinación
La API de coordinación acepta el mismo JWT para rutas administrativas y de aprobación de misiones (por ejemplo,POST /admin/missions/approve).
Los endpoints públicos de ingestión — lotes de telemetría, subidas a
IPFS — pueden usar un token de servicio independiente emitido por tu
administrador. Confirma el esquema exacto para tu despliegue.
Errores que debes manejar
| Código | Significado | Qué hacer |
|---|---|---|
401 | Token ausente, expirado o inválido | Reautenticar y reintentar una vez |
403 | Token válido pero sin el scope requerido | Mostrar al operador; no reintentar |
429 | Demasiadas solicitudes | Backoff con jitter |