WhatsApp Mute vs Block: Choose the Right Shared-Inbox Control
Mute a WhatsApp conversation when the goal is quieter notifications; block a contact when the goal is to stop that person messaging the account. Neither should stand in for an internal “pause automation” or “resolve ticket” control. In a shared inbox, keep those decisions separate so reducing noise does not accidentally cut off a customer or leave an automated reply running.
Three controls, three different intentions
WhatsApp’s notification guide treats muting as a chat-notification setting. Its blocking guide says blocked contacts can no longer call or send messages to you. It also says unblocking does not deliver messages sent during the blocked period. Blocking is therefore not a temporary backlog you can drain later.
| Intention | Appropriate control | Do not infer |
|---|---|---|
| Reduce chat notification noise | Mute the conversation | The support ticket is resolved or webhook intake is disabled |
| Stop contact from a particular person | Block the contact, after an authorized decision | Previous content is deleted or missed messages will return after unblocking |
| Stop an AI worker replying | An application-owned automation pause | A provider mute or block call cancels your queued jobs |
| Keep work visible for follow-up | Local queue state; optionally provider unread state | Unread means notifications are muted |
The last two rows are application design recommendations, not additional WhatsApp API features. For the read-state distinction, see WhatsApp read/unread synchronization. A notification preference, a receipt, and a team’s work assignment answer different questions.
What UnifyPort actually exposes
UnifyPort’s unofficial interface separates conversation actions from contact actions. The following are its API contracts, not Meta Cloud API routes.
| Action | Input and documented boundary | Reference |
|---|---|---|
| Mute | conversation_id, with duration in seconds or a future RFC3339 mute_until; never both | Mute conversation |
| Unmute | conversation_id | Unmute conversation |
| Block or unblock | contact_id containing the canonical WhatsApp LID in digits@lid form | Block contact and Unblock contact |
| Inspect blocked contacts | Response contains data.blocklist and the list fingerprint data.dhash | Get blocklist |
For mute, duration: 0 means forever—not “turn muting off.” Use the explicit unmute operation to remove the mute.
Check the provider action matrix before displaying these controls. The current reference maps contact blocking, unblocking, and blocklist reads to WhatsApp. It maps muting to WhatsApp and partially to LINE, with unmuting also mapped to LINE. A common route is not a promise of identical behavior across providers; unsupported combinations return 501 unsupported_by_provider.
Do not manufacture a blocking identifier
The WhatsApp block and unblock contracts reject a phone number or an @s.whatsapp.net JID as a substitute for the canonical LID. Obtain the contact’s actual identifier through the documented contact workflow; never attach @lid to a phone number and assume it identifies the same person.
Contact responses can contain distinct id, provider_user_id, and conversation_id values. Keep those meanings separate. The contact API and vCard guide explains why address-book actions and sending contact details are also different operations. Adding a contact is not a prerequisite this article asks you to perform merely to block someone.
Design the inbox decision before making the call
Consider a hypothetical support queue receiving repetitive messages. If the messages still need review, mute may address notification noise, while a local automation pause can prevent unwanted AI replies. If an authorized reviewer decides the contact should be blocked, that is a separate, deliberate change.
Recommended application workflow:
- Name the action clearly. Show “Mute notifications,” “Block contact,” and “Pause automated replies” as separate controls. Scope them to the selected messaging account and target.
- Confirm the target. For blocking, require a verified canonical LID associated with that account. If identity is uncertain, stop for review rather than guessing.
- Record intent locally. Keep the operator, reason, target, and requested action. These are your audit records, not fields to add to the API request.
- Inspect the result. The documented mutation response includes
data.ok. Do not show success solely because a button was clicked. Preserve a redacted error andrequest_idfor troubleshooting. - Reconcile uncertainty. After a block/unblock timeout, read the blocklist before issuing another mutation. Compare identifiers consistently;
dhashdetects a list change but does not explain who changed it or why. - Review queued automation separately. A job created before the decision may still exist in your database. Make workers check your local pause policy before sending; a provider setting is not a cancellation mechanism for your own queue.
For mute changes, the event reference documents conversation.updated with settings such as muted and mute_until. Treat delivered events as observations, not as a guarantee that every action produces a confirmation. The public catalogue does not document a contact-blocked event; use the documented blocklist instead of inventing one.
Acceptance checks and limits
Test with accounts you control. Confirm that the UI distinguishes a failed mutation from an applied one, that unmute does not invoke unblock, and that unblocking does not automatically release old reply jobs. Test identifier rejection and a timeout with an uncertain outcome. These are suggested tests, not reported results.
Do not use muting as webhook flow control. The documented mute endpoint changes conversation state; it does not document disabling event delivery. Likewise, this guide does not promise that blocking erases stored messages, moderates a shared group, or cancels activity in your CRM. Define those behaviors separately.
If a human-only workflow in the native app is sufficient, use its controls directly. If you require an official business integration, evaluate that contract independently rather than treating these UnifyPort routes as official WhatsApp endpoints.
FAQ
Does muting a chat stop automated replies?
Do not assume so. Implement an explicit local pause checked by the reply worker. Muting is not documented as a job-cancellation operation.
Can I block using a phone-number JID?
Not with UnifyPort’s documented WhatsApp block action. Use the canonical digits@lid contact identifier, not a phone number or @s.whatsapp.net value.
Will unblocking recover messages sent while blocked?
No. WhatsApp’s official help says those messages are not received after unblocking. Do not offer blocking as a reversible message buffer.
Is a changed dhash proof that my operation succeeded?
Not by itself. It is a fingerprint of the whole blocklist. Inspect whether the intended contact is present or absent and retain the operation result separately.
Next step and sources
Start with the Block contact reference and confirm your identifier mapping before enabling the control in a shared inbox.
Checked on 2026-09-25:
Turn messaging integration into a stable product pipeline.
Start by sending through one API, then bring every inbound message back into your business system with standard events.