Edit, Revoke, or Hide a Message? UnifyPort Correction Guide

To correct a message sent through a connected account, choose the scope first: edit replaces the sent text, revoke requests recall for everyone in the conversation, and local hiding changes only your application’s view. UnifyPort documents text editing for WhatsApp and revocation for Telegram, WhatsApp, and LINE. Both actions concern messages the account itself sent; receiving an edit or deletion webhook does not grant permission to perform either action.

Key takeaways

• Use editing for a text correction, revocation for withdrawing your own message, and an application control for local visibility.
• Preserve the selected account, conversation, and message together; never target “the latest message” after an operator confirms.
• Check outbound action support separately from inbound event support.
• An API result, a webhook observation, and cleanup of downstream copies are different evidence.

Edit vs revoke vs local hiding

Consider a hypothetical support reply containing the wrong appointment time. Replacing its text and removing it from an agent’s screen solve different problems.

Intended outcome	Appropriate control	What it does not establish
Correct text already sent	Edit message	The recipient never saw the original
Withdraw a message sent by this account	Revoke message	Every saved or forwarded copy is gone
Hide a row in your own inbox	Your application’s visibility control	Anything changed in the recipient’s chat
React to an observed recall	Process message.deleted	You initiated a new revocation request

WhatsApp’s official deletion guidance warns that recipients may see a message before deletion, and media saved to Photos on iOS may remain. Do not label the action “erase everywhere” or treat recall as a guarantee that confidential content was not exposed.

Local hiding is an application design choice here, not a documented UnifyPort message-delete endpoint. Similarly, the conversation.deleted and conversation.cleared events describe local conversation changes; they are not interchangeable with recalling one message for everyone.

Check the action matrix, not just the event matrix

The current provider action matrix documents these mappings:

Connected provider	Edit sent text	Revoke own message
whatsapp	Supported	Supported
telegram	Not supported	Supported
line	Not supported	Supported
twitter, zalo, tiktok, whatsapp-protocol	Not supported	Not supported

These are adapter mappings, not promises that every request will satisfy upstream eligibility or account conditions. Unsupported combinations return 501 unsupported_by_provider.

For example, the LINE edited-message guide covers receiving and reconciling message.updated. It does not enable outbound LINE editing. Build separate controls for observing changes and requesting changes rather than enabling an Edit button whenever the receiver understands that event.

The UnifyPort revoke contract is narrower than some native moderation features: it allows revoking only messages sent by the connected account itself. Do not offer it for another group member’s message merely because the operator is an administrator.

Preserve the selected message before requesting a correction

Use the stored message.received observation to resolve the target: account_id, data.conversation.id, and data.message.id. The event can represent inbound or outbound traffic; inspect data.message.direction and verify ownership before allowing an action. Top-level event id is not the message ID.

Recommended application checks:

1. Authorize the operator for the selected messaging account and conversation.
2. Freeze the selected message identity in the confirmation dialog; show the current content and intended action.
3. Check provider support and that the message was sent by this account. For editing, require a text message.
4. Serialize correction actions for that target so two agents cannot casually overwrite each other’s decisions.
5. Record the action and its outcome separately from the visible message content.

The following are illustrative JSON request bodies with fictional identifiers, not captured traffic. Send requests from a server using X-Api-Key authentication; keep the key out of browser code.

For POST /v1/messages/edit, content is the complete replacement text, not a patch:

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C",
  "content": "Correction: the appointment is at 15:00."
}

For POST /v1/messages/revoke, select the same scoped target without replacement content:

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C"
}

The revoke reference says sender_id defaults to the account and can usually be omitted. Supplying a different sender does not expand the documented permission. Do not invent a universal correction deadline or import another API’s permissions into these requests.

Keep request results and cleanup separate

Both endpoint references show a successful response containing data.ok: true. Record the actual result; do not convert it into a claim that every recipient or downstream system has removed the old content.

Observation	Recommended next action
501 unsupported_by_provider	Disable that provider/action pair; do not repeat unchanged
edit_message_failed or revoke_message_failed	Inspect the error and target context before deciding what to do
HTTP timeout or lost response	Keep the outcome uncertain; investigate before another request
Matching message.updated or message.deleted arrives	Apply the observation to the scoped message, idempotently
No matching event arrives	Do not infer either success or failure solely from absence

Save the returned request_id for investigation using the request-tracing guide. It is not an idempotency token or a promised webhook correlation key.

For event handling, follow the delivery contract: configure signing_secret, verify HMAC-SHA256 against the timestamp and raw body, check freshness, and persist before acknowledging. Delivery order is not guaranteed. A recall observation also needs separate cleanup of owned search, CRM, or AI copies; the deletion cleanup guide explains that application boundary.

FAQ

Can I edit an attachment with the edit endpoint?

The documented action is limited to text messages. Do not treat content as a media replacement field.

Does hiding a message in my inbox withdraw it from the customer?

No. Local visibility and provider-side recall are different operations. Make the scope explicit in your interface.

Does support for message.deleted mean every revoke produces a callback?

No. Event mappings do not guarantee that every upstream account or deployment emits every mapped event. Keep the HTTP outcome and observed state separate.

Next step and sources

Start with the revoke reference and test the selection and confirmation flow in an authorized test conversation. UnifyPort is an unofficial interface; it does not replace native platform rules or guarantee erasure of external copies.

References checked on 2026-10-12:

• UnifyPort: Edit message
• UnifyPort: Revoke message
• UnifyPort: Provider actions
• WhatsApp: How to delete messages