Why Your Business Number Cannot Make WhatsApp Groups.

If your plan involves a WhatsApp group for customers, the number it would run on decides whether the plan is possible at all.

Groups are not available for WhatsApp Business app phone numbers. They exist only through the Groups API, which is open to businesses with an Official Business Account on the Cloud API, and a group there holds a maximum of eight participants. Joining is by invite link only, and the Groups API uses per-message pricing.

That is usually where the community plan ends. Eight people in an invite-only thread, billed per message, is not a community channel. It is a small shared conversation with a business in it, and that is worth building only when a small shared conversation is what you actually want.

Start from the account type, not the feature

Most WhatsApp plans go wrong because they are written from the consumer app. Someone sits in six group chats on their personal phone, so a customer group feels like the obvious brand move.

A brand number is not a personal number. There are three different things called WhatsApp in a marketing meeting: the consumer app, the WhatsApp Business app, and the WhatsApp Business Platform running on the Cloud API. They have different feature sets, and groups are the sharpest example of the gap.

The broadcast surface a brand actually gets is a Channel, a separate product with its own rules, so it is worth being clear on what WhatsApp Channels are actually for before anyone spends a week designing a group.

What the WhatsApp Business app cannot do

Meta’s own documentation is blunt about it. Groups are not available for WhatsApp Business app phone numbers, and there is no setting, waiting list or workaround inside that app.

Numbers onboarded to Multi-solution Conversations are excluded as well. That one catches teams out, because it is a detail of how the number was set up rather than anything visible in daily use.

If nobody in the room knows which category your number sits in, ask whoever onboarded it before you plan anything around groups.

What the Groups API actually requires

Groups run through the Cloud API, on a business number that holds Official Business Account status. Your app needs the whatsapp_business_messaging permission for that number, plus a webhook server subscribed to the group lifecycle, participants, settings and status fields.

Official Business Account status is not a toggle. Meta’s stated criteria include being registered on the platform for at least thirty days, a business portfolio verified through Business Verification, two step verification enabled on the number, and an approved display name. Meta reviews the request and can deny it, and a denied number waits thirty days before it can reapply.

So “let us spin up a customer group this week” is really an account and engineering project that runs for weeks before a single message goes anywhere.

The limits, in one place

Meta publishes the constraints. Write them into the plan before anyone gets attached to the idea.

• Groups are not available for WhatsApp Business app phone numbers, or for numbers onboarded to Multi-solution Conversations.
• The Groups API requires an Official Business Account on the Cloud API.
• Maximum group participants: eight.
• Maximum groups you can create: 10,000 per business number.
• Maximum Cloud API businesses per group: one.
• Groups are invite-only, and the participant decides whether to join.
• The Groups API uses per-message pricing.
• Calling, disappearing messages, view-once, authentication, commerce and interactive messages are not supported.
• Message editing and deletion are not supported, and an admin cannot hide the participant list.
• Performance metrics are not available for message templates used in groups.

Eight participants is the number that ends most plans

Run the arithmetic the published caps imply. Ten thousand groups at eight participants each is a ceiling of eighty thousand people on one business number, which sounds generous until you notice it is also ten thousand separate threads.

Someone has to read those threads. Someone has to answer them, cover them at the weekend, and decide what happens when a customer posts a complaint in front of seven others.

A broadcast surface scales because one message reaches everyone. A group does not scale, because every group is a small room that needs staffing.

Invite-only changes who does the work

There is no endpoint that adds a participant to a group. The API creates a group, hands you an invite link, regenerates that link and removes people, but joining is the participant’s own decision, taken from the link.

The documented way to deliver the link is a template message carrying it. That means an approved template and a reason for each person to accept, one at a time.

Measurement then gets awkward, because performance metrics are not available for message templates used in groups. Meta also advises building separate templates for group use rather than repurposing your one to one ones, so the templates you already trust do not carry over.

Per-message pricing is a planning constraint

The Groups API uses per-message pricing. That is a billing fact about the messaging API rather than a case for buying reach, and it belongs in the plan for the same reason a shipping cost belongs in a product margin.

The documentation states the pricing model without spelling out how a message into a group of eight is counted, so model the expensive reading until your own invoices say otherwise.

Set that against a Channel, a Facebook page or an Instagram account, where publishing costs nothing per message. A daily post into a room of eight is a recurring line on a bill and a recurring job for a person, which is a strange place to put your organic effort. Working out which surfaces deserve that effort is exactly the trade we pick apart in workflow and ops consulting.

Channels is the broadcast surface

If the goal was reach, Channels is the product that matches the goal. WhatsApp describes it as a one way broadcast tool for admins to send text, photos, videos, stickers and polls, and followers cannot reply to updates.

The privacy model is the part brands underestimate. A channel admin’s phone number and profile photo are not shown to followers, and following a channel does not reveal a follower’s number to the admin or to anyone else following. Nobody is exposed to anybody, which is a large part of why people follow at all.

Two things to plan around. WhatsApp stores channel history on its servers for up to thirty days, so a Channel is a feed rather than an archive. And the WhatsApp Business Platform documentation covers messaging, templates and groups, not Channel publishing, so posting is a manual job for a named human.

The questions to answer before you build a group

1. Which number would this run on, and is it a Business app number or a Cloud API number?
2. Does that number hold Official Business Account status today, and if not, who owns getting it?
3. Is the goal reaching many people, or holding a real conversation with a few?
4. Who sends each invite, and who chases the people who never accept?
5. Who reads and replies in the thread, in which hours, and who covers weekends and holidays?
6. What happens the first time a customer complains in front of the other seven?
7. How will you judge whether it worked, given template metrics are not available in groups?
8. What is the wind down plan if the thread goes quiet or turns hostile?

If the first four have no owner’s name against them, the group is a slide, not a plan.

What good looks like

A brand that uses WhatsApp well tends to run three separate things and never confuses them. A Channel does the broadcasting. One to one messaging does service and sales. Groups, where they exist at all, are reserved for a small cohort where eight people in a room is the point rather than the ceiling.

Imagine a jeweller running a thread of eight repeat customers ahead of a private viewing, or a football club hosting a supporter panel of eight across a season. Both are sound uses of the feature. Neither is a community strategy.

The test is simple. If the value of the thread would drop when you added a ninth person, a group fits. If it would rise, you wanted a Channel.

How NBK thinks about messaging surfaces

Choosing a surface is a capacity question before it is a content question. Every messaging surface you open is a promise to reply, and the reply is the part nobody staffs, which is why who actually owns the social inbox decides whether the promise survives its second month.

We would rather a brand ran one messaging surface properly than three of them badly. The account type is the first thing we check, because a plan the account cannot execute is not a plan, it is a wish with a deadline on it.

Next step

If your social output feels busy but not effective, start with an NBK audit. Finding the constraint in the system is almost always quicker than bolting another channel on top of it.