Last updated: August 10, 2026

Direct answer: WhatsApp coexistence is strongest when retaining an established number and continued Business app use matters more than maximum burst capacity. Its fixed Cloud API throughput is 20 messages per second. If sustained or latency-sensitive demand cannot fit within that limit after realistic traffic modeling, an API-only number deserves stronger consideration.

Meta calls the underlying capability WhatsApp Business app user onboarding and notes that partners sometimes call it Coexistence. This article uses API-only as editorial shorthand for a number connected to Cloud API without simultaneous WhatsApp Business app use. API-only is not the name of a Meta product tier.

This is a buyer decision guide, not another setup tutorial. For eligibility, Embedded Signup, synchronization, linked devices, testing, reconnection, and offboarding, use CampaignHQ’s existing-number coexistence implementation guide. For CampaignHQ capabilities, see the CampaignHQ WhatsApp coexistence page.

WhatsApp coexistence vs API-only in one decision

Coexistence preserves one customer-facing number and supported Business app use while adding Cloud API workflows. The trade-off is a fixed throughput ceiling and a hybrid operating model. API-only gives up simultaneous Business app use on that number, but can provide a path to higher throughput and a more centralized messaging operation.

Neither option is automatically more scalable. A company can have a large contact list and still fit coexistence if campaigns are paced and completion time is flexible. A smaller company can outgrow 20 mps if it sends urgent notifications, experiences sharp reply spikes, or promises a strict completion time.

The decision therefore depends on six inputs:

• Measured per-second API demand, not only monthly volume.
• Inbound response traffic and normal transactional traffic.
• The acceptable completion time for campaigns and notifications.
• The economic value of retaining the established number.
• The frontline team’s real dependence on the Business app.
• The expected operating model 12 months from now.

What the fixed 20 mps limit actually means

Meta’s Business app user onboarding documentation says a phone number used with both the WhatsApp Business app and Cloud API has a fixed throughput of 20 mps. Meta’s Cloud API throughput documentation says registered numbers support up to 80 mps by default and can be automatically upgraded to up to 1,000 mps after meeting stated conditions.

Meta defines Cloud API throughput as inclusive of inbound and outbound messages and all message types. The primary documentation reviewed does not explicitly state whether Business app sends represented through message-echo webhooks count against the coexistence number’s Cloud API throughput. Confirm that accounting with Meta or the provider before final capacity planning.

If API traffic exceeds the permitted throughput, Meta returns error 130429 until traffic falls within the allowed rate. A provider may queue and retry affected sends, but that is provider behavior rather than a guaranteed Meta-managed queue. Buyers should therefore ask how the provider handles rate errors, retry timing, queue depth, duplicate prevention, and completion reporting.

Translate 20 mps into a completion-time question

At the throughput layer, 20 mps equals 1,200 messages per minute or 72,000 messages per hour if the rate could be sustained continuously. These are arithmetic reference points, not campaign promises. Incoming Cloud API messages, other outbound workflows, retries, templates, consent rules, quality controls, pricing, and business-portfolio limits still matter.

For example, a 60,000-message outbound job would require at least 50 minutes at a full 20 mps before allowing for response traffic, other workloads, provider controls, retries, or delivery variation. If the business accepts a two-hour completion window, coexistence may still fit. If the same job must complete in ten minutes, it does not fit the raw 20 mps ceiling.

Averages can hide the risk. One-minute and five-minute rates are useful context, but a per-second ceiling requires per-second observations or a realistic load simulation. Measure or simulate API send demand, inbound response traffic, provider queue depth, completion latency, and error behavior during a representative peak.

Understand the 1,000 mps comparison before using it

The 1,000 mps figure is not an automatic outcome of choosing API-only. Meta currently requires the business portfolio to have an unlimited messaging limit, the number to message at least 100,000 unique users outside customer service windows within a moving 24-hour period, and the phone-number quality rating to be medium or higher. Meta also notes that the initial throughput upgrade can make the number unavailable for up to one minute. Higher throughput itself has no additional charge, while messages still follow current platform pricing.

This means the realistic comparison is often 20 mps coexistence versus up to 80 mps on a standard Cloud API number first. The 1,000 mps path matters for businesses that can meet the eligibility conditions and genuinely need that level of throughput.

WhatsApp coexistence pros for a scaling business

The advantages are concentrated around continuity and adoption rather than maximum capacity.

• Retain a trusted number: the business can preserve a number already printed on packaging, invoices, storefronts, ads, profiles, and support pages.
• Keep supported app conversations: relationship managers, owners, and field teams can continue supported one-to-one work in the Business app while API workflows are introduced.
• Reduce change at the customer edge: customers do not have to learn a second number at the start of the API rollout.
• Adopt in phases: the organization can introduce a shared platform, templates, integrations, and governance without forcing every frontline role into a new workflow immediately.
• Preserve optionality during learning: the business can learn its real API traffic, reply pattern, and app dependency before deciding whether a more centralized model is justified.

These benefits can be commercially significant. If the existing number is a major inbound acquisition and support asset, replacing it may create customer confusion, missed enquiries, fraud concerns, and additional campaign work. That value should be estimated rather than treated as an emotional preference.

WhatsApp coexistence cons for a scaling business

The disadvantages are concentrated around burst capacity and the complexity of running two operating surfaces.

• Fixed Cloud API throughput: the coexistence number stays at 20 mps rather than following the standard higher-throughput path.
• Potential completion delays: sustained or sharp API demand can trigger error 130429. Provider queueing and retry quality then affect completion time.
• More operating rules: app users, shared-inbox agents, and automations need clear ownership so customers do not receive conflicting replies.
• App workflow changes: some Business app features and device behaviors change after onboarding. Review those details in the implementation guide before committing.
• More recovery planning: device changes or app re-registration can interrupt the Cloud API companion and require operational recovery.
• A future transition is not guaranteed to be simple: Meta documents coexistence offboarding, but the cited documentation does not promise a same-number conversion from coexistence to an API-only configuration.

The limitation list above is intentionally short. Detailed synchronization, companion-device, chat-feature, pricing-window, and offboarding mechanics belong to the technical coexistence guide. Buyers should use this page to decide whether those details justify deeper implementation review.

When coexistence is usually the stronger choice

Coexistence deserves stronger consideration when most of these conditions are true:

• The existing number generates meaningful inbound enquiries or has strong offline visibility.
• Frontline roles have a genuine need to continue Business app conversations.
• Measured or simulated API demand fits under 20 mps with operating headroom.
• Campaign and notification completion windows are flexible enough for provider pacing.
• The organization wants to phase in centralized API workflows.
• The business accepts the documented app and device trade-offs.
• There is a named owner for app behavior, API operations, provider queueing, and recovery.

Do not plan directly against the 20 mps ceiling. Set headroom from measured traffic variability, expected replies, retry behavior, campaign-completion targets, and provider queue performance. A useful headroom target is specific to the operation and service-level objective. It is not a fixed Meta percentage.

When API-only deserves stronger consideration

An API-only model deserves stronger consideration when several of these conditions apply, or when one condition is non-negotiable:

• Sustained or latency-sensitive demand cannot fit within 20 mps after realistic queueing and response traffic are modeled.
• Campaigns or notifications have strict completion-time requirements.
• The business needs a path toward the standard 80 mps throughput and can potentially satisfy Meta’s 1,000 mps eligibility conditions later.
• All customer-facing work is ready to move into a centralized inbox, CRM, or service workflow.
• Simultaneous Business app use is not an operational requirement.
• A dedicated API number can be introduced without unacceptable customer confusion.
• Hybrid ownership and device-recovery requirements would create more risk than value.

A short spike above 20 mps does not automatically require API-only. A capable provider may smooth the job through queueing when the completion window permits it. The stronger trigger is sustained demand or a latency requirement that cannot tolerate that smoothing.

Five numbers to collect before deciding

1. Peak per-second API demand

Capture the highest per-second send and receive rates during campaigns, order peaks, service incidents, and seasonal events. If the provider only supplies minute-level reports, run a controlled load test and inspect queue and error data.

2. Normal transactional baseline

Promotional campaigns do not run in isolation. Order updates, reminders, authentication, service notifications, and support replies can consume Cloud API capacity at the same time. Model the baseline that must continue while a campaign is active.

3. Expected reply rate

Estimate how many people will reply and how quickly. A campaign designed to start conversations has a different capacity profile from a one-way notification. Include the inbound response load and the outbound replies or automations that follow.

4. Required completion window

Replace vague requirements such as “send quickly” with a measurable window. Decide whether a job must complete in five minutes, thirty minutes, two hours, or by the end of the day. Throughput becomes a business constraint only in relation to that requirement.

5. Twelve-month growth case

Model the expected contact base, campaign frequency, notification volume, response rate, and critical seasonal peak for the next year. Coexistence may fit today’s workload but create another operating change shortly after onboarding. Conversely, a speculative future volume should not force a disruptive number change before there is evidence.

Three illustrative decision scenarios

Scenario 1: An established service number with modest automation

A regional service company receives enquiries on one number printed across branches and invoices. Relationship managers rely on the app, while reminders and follow-ups run at modest API volume. The established number is commercially valuable and the measured peak remains comfortably below 20 mps. Coexistence is likely the stronger starting model.

Scenario 2: A growing D2C retention program

A brand has a large opted-in audience and launches promotions that create immediate replies. The raw job can fit under 20 mps only if it is paced over a longer window. If the business accepts that window and still values app-based work, coexistence may fit. If promotions must complete much faster, API-only deserves stronger consideration.

Scenario 3: Latency-sensitive operational notifications

A business sends urgent delivery, payment, authentication, or disruption updates. The important requirement is not monthly volume but the number of messages that must complete within a few minutes. If sustained demand and the completion target cannot fit under 20 mps, the architecture should prioritize API-only throughput and centralized control.

A coexistence vs API-only decision scorecard

Ask marketing, operations, support, and technology owners to answer these questions with evidence:

1. What revenue, support, or acquisition value is attached to the existing number?
2. Which frontline roles require the Business app, and why?
3. What is the measured peak per-second API demand?
4. What inbound response load follows a typical campaign?
5. Which transactional workloads must continue during campaign peaks?
6. What is the acceptable completion time for each workload?
7. How does the provider handle error 130429, queueing, retries, and duplicate prevention?
8. What headroom is required by the business’s service-level objective?
9. Will the 12-month growth case still fit the model?
10. Can a dedicated API number be introduced without harming trust or discoverability?
11. Is the organization ready to centralize customer replies?
12. What is the approved recovery and future-transition plan?

Use the WhatsApp Business Platform provider and setup guide to evaluate provider readiness. Use the current WhatsApp Business pricing update to keep capacity planning separate from message costs.

WhatsApp coexistence feature reality at a glance

WhatsApp coexistence connects one existing WhatsApp Business app number to Cloud API while preserving supported app use. Meta’s current feature comparison says individual 1:1 messages can be mirrored and up to six months of 1:1 history can be synchronized. Contacts with WhatsApp numbers can also be synchronized. Group chats remain usable in the Business app but are not synchronized to Cloud API. Disappearing messages are turned off for individual chats, and view-once messages are disabled after onboarding.

This is why “keep the app and add the API” is directionally correct but incomplete. The decision also changes feature behavior, device responsibilities, message ownership, throughput, and recovery. Use the existing-number setup and limits guide for the full implementation sequence; use the pilot below to decide whether the operating model works for your team.

What a real coexistence pilot should prove

A recent r/WhatsappBusinessAPI discussion about coexistence surfaced practical questions about device inactivity, chat-history synchronization, human and bot ownership, customer service windows, and template operations across multiple numbers. Community comments are useful for finding failure modes, but they are not product specifications. Use them as a pilot checklist, then verify each result against Meta’s current onboarding documentation and the provider’s observed logs.

1. Keep the primary app active and monitor disconnection reasons

Meta documents PRIMARY_INACTIVITY when the primary device has been inactive for approximately 14 days and COMPANION_INACTIVITY when a companion device has been inactive for approximately 30 days. Device re-registration, a number change, an account change, or switching back to the consumer app can also interrupt the relationship. This turns the community’s “14-day cutoff” question into a concrete operating requirement: assign an owner for the primary phone, keep it connected, monitor account-update webhooks, and maintain a tested reconnection runbook.

2. Complete history synchronization inside the onboarding window

Meta says the provider has 24 hours after onboarding to synchronize messaging history. The available history can include individual messages from the previous 180 days, while media asset IDs are available only for media sent within the previous 14 days. Before activation, decide whether history will be shared, who verifies it, and what “complete” means. Test the oldest expected conversation, recent media, contact synchronization, and the provider’s handling of delayed or duplicate history webhooks.

3. Separate Business app rules from Cloud API rules

The thread also exposed confusion about the 24-hour customer service window. Meta’s documentation distinguishes the two surfaces: Cloud API messages follow the customer service window and approved-template rules, while messages sent from the WhatsApp Business app are not subject to that window and do not create, extend, or affect Cloud API customer service windows or Cloud API pricing. The pilot should test app replies, API template sends, and API free-form replies as separate cases rather than assuming one surface changes the other.

4. Prove the human-to-automation handoff

Messages can be mirrored between the Business app and the Cloud API, but ownership logic is still an application and provider responsibility. Test what happens when an agent replies from the phone while a bot, journey, or shared-inbox automation is active. The acceptance rule should be explicit: the human action pauses or reroutes automation, the conversation has one visible owner, duplicate replies are prevented, and the audit trail shows whether the app, API, or automation sent each message.

5. Test the real multi-number and template operating model

Practitioners in the thread reported different experiences with WABA structure and template management. Do not generalize from either report. Ask the provider to demonstrate where each coexistence number is onboarded, who owns the WABA and credit line, how templates are created and approved, whether templates must be duplicated, and how naming and reporting work across numbers. Pilot with a small representative set before onboarding a large field or sales team.

Coexistence pilot exit criteria

• No unexplained device or partner disconnections during the test window.
• History and contacts synchronize within the agreed acceptance window.
• Human app replies pause or redirect automation without duplicate responses.
• Template and customer-service-window behavior matches the documented app/API split.
• Multiple numbers, WABA ownership, template administration, and reporting are operationally manageable.
• Peak API traffic, inbound replies, provider queues, and error 130429 stay within the approved completion-time objective.
• A device-change and reconnection drill succeeds without relying on an undocumented same-number transition.

If the pilot cannot pass these checks, the issue is not merely “coexistence versus API-only.” It is an operating-model gap that should be resolved before scaling. Keep the detailed onboarding sequence in the existing-number setup and limits guide, and use this page to make the architecture decision.

Do not confuse throughput with permission to message

Throughput describes how quickly the API can process messages. It does not override consent, templates, quality controls, current pricing, WhatsApp Business account rate limits, business-portfolio template messaging limits, or customer service windows.

Outside an open customer service window, Cloud API business-initiated messages require approved templates. Within an open window, supported non-template messages may be sent under Meta’s rules. Sending faster does not repair poor consent, weak targeting, duplicate automation, or unresolved support ownership.

The scaling decision must therefore combine capacity, customer permission, operating controls, and the value of the existing number.

Implementation facts to verify after the decision

If coexistence wins the decision, the technical owner still needs to verify eligibility, Embedded Signup v4 readiness, the 24-hour synchronization requirement, 180-day individual-message history limit, 14-day historical media asset window, linked-device behavior, feature changes, reconnection conditions, and offboarding. Meta says Embedded Signup v2 will be deprecated on October 15, 2026, so providers should be ready for version 4.

Those are implementation checks, not reasons to recreate the buyer decision here. CampaignHQ’s existing-number setup and limits guide contains the operational detail.

How CampaignHQ approaches the choice

CampaignHQ is a Meta Tech Partner and an Email plus WhatsApp customer retention platform built on AWS. A readiness review starts with measured API peaks, completion-time requirements, response behavior, app-dependent roles, number value, and the 12-month growth case.

The result should be one of three documented choices:

• Coexistence: the existing number and app workflow justify the fixed 20 mps ceiling.
• API-only: centralized control or sustained and latency-sensitive demand makes simultaneous app use less valuable.
• Phased plan: coexistence is used initially, with a provider-validated future architecture and explicit review trigger. The same-number transition must not be assumed.

Frequently asked questions

Is 20 mps enough for a scaling business?

It can be. Model per-second API demand, inbound responses, normal transactional traffic, provider queueing, and the required completion window. Coexistence can fit a large audience when jobs are paced, while a smaller latency-sensitive operation may require a different architecture.

Do Business app messages count against the coexistence throughput limit?

Meta says Cloud API throughput includes inbound and outbound messages and all message types, but the primary documentation reviewed does not explicitly state whether Business app sends represented by message-echo webhooks consume that capacity. Confirm the accounting with Meta or the provider.

What happens when Cloud API traffic exceeds 20 mps?

Meta returns error 130429 until traffic falls within the allowed throughput. A provider may queue and retry affected sends, but queueing behavior and completion time depend on the provider’s implementation rather than a guaranteed Meta-managed queue.

When is an API-only number safer than coexistence?

API-only deserves stronger consideration when sustained or latency-sensitive demand cannot fit under 20 mps after realistic queueing and response traffic are modeled, or when centralized control is non-negotiable and simultaneous Business app use adds little operational value.

Can a business move from coexistence to API-only on the same number?

A phased plan may be possible, but the cited Meta documentation establishes the coexistence offboarding method, not a guaranteed same-number conversion to API-only. Confirm the intended number, account state, and onboarding sequence with the provider before starting.

Official Meta sources

• Onboard WhatsApp Business app users
• WhatsApp Cloud API throughput
• Embedded Signup version 4
• Reconnect offboarded coexistence clients
• Current WhatsApp Business Platform pricing

Written by CampaignHQ Team