Skip to main content

Submit Custom Device data

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

Direct HTTP ingestion of a device's telemetry payload, step 1 of 2 when the payload includes a blob. The request body has no fixed schema. It is whatever dataPacks/blob fields the device's DataParser channel config maps, resolved by JSON path (see .../data-source/data-parser's configs[].dataPacks[].valueObjJsonPath).

Requires DataSource.connectorType == HTTP-Server and the device to be Activated. dataPacks values are extracted, parsed, and written to their mapped DataStreams synchronously within this same request. There is no queueing; a 201 response means the data has already been published. A blob mapping's value is instead a nested metadata object (see Request Body) that opens a pending upload session rather than publishing immediately. The caller must then complete the upload with the step-2 PUT before expiresIn elapses.

Size limit: The JSON payload and the blob content uploaded in step 2 use the same size limit. The default is 5 MB (5,242,880 bytes). Your deployment may set a different value. No API returns the current value.

Parameters

  • deviceId (UUID, required, path): Custom device identifier. No orgId in the route. This endpoint is org-less; access is gated solely by the http-server-data.write client-credential scope, not by org role. WEDA does not check the credential's deviceIds, so a token with this scope can write to any Custom Device.
  • channel (integer, required, query): Selects one DataParser channel config block.

Request Body

No fixed schema. For each dataPacks/blob mapping configured on the selected channel, the server reads the value at that mapping's valueObjJsonPath (and timePath, if configured) from this body. A JSON body is required. An empty body returns 400. A field mapped as blob must be a JSON object with the fields below. If the payload leaves the field out, or the field is not an object, WEDA ignores it and starts no upload (see 201 under Responses). An object without metadata returns 400. The object has these fields:

  • contentType (string, required): MIME type of the binary content to be uploaded in step 2.
  • description (string, optional): Description of this blob.
  • downloadFileName (string, required): Suggested filename for the downloaded content.
  • blobMD5 (string, required): MD5 checksum of the binary content as 32 hexadecimal characters. Upper and lower case are both accepted. Base64 is not accepted. Step 1 does not check the format. WEDA compares it with the uploaded bytes in step 2, and a wrong value or format returns 400 (WEDA.Blob.Md5Mismatch) there.
  • blobSize (integer, required): Declared size in bytes, verified against the actual bytes uploaded in step 2. Must not exceed the size limit (5 MB, 5,242,880 bytes, by default).
  • metadata (object, required): Arbitrary caller-supplied metadata, stored alongside the upload and returned unchanged in the step-2 response.

Responses

  • 201 Created: Payload ingested. If a blob mapping matched a blob object, dataStreamId/uploadId/downloadUrl/expiresIn are populated for the step-2 upload. Otherwise all four are null and the dataPacks values are still ingested. This includes a payload that leaves out the blob field and a blob field that is not an object. Check that uploadId is not null before step 2. If it is null, no upload was started and the blob content is not uploaded.
  • 400 Bad Request: The body is empty, the payload is malformed, a blob field is an object but has no metadata, a dataPacks mapping's JSON path doesn't resolve against the payload, a configured timePath's value is present but isn't a valid Unix-milliseconds number or ISO 8601 string, or the payload exceeds the size limit (5 MB by default).
  • 404 Not Found: No Custom Device with this deviceId exists (WEDA.CustomDevice.NotFound).
  • 409 Conflict: The device exists but its current state doesn't allow ingestion: it is not Activated, its DataSource connectorType is not HTTP-Server, it has no DataParser bound yet, or the requested channel doesn't exist on its DataParser. These are state conflicts on a resource that does exist, not not-found/validation problems.

Request​

Responses​

Created. If blob is not provided, ingestion completes without step 2. If blob is provided, response includes upload information for step 2.