Ingest API

Two transports, one authentication model: fleet-scoped hashed keys. The server stamps the tenant from the key — never from the payload — so a device cannot write into another fleet or another organization.

REST

POST /v1/ingest
X-Ingest-Key: vsk_…

{
  "device_id":  "uuid — must belong to the key's fleet",
  "payload_hex": "raw frame, hex-encoded",
  "ts":          "optional ISO-8601; defaults to arrival time"
}

→ 202 Accepted   (decoding happens off the request path)

MQTT

Publish the same hex payload to ingest/{fleet_id}/{device_id} — username is the fleet id, password is the ingest key. The broker enforces a per-fleet ACL: publishing to another fleet's topic is rejected at the broker, before our code ever sees it.

Failure semantics

A frame that cannot be decoded (for example, shorter than the active rule expects) is parked on a dead-letter stream and never blocks the pipeline; the raw payload is stored regardless, so a corrected rule can replay it.

Rate/size limits are per plan. 401 means the key is wrong or revoked; 404 means the device id is not in the key's fleet — check both before suspecting the pipeline.