Saltar al contenido principal

Trigger SOS (HTTP fallback)

POST 
/v1/sdk/sos

Production path (MQTT): PUBLISH JSON to topic sos/alerts/<sdk_user_id> (QoS 1, retain false) with the same object as this request body — see MQTT tag (channels table), MQTTPublishSOSMinimal / MQTTPublishSOSFull examples, and schema SDKSOSIngestPayload.

This route is an optional HTTP fallback with the same JSON body and SDK headers (X-App-ID, X-User-ID, Authorization: Bearer <user_hash>). Do not send userId; the SDK user comes from auth. deviceId is optional; omit it for mobile-only SOS creation. When present, deviceId is the paired device hardware id. In relay mode, deviceId may reference a device belonging to a different user within the same app — the backend resolves the target user automatically (see MQTT tag, LoRa relay).

Behaviour matches the MQTT ingest path exactly: on success the backend publishes the same processed event (carrying the actuator plan) to sos/events/<sdk_user_id>, so subscribers see the incident regardless of whether it arrived over MQTT or this HTTP fallback. The synchronous response body additionally carries the plan in incident.actuators (SDKSOSActuatorSnapshot). Live transitions then arrive over MQTT as sos.actuator_update events — see the processed plan (MQTTSubscribeIncidentEvent) and live-update (MQTTSubscribeActuatorUpdate) examples under the MQTT tag.

Request​

Responses​

Open incident snapshot