跳至主要内容

Upload Custom Device blob content

PUT 
/api/v1/devices/{deviceId}/data-source/http-server/data

Step 2 of the two-step blob upload flow: uploads the raw binary content declared in step 1's blob metadata. uploadId must have been created by a step-1 POST with a blob mapping, and this call must happen before the pending upload's expiresIn window elapses.

Every call is treated as a brand-new upload attempt. There is no retry/idempotency handling. A second call for the same uploadId while the first is still in flight is rejected with 409, not queued or merged; once an upload completes successfully the pending session is deleted, so retrying the same uploadId afterwards returns 404 (one-time use).

Parameters

  • deviceId (UUID, required, path): Custom device identifier. Same org-less/scope-gated access model as step 1.
  • channel (integer, required, query): Must match the channel used in the step-1 request.
  • uploadId (UUID, required, query): The pending upload session identifier returned by step 1.

Request Body

Raw binary content (application/octet-stream, image/jpeg, image/png, video/mp4, application/pdf, or text/plain), not JSON. Its actual size and MD5 checksum must match the blobSize/blobMD5 declared in the step-1 request.

Responses

  • 200 OK: Upload completed. The binary was stored and the record published to the NATS Bus.
  • 400 Bad Request: The uploaded content's actual size doesn't match the declared blobSize, its MD5 doesn't match the declared blobMD5, or the content exceeds the configured size limit.
  • 404 Not Found: uploadId not found, expired, the deviceId/channel don't match what was declared in step 1, or the upload was already completed (one-time use: the pending session is deleted on success).
  • 409 Conflict: The device is not currently Activated, or another request for the same uploadId is already in progress.

Request​

Responses​

OK