Last updated: August 4, 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.

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