APIs Device to Cloud UDP Devices Send and receive IoT data

Overview Copied!

This page describes how to exchange data between the Device to Cloud platform and your UDP devices.

• Downlink (platform → device): Send messages to a device by creating content instances in the outgoing-msg container. You can choose the encoding format (plain string, base64, hexstring) and control delivery behaviour with queuing labels.
• Uplink (device → platform): When a device sends a UDP datagram, the platform processes it and stores the result in the device’s received-msg container.
• Error handling: If a downlink message fails (decoding error, device offline, internal error), the platform creates error entries in the error-msg and logs containers for tracking and debugging.

The sections below cover the API requests, message formats, uplink and downlink processing flows, architecture details, and error codes.

Send message to IoT device Copied!

To send a downlink message to a UDP device, create a content instance in the device’s outgoing-msg container. The message payload is placed in the con field, and encoding or queuing behaviour is controlled via labels in the lbl array.

POST {{API_URL}}/device-communication/myUDP-Device01/outgoing-msg
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

{
  "m2m:cin": {
    "con": "BGVsbG8gdmlhIFVEUB==",
    "lbl": ["decode:base64"]
  }
}

HTTP/1.1 201 Created
date: Mon, 25 May 2026 16:17:57 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T16:17:57.858Z
x-m2m-rsc: 2000
x-azure-ref: 20260525T161757Z-r1d8c8b4b7f8ncs4hC1FRA2s6w0000000ew000000000ayuk
x-cache: CONFIG_NOCACHE
accept-ranges: bytes
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233133343239
vary: Origin
x-kong-upstream-latency: 212
x-kong-proxy-latency: 2
x-kong-request-id: 91e1eb0ae1fb9709414f46607ce4164f
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 504
x-http2-stream-id: 3
{
  "m2m:cin": {
    "con": "BGVsbG8gdmlhIFVEUB==",
    "cnf": "text/plain:0",
    "ty": 4,
    "rn": "sent-123e4567-e89b-12d3-a456-426614174000",
    "ri": "5f4dcc3b5aa765d61d8327deb882cf99",
    "cr": "CmyApplication",
    "ct": "20260422T120000,000",
    "lt": "20260422T120000,000"
  }
}

Data format in con

There is no fixed data format specified for UDP devices — data may be binary. The con field in an outgoing message (outgoing-msg) container instance can be a plain string, a hexstring-encoded string, or a base64-encoded string.

Encoding flags

The lbl array on the container instance supports the following flags:

Message queuing

When queuing is enabled and multiple messages are pending, the platform sends them in order (oldest → newest) with a 1-second interval between each message so the device has time to process them. This interval is fixed and cannot be changed.

Receive data from IoT device Copied!

When your UDP device sends data to the platform, the following happens:

1. The device sends a UDP datagram to the D2C endpoint via the Telekom mobile network.
2. The platform identifies the device by resolving its IP address to the device IMEI.
3. The platform validates the incoming message.
4. If validation fails, the message is rejected with 400 Bad Request.
5. The uplink payload is stored as a content instance in the device’s received-msg container in DMO, enriched with the device’s uplink properties.
6. The platform returns 200 OK.

Process uplink messages

After the platform processes an uplink datagram, a content instance is created in the device’s received-msg container. Below is an example of the resulting message:

{
  "m2m:cin": {
    "con": {
      "nodeResourceName": "myUDP-Device01",
      "nodeID": "urn:gsma:imei:999907050041452",
      "time": 1755693615539,
      "method": "data-received",
      "messageType": "data-received",
      "data": "68656c6c6f20333234",
      "uplinkProperties": {
          "AssetId": "12345"
      },
      "status": {
          "code": 200,
          "message": "success"
      }
    },
    "cnf": "application/json:0"
  }
}

Uplink messages are stored in the received-msg container with additional uplink properties configured during device provisioning. The content instance has the following structure:

Fields:

• nodeResourceName — the device ID as registered during provisioning.
• nodeID — the IMEI-based node identifier (urn:gsma:imei:<imei>).
• time — Unix timestamp (milliseconds) when the message was received.
• method / messageType — always "data-received" for uplink data.
• data — the raw payload sent by the device, hexstring-encoded.

data field encoding

The data field always contains the device payload encoded as a hexstring string. The platform hexstring-encodes the raw binary data received from the device so it can be safely transported in JSON.

To retrieve the original device payload, decode the data value from hexstring in your application.

• uplinkProperties — key-value pairs extracted from the device labels that start with d2c-uplink-property_ (e.g. the label d2c-uplink-property_AssetId:12345 produces "AssetId": "12345").
• status.code / status.message — processing result (200 / "success" on success).
• cnf — content format; "application/json:0" indicates a JSON payload.

Downlink Message Flow Copied!

When the platform sends data to a UDP device, the message is processed through the following steps:

1. Your application creates a content instance in the device’s outgoing-msg container in DMO.
2. The platform validates the message format. The m2m:cin object must contain a con (content) field. Optionally, you can include a lbl array with encoding and queuing labels.
3. If schema validation fails (e.g. missing con field), the platform returns 400 Bad Request. If the payload cannot be decoded (e.g. invalid base64 or hexstring), the platform returns 415 Unsupported Media Type and writes an error entry to both the error-msg and logs containers.
4. The platform evaluates the queuing label:
   • If the outgoing message contains the label queuing:enabled — the message is buffered until the device sends an uplink datagram.
   • If the label queuing is missing or equals queuing:disabled — the platform attempts to deliver the message immediately.
5. The platform checks whether the device is currently connected via the mobile network:
   • Device is connected — the message is delivered to the device and moved to the sent-msg container.
   • Device is not connected — an error entry is written to both the error-msg and logs containers, and the message remains in the outgoing-msg container (see Buffer downlink messages with queuing ).

Normal case — device is connected

1. Your application creates an outgoing message in DMO (label queuing:disabled or no queuing label).
2. The platform delivers the downlink data to the device via the mobile network.
3. The outgoing message is moved to the sent-msg container.
4. The mobile network buffers the data until the device wakes up, then delivers it.

Not-connected case — device is offline

1. Your application creates an outgoing message in DMO (label queuing:disabled or no queuing label).
2. The platform detects that the device is not connected to the mobile network.
3. An error entry is written to both the error-msg and logs containers.
4. The outgoing message remains in the outgoing-msg container — it is not deleted.

Get last received device messages via API

Use this API to retrieve the last (most recent) content instance created in the device’s received-msg container. The endpoint returns the latest uplink message the platform stored for the specified device.

Request notes:

• URL: GET …/received-msg/la — la (latest) returns the most recent content instance.
• Authentication: standard Bearer token in Authorization header and oneM2M headers (X-M2M-Origin, X-M2M-RI) as shown below.

GET {{API_URL}}/device-communication/myUDP-Device01/received-msg/la
Accept: application/json
Content-Type: application/json
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

HTTP/1.1 200 OK
date: Mon, 25 May 2026 16:17:57 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T16:17:57.858Z
x-m2m-rsc: 2000
x-azure-ref: 20260525T161757Z-r1d8c8b4b7f8ncs4hC1FRA2s6w0000000ew000000000ayuk
x-cache: CONFIG_NOCACHE
accept-ranges: bytes
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233133343239
vary: Origin
x-kong-upstream-latency: 212
x-kong-proxy-latency: 2
x-kong-request-id: 91e1eb0ae1fb9709414f46607ce4164f
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 504
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": {
      "nodeResourceName": "myUDP-Device01",
      "nodeID": "urn:gsma:imei:999907050041452",
      "time": 1752761134124,
      "messageType": "data-received",
      "status": {
        "code": 200,
        "message": "success",
        "detail": null
      },
      "data": "68656c6c6f20333234",
      "uplinkProperties": {
        "AssetId": "12345"
      }
    },
    "cnf": "application/json:0",
    "ty": 4,
    "cs": 234,
    "st": 12,
    "cr": "Cd2c-protocol-adapter-udp",
    "rn": "aabefd77-2166-4710-8e22-cce1c8d76312",
    "ri": "6879032f50fa7af1af3e4999",
    "pi": "68767201272211da007e5999",
    "ct": "20250717T140535,167000",
    "lt": "20250717T140535,167000"
  }
}

Notes on the response:

• The data field inside content is hexstring-encoded. Decode it to obtain the original device payload.
• uplinkProperties contains key/value pairs derived from device labels prefixed with d2c-uplink-property_.
• contentInfo (application/json:0) indicates the stored content format.

Possible status codes:

• 200 OK — latest content instance returned.
• 404 Not Found — no messages available for the device (container empty or device unknown).
• 401/403 — authentication/authorization failure.

Example: decode the data value (hexstring) in your application to get the original bytes sent by the device.

Downlink message types and error requests {#_downlink_requests_scenario}

The following examples show how to create outgoing messages with different encoding types and how the platform handles invalid payloads.

Send downlink message encoded in Base64

POST {{API_URL}}/device-communication/myUDP-Device01/outgoing-msg
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

{
  "m2m:cin": {
    "con": "RlJUWUxLNQ=",
    "lbl": ["queuing:disabled", "decode:base64"]
  }
}

HTTP/2 201 Created
date: Mon, 25 May 2026 17:14:09 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:14:09.677Z
x-m2m-rsc: 2001
x-azure-ref: 20260525T171409Z-r1d8c8b4b7f5ql5bhC1FRAfz140000000hb000000000prqk
x-cache: CONFIG_NOCACHE
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233135303632
vary: Origin
x-kong-upstream-latency: 217
x-kong-proxy-latency: 2
x-kong-request-id: 1a85e9049b246c339905a3143678ef3c
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 311
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": "RlJUWUxLNQ=",
    "lbl": [
      "queuing:disabled",
      "decode:base64"
    ],
    "ty": 4,
    "cs": 12,
    "st": 1,
    "cr": "CmyApplication",
    "rn": "733c1c82-5b05-43f0-9a58-6ee0b7847775",
    "ri": "6a1483616db94c7dbcfc043d",
    "pi": "69ccfe987b2bb29ede53507b",
    "ct": "20260525T171409,669000",
    "lt": "20260525T171409,669000"
  }
}

Send downlink message encoded in HexString

POST {{API_URL}}/device-communication/myUDP-Device01/outgoing-msg
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

{
  "m2m:cin": {
    "con": "68656C6C6F686179",
    "lbl": ["queuing:disabled", "decode:hexstring"]
  }
}

HTTP/2 201 Created
date: Mon, 25 May 2026 17:14:09 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:14:09.677Z
x-m2m-rsc: 2001
x-azure-ref: 20260525T171409Z-r1d8c8b4b7f5ql5bhC1FRAfz140000000hb000000000prqk
x-cache: CONFIG_NOCACHE
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233135303632
vary: Origin
x-kong-upstream-latency: 217
x-kong-proxy-latency: 2
x-kong-request-id: 1a85e9049b246c339905a3143678ef3c
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 311
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": "68656C6C6F686179",
    "lbl": [
      "queuing:disabled",
      "decode:hexstring"
    ],
    "ty": 4,
    "cs": 12,
    "st": 1,
    "cr": "CmyApplication",
    "rn": "733c1c82-5b05-43f0-9a58-6ee0b7847775",
    "ri": "6a1483616db94c7dbcfc043d",
    "pi": "69ccfe987b2bb29ede53507b",
    "ct": "20260525T171409,669000",
    "lt": "20260525T171409,669000"
  }
}

Send downlink message without encoding (plain string)

POST {{API_URL}}/device-communication/myUDP-Device01/outgoing-msg
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

{
  "m2m:cin": {
    "con": "Hello myUDP-Device01",
    "lbl": ["queuing:disabled"]
  }
}

HTTP/2 201 Created
date: Mon, 25 May 2026 17:14:09 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:14:09.677Z
x-m2m-rsc: 2001
x-azure-ref: 20260525T171409Z-r1d8c8b4b7f5ql5bhC1FRAfz140000000hb000000000prqk
x-cache: CONFIG_NOCACHE
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233135303632
vary: Origin
x-kong-upstream-latency: 217
x-kong-proxy-latency: 2
x-kong-request-id: 1a85e9049b246c339905a3143678ef3c
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 311
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": "Hello myUDP-Device01",
    "lbl": [
      "queuing:disabled"
    ],
    "ty": 4,
    "cs": 12,
    "st": 1,
    "cr": "CmyApplication",
    "rn": "733c1c82-5b05-43f0-9a58-6ee0b7847775",
    "ri": "6a1483616db94c7dbcfc043d",
    "pi": "69ccfe987b2bb29ede53507b",
    "ct": "20260525T171409,669000",
    "lt": "20260525T171409,669000"
  }
}

When no decode: label is present, the platform treats con as a plain UTF-8 string and converts it to a lowercase hexstring before sending to the device.

Send downlink message with invalid encoding

The following example demonstrates what happens when the payload does not match the declared encoding. Here con contains an invalid hexstring ("zz11" includes non-hex characters), but the label declares decode:hexstring:

POST {{API_URL}}/device-communication/myUDP-Device01/outgoing-msg
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

{
  "m2m:cin": {
    "con": "zz11",
    "lbl": ["queuing:disabled", "decode:hexstring"]
  }
}

HTTP/2 201 Created
date: Mon, 25 May 2026 17:14:09 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:14:09.677Z
x-m2m-rsc: 2001
x-azure-ref: 20260525T171409Z-r1d8c8b4b7f5ql5bhC1FRAfz140000000hb000000000prqk
x-cache: CONFIG_NOCACHE
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 486cbd34bf187c63cf1c233135303632
vary: Origin
x-kong-upstream-latency: 217
x-kong-proxy-latency: 2
x-kong-request-id: 1a85e9049b246c339905a3143678ef3c
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 311
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": "zz11",
    "lbl": [
      "queuing:disabled",
      "decode:hexstring"
    ],
    "ty": 4,
    "cs": 12,
    "st": 1,
    "cr": "CmyApplication",
    "rn": "733c1c82-5b05-43f0-9a58-6ee0b7847775",
    "ri": "6a1483616db94c7dbcfc043d",
    "pi": "69ccfe987b2bb29ede53507b",
    "ct": "20260525T171409,669000",
    "lt": "20260525T171409,669000"
  }
}

This request results in an error. The platform returns a 415 Unsupported Media Type status and creates an error message in the error-msg and logs containers.

Error Handling Copied!

When an error occurs during downlink message processing (e.g. decoding failure, device not found, device offline), the platform creates error messages in DMO containers to ensure proper tracking and debugging.

Error containers

Error messages are stored in two DMO containers:

Error flow

1. Error detection — an error occurs during message processing.
2. Error message creation:
   • If the device is found: error messages are created in both the error-msg container and the logs container.
   • If the device is not found: an error message is created only in the logs container.

Error message structure

Below is an example of an error message stored in the error-msg container:

GET {{API_URL}}/device-communication/myUDP-Device01/error-msg/la
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

HTTP/2 200 OK
date: Mon, 25 May 2026 17:20:36 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:20:36.028Z
x-m2m-rsc: 2000
x-azure-ref: 20260525T172035Z-r1d8c8b4b7fcntbshC1FRA3bz40000000d2g0000000010n3
x-cache: CONFIG_NOCACHE
accept-ranges: bytes
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 16ae5c1a33f7a30b54bf2331393532
vary: Origin
x-kong-upstream-latency: 426
x-kong-proxy-latency: 4
x-kong-request-id: da85c0750ee8771caa5c0e6e50d85b0f
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 551
x-http2-stream-id: 3

{
  "m2m:cin": {
    "con": {
      "nodeResourceName": "myUDP-Device01",
      "nodeID": "urn:gsma:imei:999907050041452",
      "data": "BGVsbG8gdmlhIFVEUE==",
      "status": {
        "code": 415,
        "message": "unsupported media type",
        "detail": "Error during decoding message. Unsupported message format"
      }
    },
    "cnf": "application/json:0"
    "ty": 4,
    "cs": 295,
    "st": 1023,
    "cr": "CmyApplication",
    "rn": "f74fa8fc-38df-487b-8db3-e4d7501e4783",
    "ri": "6a1484a56db94c7dbcfc045c",
    "pi": "69811cbca9e3473a78b69e17",
    "ct": "20260525T171933,081000",
    "lt": "20260525T171933,081000"
  }
}

Fields:

• nodeResourceName — the device ID as registered during provisioning.
• nodeID — the IMEI-based node identifier (urn:gsma:imei:<imei>).
• data — the original payload that caused the error.
• status.code — HTTP-style error code (e.g. 415 for unsupported media type, 422 for unprocessable entity).
• status.message — short error description.
• status.detail — detailed error message for debugging.
• cnf — content format; "application/json:0" indicates a JSON payload.

Log message structure

Below is an example of a log message stored in the logs container:

GET {{API_URL}}/d2c-protocol-adapter-agent-udp/logs/la
Accept: application/json
Content-Type: application/json;ty=4
X-M2M-Origin: CmyApplication
X-M2M-RI: 123
Authorization: Bearer {{ACCESS_TOKEN}}

HTTP/2 200 OK
date: Mon, 25 May 2026 17:20:36 GMT
content-type: application/json; charset=utf-8
request-context: appId=cid-v1:
x-service-responder: device-management-orchestrator
x-m2m-ri: 123
x-m2m-rvi: 4
x-m2m-ot: 2026-05-25T17:20:36.028Z
x-m2m-rsc: 2000
x-azure-ref: 20260525T172035Z-r1d8c8b4b7fcntbshC1FRA3bz40000000d2g0000000010n3
x-cache: CONFIG_NOCACHE
accept-ranges: bytes
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
referrer-policy: no-referrer
x-tardis-traceid: 16ae5c1a33f7a30b54bf2331393532
vary: Origin
x-kong-upstream-latency: 426
x-kong-proxy-latency: 4
x-kong-request-id: da85c0750ee8771caa5c0e6e50d85b0f
strict-transport-security: max-age=31536000; includeSubDomains
content-length: 551
x-http2-stream-id: 3
{
  "m2m:cin": {
    "con": {
      "identifier": "urn:gsma:imei:999907050041452",
      "type": "UDP downlink message failed",
      "service": "d2c-protocol-adapter-agent-udp",
      "data": "BGVsbG8gdmlhIFVEUE==",
      "status": {
        "code": 415,
        "message": "unsupported media type",
        "detail": "Error during decoding message. Unsupported message format"
      }
    },
    "cnf": "application/json:0",
     "ty": 4,
     "cs": 295,
     "st": 1023,
     "cr": "CmyApplication",
     "rn": "f74fa8fc-38df-487b-8db3-e4d7501e4783",
     "ri": "6a1484a56db94c7dbcfc045c",
     "pi": "69811cbca9e3473a78b69e17",
     "ct": "20260525T171933,081000",
     "lt": "20260525T171933,081000"
  }
}

Fields:

• identifier — the IMEI-based node identifier (urn:gsma:imei:<imei>).
• type — describes the error category (e.g. "UDP downlink message failed").
• service — the service that produced the log entry (d2c-protocol-adapter-agent-udp).
• data — the original payload that caused the error.
• status.code / status.message / status.detail — same semantics as in the error-msg container.
• cnf — content format; "application/json:0" indicates a JSON payload.

Error codes

Node updates {#_node_updates}

When a device node is updated (e.g. labels are changed during re-provisioning), the platform automatically updates the uplink properties used to enrich incoming messages. The uplink properties are derived from device labels that follow the pattern d2c-uplink-property_<key>:<value>.

For example, if a device label is changed from d2c-uplink-property_AssetId:1234 to d2c-uplink-property_AssetId:5678, the platform updates the properties accordingly, and all subsequent uplink messages will include the new value.

Buffer downlink messages with queuing Copied!

The platform supports two runtime scenarios for buffering downlink messages, depending on the queuing label and the device connection status.

Scenario: queuing enabled — message is buffered immediately {#_scenario_queuing_enabled}

When a container instance is created in the outgoing-msg container with the label queuing:enabled, the message is not forwarded immediately. Instead, it is buffered in the outgoing-msg container until the device connects to D2C.

The flow works as follows:

1. Your application creates a content instance in the outgoing-msg container in DMO with "lbl": ["queuing:enabled"].
2. The platform detects the queuing:enabled label and buffers the message — it is not forwarded to the device.
3. The message remains in the outgoing-msg container until the device sends an uplink datagram.
4. On the next uplink, the platform checks for pending queued messages, delivers them in order (oldest → newest) with a 1-second interval, and moves delivered messages to the sent-msg container.

Scenario: queuing disabled — device is not connected {#_scenario_queuing_disabled_offline}

This is the default behaviour. If the container instance created in outgoing-msg has the label queuing:disabled — or the queuing label is missing entirely — the platform tries to deliver the message immediately. However, if the device is not connected, the message cannot be delivered.

The flow works as follows:

1. Your application creates a content instance in the outgoing-msg container in DMO (label queuing:disabled or no queuing label).
2. The platform attempts to deliver the message to the device immediately.
3. The platform detects that the device is not connected.
4. An error entry is written to both the error-msg and logs containers.
5. The message stays in the outgoing-msg container — it is not deleted.

Summary of queuing behavior

Next: Forward messages to applications

In the next step, you learn how to integrate your application and use device groups to configure the data routing to your application endpoint.