Whatsapp delivery check
Skill InitechSoftware/openclaw-whatsapp-skills/skills/whatsapp-delivery-check
Given a TimelinesAI message_uid, poll GET /messages/{uid}/status_history and return the Sent / Delivered / Read timeline. Use after a send to confirm a message actually reached the recipient's device, or to answer "did X receive Y" questions from the user.From its SKILL.md
npx -y skills add InitechSoftware/openclaw-whatsapp-skills --skill whatsapp-delivery-checkAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
4 things to look at
- reads credentialsReads from 1 credential source: `$TIMELINES_AI_API_KEY`.
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 1 command, including `curl -sS -H "Authorization: Bearer $TIMELINES_AI_API_KEY" "https://app.timelines.ai/integrations/api/messages/$MESSAGE_UID/status_history"`.
- fetches URLsInstructs the agent to fetch 1 URL, including https://app.timelines.ai/integrations/api/messages/$MESSAGE_UID/status_history.
SKILL.md
3.9 KB, 921 tokens by cl100k_base, as published. Nobody here has run it
WhatsApp delivery check
Check whether a previously-sent WhatsApp message was actually delivered. TimelinesAI's POST /messages returns a message_uid that is a receipt, not a delivery confirmation — the real delivery status comes from GET /messages/{uid}/status_history.
When to use
- After a transactional send, confirm delivery before telling the user "message sent".
- Answer "did John actually receive the invoice I sent this morning?" from the human user.
- Retroactively check whether an old message was read.
- Aggregate delivery stats across many messages for response-time analytics.
Invocation payload
{
"message_uid": "a8f9b2c1-..."
}
Implementation
curl -sS -H "Authorization: Bearer $TIMELINES_AI_API_KEY" \
"https://app.timelines.ai/integrations/api/messages/$MESSAGE_UID/status_history"
Response shape
{
"status": "ok",
"data": [
{"status": "Sent", "timestamp": "2026-04-12 12:28:40 +0000"},
{"status": "Delivered", "timestamp": "2026-04-12 12:28:41 +0000"},
{"status": "Read", "timestamp": "2026-04-12 12:31:15 +0000"}
]
}
The data array is in chronological order. Each entry is a state transition.
Interpretation
| Latest status | What it means |
|---|---|
Sent | TimelinesAI accepted the send and pushed it to WhatsApp. The recipient's device has NOT confirmed delivery yet. |
Delivered | The recipient's device has received the message. They haven't opened the chat yet. |
Read | The recipient opened the chat (with read receipts enabled on their end). They've seen it. |
Typical timing on an active number: Sent → Delivered within ~1 second. Delivered → Read can take minutes or hours depending on when the recipient opens their phone. For customers with read receipts disabled, you'll never see Read — treat Delivered as the strongest signal you'll get.
Return value
Return the full status history as structured data so the caller can decide what to do:
{
"message_uid": "a8f9b2c1-...",
"latest_status": "Delivered",
"latest_timestamp": "2026-04-12 12:28:41 +0000",
"sent_at": "2026-04-12 12:28:40 +0000",
"delivered_at": "2026-04-12 12:28:41 +0000",
"read_at": null
}
For a natural-language answer to the human user:
"Yes — your invoice message to John was delivered at 12:28 UTC this morning, but he hasn't opened the chat yet (or has read receipts disabled)."
Failure modes
| Response | Meaning | What to do |
|---|---|---|
{"status":"error","message":"Message uid ... not found"} | Typo in the uid, or the uid belongs to a different workspace | Don't retry; check the uid |
{"status":"error","message":"Not authenticated"} | Wrong token | Check $TIMELINES_AI_API_KEY |
Empty data: [] array | Send was accepted but no state transition has landed yet | Wait a second and retry once |
What this skill deliberately does NOT do
- Does not poll continuously — call it once per user question. For real-time delivery tracking, poll on a timer from a different process.
- Does not interpret "missing Read status" as "unread" — many users disable read receipts, which means
Readnever arrives even if they've seen the message. Only assertReadis positive evidence, notnot Readas negative evidence. - Does not correlate across workspaces — UIDs are workspace-local. If sender and recipient are in different TimelinesAI workspaces, the
message_uidthe sender got is NOT the same UID the recipient's workspace assigned. Seedocs/state-persistence.mdfor cross-workspace correlation patterns.
What ships with it: 1 file
1.9 KB alongside SKILL.md
- README.md1.9 KB