Get downlink frame history

Returns the downlink frames queued during the given period — sent, waiting and withdrawn — together with their statuses. Use it to check what happened to frames if you did not receive downlink_status messages.

The response arrives as two get_downlink_data_resp messages with the same operation_id: first status: 1 — the request is accepted, then status: 3 — the data.

Request and response: get_downlink_data_req → get_downlink_data_resp (two messages).
Access: a low access level token sees the devices of its application and of applications that granted it access; a high access level token sees all devices of the owner.

Request

Fields not marked as required may be omitted.

Field	Type	Description
cmd	string	get_downlink_data_req
operation_id	string	Any string; the server returns it in the response to match the request and the response
date_from	string	Required. Period start, inclusive. Format YYYY-MM-DD HH:MM:SS+HHMM
date_to	string	Required. Period end, exclusive. Same format
devEui	string	Device DevEUI, 16 hex characters. Without it — all available devices
limit	uint32	How many frames to return. Default 10; the server reduces a value above 100 to 100
descending	bool	true — newest first. Default false: oldest first

{
    "cmd": "get_downlink_data_req",
    "operation_id": "rsm234",
    "devEui": "7950D20CBBB77561",
    "date_from": "2026-10-07 00:00:00+0500",
    "date_to": "2026-10-08 00:00:00+0500",
    "limit": 10
}

Response

The first message acknowledges the request:

{
    "cmd": "get_downlink_data_resp",
    "operation_id": "rsm234",
    "status": 1
}

The second one carries the data:

Field	Type	Description
cmd	string	get_downlink_data_resp
operation_id	string	Value from the request
status	uint8	1 — request accepted, 3 — data, 2 — error
dataCount	uint32	Number of frames in the list
dataList	array	Frames; their fields are in the table below
error_code, error_text	uint8, string	Only on error, see below

Frame fields in dataList:

Field	Type	Description
devEui, devAddr	string	The device
time	string	Queuing time, UTC
data	string	Payload in hex
downlink_status	uint8	Frame status code, see the status table
downlink_status_text	string	Status name, e.g. Delivered
downlink_ack	bool	true — the frame has a final status
downlink_ack_time	string or null	When the frame got its final status; null while there is no final status

{
    "cmd": "get_downlink_data_resp",
    "operation_id": "rsm234",
    "status": 3,
    "dataCount": 1,
    "dataList": [
        {
            "devEui": "7950D20CBBB77561",
            "devAddr": "7950D20C",
            "time": "2026-10-07 09:15:03+0000",
            "data": "FFFFFFFFFFFF",
            "downlink_status": 3,
            "downlink_status_text": "Delivered",
            "downlink_ack": true,
            "downlink_ack_time": "2026-10-07 09:47:21+0000"
        }
    ]
}

Errors

error_code	error_text	What happened
3	Invalid date range	date_from or date_to is missing

On error a single message with status: 2 arrives, without the acknowledgement.

Good to know

• Check the date format. If a date cannot be parsed, the server sends only the first message (status: 1) and no data.
• Specify the time zone in dates. Times in the response are UTC.
• The server does not use the appId and devAddr request fields for filtering — filter by devEui.
• downlink_ack means the frame has a final status, not that the device acknowledged reception: frames are sent unconfirmed. For details, see frame status.

Current ONS version

The downlink_status and downlink_status_text fields were added to the server in June 2026 and are not in the v0.17 description.

See also

• Sending data to a device — the scenario and frame statuses.
• get_data_req — uplink history.