## 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

| Surface                                                | Coexistence (Cloud) | WhatsApp Web                                              |
| ------------------------------------------------------ | ------------------- | --------------------------------------------------------- |
| 1:1 conversations                                      | Yes (authoritative) | Send / fallback and recovery of Cloud-unsupported content |
| Templates, interactive, flows, catalog                 | Yes                 | No                                                        |
| Groups, communities, channels, status, broadcast lists | No                  | Yes                                                       |
| Native WhatsApp Web calls                              | No                  | Yes                                                       |

### 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](/hc/ajuda/articles/reports-whatsapp-cost-center-en).

## 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](/hc/ajuda/articles/inboxes-channels-whatsapp-coexistence-en)
- [WhatsApp Cloud with Embedded Signup](/hc/ajuda/articles/inboxes-channels-whatsapp-cloud-embedded-signup-en)
- [WhatsApp Web](/hc/ajuda/articles/inboxes-channels-whatsapp-web-wazmeow-en)
- [WhatsApp Hub: groups, communities, channels and status](/hc/ajuda/articles/inboxes-channels-whatsapp-hub-grupos-comunidades-canais-status-en)