Describe the bug
When fetching chat history via the GET /api/{session}/chats/{chatId}/messages endpoint, WAHA returns the exact same Unix timestamp (the time the API request was made) for all historical outgoing messages (fromMe: true).
Instead of returning the original sent time of each message, the API forces the current fetch time into both the timestamp and _data.messageTimestamp fields. This causes massive data desync on the client side, as all past messages lose their original timestamps and appear to have been sent at the exact same second (the moment the page was refreshed).
Version
Get the WAHA version by calling GET /api/version
{
"version": "2026.6.2",
"engine": "NOWEB",
"tier": "CORE",
"browser": null,
"platform": "linux/x64",
"worker": {
"id": null
}
}
Steps
To Reproduce Steps to reproduce the behavior:
- Send a few outgoing messages to a specific chat, waiting several minutes or hours between each message.
- Call the endpoint: GET /api/{session}/chats/{chatId}/messages?limit=5
- Inspect the returned JSON payload.
- See error: All older messages have their timestamp and _data.messageTimestamp fields overwritten with the current system time (the exact second the GET request was executed).
Expected behavior
The API should return the original, accurate Unix timestamp representing when each message was actually sent or received, preserving the chronological integrity of the chat history.
Requests - Responses
Request:
GET /api/SESSION_NAME/chats/6282264148251@c.us/messages?limit=2
Response: (Notice that a message sent yesterday and a message sent today both return the exact same timestamp 1782875272)
[
{
"id": "true_xxxxxx@c.us_3EB0A6B1017849915F5C4A",
"timestamp": 1782875272,
"from": "xxxxxx@c.us",
"fromMe": true,
"body": "halo",
"_data": {
"messageTimestamp": 1782875272,
"status": 4
}
},
{
"id": "true_xxxxxx@c.us_3EB07B831868DEC0D8BDFD",
"timestamp": 1782875272,
"from": "xxxxxx@c.us",
"fromMe": true,
"body": "haloww",
"_data": {
"messageTimestamp": 1782875272,
"status": 4
}
}
]
Docker Logs
N/A (No error is thrown, the API returns a 200 OK but with corrupted timestamp data).
Screenshots
N/A
Additional context
This bug completely breaks chronological message ordering on CRM dashboards or frontends that rely on WAHA's fetch API for synchronization. Because the engine resets the messageTimestamp to the time of retrieval, older messages get pulled to the bottom of the chat UI, destroying the conversational flow.
Describe the bug
When fetching chat history via the GET /api/{session}/chats/{chatId}/messages endpoint, WAHA returns the exact same Unix timestamp (the time the API request was made) for all historical outgoing messages (fromMe: true).
Instead of returning the original sent time of each message, the API forces the current fetch time into both the timestamp and _data.messageTimestamp fields. This causes massive data desync on the client side, as all past messages lose their original timestamps and appear to have been sent at the exact same second (the moment the page was refreshed).
Version
Get the WAHA version by calling
GET /api/version{ "version": "2026.6.2", "engine": "NOWEB", "tier": "CORE", "browser": null, "platform": "linux/x64", "worker": { "id": null } }Steps
To Reproduce Steps to reproduce the behavior:
Expected behavior
The API should return the original, accurate Unix timestamp representing when each message was actually sent or received, preserving the chronological integrity of the chat history.
Requests - Responses
Request:
GET /api/SESSION_NAME/chats/6282264148251@c.us/messages?limit=2Response: (Notice that a message sent yesterday and a message sent today both return the exact same timestamp 1782875272)
Docker Logs
N/A (No error is thrown, the API returns a 200 OK but with corrupted timestamp data).
Screenshots
N/A
Additional context
This bug completely breaks chronological message ordering on CRM dashboards or frontends that rely on WAHA's fetch API for synchronization. Because the engine resets the messageTimestamp to the time of retrieval, older messages get pulled to the bottom of the chat UI, destroying the conversational flow.