WhatsApp hybrid inbox: Coexistence (Cloud) + WhatsApp Web on one number

Overview

The hybrid inbox joins, in a single conversation, a Coexistence (Cloud) inbox and a WhatsApp Web inbox that share the same physical number. Instead of two separate inboxes for the same contact, you work in one place and the platform automatically chooses which transport to send with.

• Cloud (Coexistence) is authoritative for inbound: conversations live in the Cloud inbox.
• WhatsApp Web is a send + fallback transport: used, for example, outside the 24h window to send a session message over WhatsApp Web, which Meta does not charge for, instead of paying for a template.
• Inside the window, replying over Cloud has a service cost: since 2026-10-01 that reply is a service message. The platform estimates it as free within the number's monthly allowance of 1,000 service messages and with a cost after it. Estimated monthly allowance; Meta does not publish this limit in the documentation tracked here. Meta does not charge for WhatsApp Web.
• Both inboxes still exist — pairing is a link, never a merge.

Every outgoing message gets a transport badge ("via Coexistência (Cloud)" or "via WhatsApp Web", with a fallback marker when applicable), so you always know which transport delivered it.

The connection order matters, and there is only one that works. Connect the Coexistence (Cloud) inbox first, wait for Meta's synchronization (it can take up to ~24 hours), and only then connect/pair the WhatsApp Web inbox. Activating Coexistence unlinks every companion device from the WhatsApp Business app — including a WhatsApp Web inbox that was already paired on that number.

Prerequisites

• The Hybrid inbox feature enabled on the account (ask your platform operator).
• A Coexistence (Cloud) inbox connected through Embedded Signup on the number — this is always the first connection.
• Meta's synchronization completed for that number (it can take up to ~24 hours after activation).
• The WhatsApp Business app installed on the number's phone, with internet, to scan the WhatsApp Web QR after the synchronization.
• An administrator profile to create inboxes, pair/unpair and change routing.

Do not connect WhatsApp Web before Coexistence. If a WhatsApp Web inbox already exists on that number, it will be logged out when Coexistence is activated and must be paired again (scan a new QR). Re-pairing loses nothing: the same inbox is reused — phone number, conversations, contacts and message history all stay. Only the gateway session is rebuilt.

Step by step

1. Connect Coexistence (Cloud) — always first

1. In Settings → Inboxes, create a WhatsApp inbox and choose the WhatsApp Cloud provider with Embedded Signup.
2. In Meta's flow, select the number already used in WhatsApp Business and complete the coexistence activation for that number.
3. On activation, Meta unlinks every companion device from WhatsApp Business. This is expected — it is exactly why WhatsApp Web comes afterwards.

2. Wait for Meta's synchronization

4. Meta syncs the number's history and contacts into the Cloud inbox. This can take up to ~24 hours.
5. Do not move on until the Cloud inbox is receiving and sending messages normally.

3. Connect (or re-pair) the WhatsApp Web inbox

6. Only now create the WhatsApp Web inbox with the same number — or, if it already existed, open the inbox and generate a new QR on its connection screen.
7. On the phone: WhatsApp → Linked devices → Link a device and point the camera at the QR.
8. Wait for the Web inbox to reach the connected state.

4. Pair the two inboxes

9. Open Inbox settings for the Cloud (Coexistence) inbox and go to the Híbrido (Hybrid) tab.
10. Under WhatsApp Web inbox to pair, select the Web inbox with the same number.
11. Click Pair inboxes. The platform validates it (same account, same number, one Cloud + one Web) and creates the link. Required bots, flows, automations and memberships are mirrored additively to Cloud without removing their Web bindings. Web campaigns stay active on their original inbox, and Web HistorySync stays enabled for groups, newsletters and other surfaces Coexistence does not deliver. Only duplicable 1:1 history is filtered.
12. On the Web inbox, the Hybrid tab becomes a read-only mirror ("configure on the Cloud inbox").

Settings & options

On the Híbrido tab (on the Cloud inbox) you set the routing:

• Receives (inbound authority): which transport owns inbound (v1: Cloud/Coexistence).
• Default send transport: inside the 24h window (default: Cloud). Over Cloud, the reply is a service message: the estimate treats it as free within the number's estimated monthly allowance and with a cost after it; actual billing depends on Meta's report.
• Out-of-window send transport: when the window closes (default: WhatsApp Web — not billed by Meta).
• Automatic fallback: after a definite failure, allow one attempt through the sibling transport eligible for this message. A timeout or uncertain result does not trigger an automatic resend.
• Allow composer override: agents pick the transport per conversation (Auto / Cloud / Web).

Approved templates, Meta-native interactive messages, WhatsApp Flows and catalog go through Cloud. WazMeow-only interactive messages and group/newsletter conversations continue through Web.

A call received through the WhatsApp Web session does not reopen Meta’s 24-hour window.

When Meta refuses a message for being outside the 24-hour window, the platform re-sends it once through WhatsApp Web, as long as that session is connected.

Automatic distribution per contact

With the unified inbox active, an administrator configures distribution on the Cloud inbox, in the Hybrid tab. The Web inbox only shows the saved proportion and cannot edit it.

1. Turn on Automatic distribution per contact.
2. Drag Percentage through WhatsApp Web, from 0 to 100.
3. Cloud API automatically receives the complementary percentage, totaling 100%.
4. Check the summary, such as 40% WhatsApp Web · 60% Cloud API. With the slider focused, use the arrow keys to adjust it or Home/End to reach the endpoints.
5. Click the existing Save routing button. Discard changes only restores the distribution draft and does not change other settings on the page. Reloading after a conflict brings back the latest saved configuration.

Changes stay local until saving. The restart notice only appears when a valid proportion differs from the saved one. Saving a new proportion resets the count for all contacts; turning on and saving also starts a new count. The percentage is counted per contact only across support replies eligible on both channels. 0% or 100% does not disable channels or features exclusive to Web or Cloud, and the proportion does not guarantee savings or delivery.

Distribution chooses the channel before sending. Fallback is a separate option applied after a definite failure, if the sibling can carry that message. A timeout or uncertain result does not trigger an automatic resend through the other channel, to avoid duplicates.

Single operational inbox (optional)

When the operator also enables Single operational inbox, an administrator can activate it on the Hybrid tab:

• Cloud becomes the single entry in day-to-day operational lists and pickers;
• the physical Web inbox is not deleted, merged or disabled and remains available in settings, reporting and audit;
• groups, newsletters, calls, HistorySync, ignore rules, campaigns and Web-only sends continue using Web;
• old 1:1 Web conversations are resolved and cross-linked to the Cloud conversation; their messages and calls remain on their original rows;
• before freezing any conversation, the platform tries to reconcile on its own that conversation's Maestro control state (human stand-down, the specific Robot, and the autonomy set only there) onto the Cloud conversation. Only a pending human approval needs a decision from you;
• activation reports progress and automatically returns to the visible two-inbox mode if it fails.

On deactivation, the Web inbox returns to operational lists. Existing links and resolved history remain intact; there is no destructive rollback or automatic history merge.

What each transport covers

WhatsApp Web session status

When you open or refresh a conversation that uses this pair, the platform reads the latest available observation from the physical Web inbox. The notice appears on that opening or refresh; it does not promise an immediate alert from a probe or continuous monitoring of a tab that is already open.

Only a fresh observation confirming that the session is offline shows “WhatsApp Web has had no active session since {date and time}”, in the account time zone. If the episode started on a different day, the date accompanies the time. While that outage is confirmed, messages that require Web will not be sent. The notice does not say whether an earlier message was delivered, resend it, or confirm fallback or retry through another transport.

A missing, stale, invalid, or unavailable observation is an unknown state, not a disconnection. The person handling the conversation sees that context and contacts an administrator; do not recreate the inbox, delete history, or log out to try to resolve an unknown state. When the physical Web inbox is identified and the profile is authorized, the administrator opens its existing Connection. Requesting reconnection can fail; only a new connected-session confirmation removes the notice.

An administrative email, when sent about a known outage, also does not prove recovery, message delivery, or an update to the conversation that is already open.

Contact cards and scheduled messages

In the composer, use Contact to create a native card. The picker shows people only: phone numbers are normalized, repeated records for the same number appear once, and technical group, channel, broadcast and bot identities stay out of search. The same structured card is preserved when forwarded or scheduled, whether delivery uses Cloud/Coexistence or WhatsApp Web.

When scheduling a message, the text field uses the same editing surface as the composer, including the formatting toolbar supported by the channel. You can also attach files, choose media from the library, record a voice note, and open the native template or interactive composers available for that inbox. The preview validates the content and transport capability before publication is allowed.

1:1 messages that Cloud cannot display

In Cloud-primary mode, the message still arrives through Coexistence first. When Cloud provides only “This message is not supported”, the platform waits for WhatsApp Web's decrypted copy, verifies that both events represent the same message, and updates the existing Cloud bubble. Text, captions, media, stickers, audio/voice notes and other Web-recognized formats keep their original position and timestamp, without creating a second message. If an earlier delivery race also left a technical “Waiting for message” bubble in the Web inbox, it is removed after the Cloud bubble is recovered.

Matching is deliberately conservative: if the platform cannot prove that the two events are the same item, it keeps the unsupported notice instead of placing content in the wrong conversation. Keep the paired Web session connected even when Cloud is the primary transport.

While text or media is still being recovered, the conversation shows a temporary state instead of exposing the provider's technical placeholder. Flows, rules, bots, Captain, webhooks, and notifications wait until the content is ready and receive one stable version of the message. If recovery becomes permanently unavailable, the agent sees a notice and no automation runs against the placeholder.

Poll votes and event replies are updates to a message that already exists, not new messages: WhatsApp shows no bubble for them. On the unified inbox Coexistence still delivers that encrypted update as “This message is not supported”; the WhatsApp Web copy applies the vote or RSVP to the original card and the Cloud notice is discarded automatically, whichever copy arrives first. Answering an event from the platform works on the card shown in the unified conversation.

If a “Waiting for the content of this message” bubble stays unanswered for more than 30 minutes — the sender never re-sent the content — it turns into “The content of this message could not be recovered” instead of waiting forever. When a media received through Cloud could not be downloaded, the bubble offers “Try downloading again”: the platform fetches the file once more by the same provider identifier and attaches it to the message as soon as it arrives.

Cost and currency

On the same tab, the Custos (Cost) section shows real message cost (Meta pricing analytics) by category, in the WABA billing currency and in your display currency (FX conversion). Coexistence accounts cannot migrate their Meta billing currency — so display-currency conversion is the answer, and a link to Meta's official documentation is shown.

The cost of each message, the number's estimated monthly service-message allowance and the reasons a message was free are in the WhatsApp cost center.

Use cases

Greetings in the unified inbox

When the unified inbox is active, private group welcome and farewell messages appear in the participant’s unified conversation. Delivery still uses the WhatsApp Web connection associated with the group. Greetings sent inside the group remain in the group conversation. Reusing a resolved conversation follows the unified inbox configuration.

• Cut out-of-window cost: reply after 24h via a WhatsApp Web session, not billed by Meta, instead of a paid template.
• Save the service allowance: in the platform's estimate, each delivered service reply over Cloud inside the window uses one unit of the estimated monthly allowance of 1,000 messages; above it, a cost is projected (inside an ad's free window the message is free; the documentation tracked here does not confirm whether it counts in that estimate). A reply over WhatsApp Web is not billed by Meta, because it does not go through the Cloud API. Replying over WhatsApp Web avoids service messages over Cloud: after the month's 1,000 in the estimate, each one avoided represents one projected charge less; before that, it represents estimated allowance saved. Actual savings depend on Meta's billing.
• Continuity: fallback allows one attempt through an eligible sibling after a definite failure; it does not guarantee delivery or automatically resend an attempt with an uncertain result.
• Groups, communities, channels and status: keep everything Coexistence does not cover working on the same number, through the Web inbox.
• WhatsApp Web calls: keep native WhatsApp Web calls working on the number, even with Coexistence active (see below).

Tips, limits & best practices

• The order is mandatory: Coexistence (Cloud) → Meta synchronization (~24h) → WhatsApp Web → pairing. Reversing it gets the Web inbox logged out the moment Coexistence is activated.
• Open the WhatsApp Business app at least once every ~14 days on the number's phone. Without that, Coexistence loses health and may stop syncing.
• Every hybrid call uses WhatsApp Web signaling and media, even when its bubble is attached to the Cloud conversation in single-inbox mode. Pairing does not change calling configuration.
• Outbound calls continue through Web. For inbound 1:1 calls, the dashboard can ring only when Meta/the gateway delivers a CallOffer to the companion device. On some Coexistence numbers Meta rings only the phone; no local retry can reconstruct an offer that never arrived.
• WhatsApp Web groups, communities, channels and status remain their own Web conversations.
• Do not remove Web bot, flow, automation or campaign bindings: groups, newsletters and Web-only features still need them. Pairing mirrors only what Cloud also needs.
• v1 runs in Cloud-primary mode (Coexistence is the authoritative receiver).

Troubleshooting

• The WhatsApp Web inbox went to "logged out" after activating Coexistence: this is the expected behavior — activation unlinks every companion device from WhatsApp Business. The Web inbox reports the cause (logged out from another device — the normal case here —, primary device was logged out, or unknown reason); in all three the fix is the same. Open the Web inbox, generate a new QR on its connection screen and pair again. Nothing is lost: phone number, conversations, contacts and history all stay on the same inbox; only the gateway session is rebuilt.

• The inbox says it paired but nothing arrives: the number may be stuck on a pending placeholder because another inbox already holds that number — in the same account (same provider) or in another account. The Híbrido tab and the pairing screen show the reason. Release or remove the inbox holding the number, then pair again.

• No inbox to pair: check the order — Coexistence (Cloud) first, Meta synchronization completed, and only then the WhatsApp Web inbox connected on the same number.

• Single-inbox activation stopped because of a configuration conflict: the platform now refuses on the click itself, with 422, naming which configuration conflicts between the Cloud and Web inboxes (assignment policy, routing, CSAT, bot, inbox integration, ads conversion, among others). Previously the request was accepted, queued, and only failed minutes later. Resolve the conflict on the named inbox and activate again.

• Single-inbox activation stopped because of Maestro state: having Maestro configured does not block activation. Before freezing any history, the platform tries to reconcile the Web conversation's control state onto the Cloud conversation that will take over, then reads it back. Only what genuinely did not move still blocks:

  • Resolves by itself, with no operator action: the human stand-down (the robot was told to stay quiet on that conversation), the specific Robot routed to that conversation (re-applied by name), and that conversation's autonomy (autopilot, copilot or hybrid set only there). All three are re-applied on the Cloud conversation and stop showing up as blockers.
  • Needs a decision from you: a pending human approval — an action parked waiting for someone to approve or reject it. It is not moved, because approving re-runs the parked action and re-running it against another conversation is not verifiable. The Web conversation is preserved exactly for this: open the conversation named on screen, approve or reject the pending item, and activate again.
  • The state could not be READ (Maestro unreachable or turned off): this is a communication failure, not control state. The message asks you to check Maestro connectivity; there is no point hunting for a pending approval, because the platform never managed to ask. The check stops at the first conversation, so the counter no longer repeats the same block dozens of times.

  When something still blocks, the screen names the exact conversations, with a link to open each one, and offers to activate anyway. That confirmation covers only the conversations listed at that moment — if a new blocker appears afterwards, it blocks again. There is no blanket override. On any block, both inboxes remain visible and no history in that batch is changed.

• Progress shows "0 · 0 · 0" while conversations are blocked: fixed. The progress line now has separate segments for frozen and linked, already linked, safely skipped and — highlighted — blocked, with how many conversations were checked. Blocked is not the same as safely skipped.

• This number already has another WhatsApp inbox: if the Web inbox comes up on a number that already has a Cloud inbox in the same account with no pair between them, the connection screen shows a notice. This is allowed, but both inboxes receive the same conversations independently and the history ends up split. The notice disappears on its own once you pair them on the Híbrido tab. It is a notice, not a block.

• The WhatsApp Web send failed with "WhatsApp shared only a business-scoped ID": Meta now identifies each user by a business-scoped ID (BSUID) and omits the phone number of anyone who hides it behind a username. The official channel (Cloud) can send to that ID; WhatsApp Web needs a phone number. Without a known number, the platform does not try WhatsApp Web: the message goes through the official channel when the 24-hour window is open, and the percentage split never picks Web for that contact either. As soon as the contact shares the phone number or messages with it, both channels work again.

• Reacting, editing, voting in a poll, answering an event or deleting for everyone was refused with "This message was sent through WhatsApp Web, which can no longer reach this contact": these actions must go out through the same channel as the original message. That message was delivered by WhatsApp Web, and the contact now has only a business-scoped ID (BSUID), without a phone number, which WhatsApp Web cannot reach. Nothing was sent to the contact. A delete for everyone becomes a delete on the platform only. The actions work again once the contact shares the phone number or messages with it.

• Duplicate message after a Web send: confirm the inboxes remain paired. Reconciliation uses the Web identifier embedded in the wamid; do not remove the transport stamp or recreate the message manually.

• The “This message is not supported” notice was not replaced: wait a few seconds and confirm the paired Web inbox is connected and received the same event. When Web does not deliver the decrypted copy or more than one candidate exists at the same instant, the notice stays in place to prevent a wrong match.

• The message remains in “processing content”: check the Web inbox connection and the media queue. The platform retries without firing automations on incomplete content; after the limit, it shows a content unavailable notice so the failure is not silent.

• Zero cost: sync runs periodically; use Sync now in the Cost section.

• An inbound call does not ring in the dashboard: check the Web connection/engine and CallOffer logs. If no offer reaches the gateway, the limitation is upstream and the call may ring only on the phone. An outbound call in the same session helps confirm that local Web signaling is healthy.

See also

• WhatsApp Cloud Coexistence
• WhatsApp Cloud with Embedded Signup
• WhatsApp Web
• WhatsApp Hub: groups, communities, channels and status