Scoping the WhatsApp Groups API: OBA Gating, Eight-Seat Rooms and the Missing Moderation Layer

Most requests that reach a platform team about WhatsApp groups start from one assumption: surely there is an endpoint for this. Since Meta added a Groups API to the Cloud API, that is partly right. The work is figuring out which part, because the API serves a narrow use case and its boundaries come from identity and authorization rules, not throughput. Below it gets the usual dependency review: who may call it, what it controls, what it refuses to do.

Identity gating comes before any code

The first control is not technical. The Groups API only runs on Cloud API numbers that hold an Official Business Account (OBA). The 9bot breakdown of the Groups API, its limits and its alternatives lists the criteria Meta publishes for that status: following the WhatsApp Business Messaging Policy, a minimum of 30 days registered on the WhatsApp Business Platform, a business portfolio verified by Meta, two-step verification switched on for the number, and an approved display name. Employee numbers, test accounts and WhatsApp Business app numbers are not eligible, and a rejected request forces a 30 day wait before the next attempt.

As a security control this is sensible: every API group is tied to a verified business with 2FA on the sending number. For planning it is a blocker, since a team without OBA cannot even start a proof of concept.

The object model in one table

Limits as recorded from Meta's documentation on October 9, 2026:

Property Constraint Design implication
Participants per group 8 maximum Service rooms, not communities
Groups per number Up to 10,000 One group per ticket or account is feasible
Cloud API businesses per group 1 maximum A single integrator owns the room
Membership Invite link only, join requests optional No direct add, the user always opts in
Message types Text, media, text or media templates No buttons, lists, commerce or auth messages
Billing Per message Busy groups raise the bill
Unsupported Calls, disappearing and view-once messages, edit, delete, hiding the participant list No moderation primitives

The lifecycle is predictable: create the group with a subject and description, fetch or reset its invite link, deliver it (a template can carry it), handle join requests if enabled, then message, pin and consume webhook events. Teardown removes participants, changes settings or deletes the group. All of it assumes a Cloud API integration, a webhook receiver and someone on call.

Two layers, two permission models

The source article separates two layers, and the split belongs in your architecture diagram. The Meta layer (Cloud API plus Groups API) carries business messaging, pushes events to your server and enforces the limits above. The group operation layer covers routine work in large groups and communities tied to a number you control: join approvals, moderation, command replies and scheduled announcements.

Your WhatsApp groups are a business channel

The Groups API cannot serve that second layer: without delete, no process can pull a banned link or an abusive message. This is where 9bot works. 9bot is an independent paid tool with a 7-day trial, has no affiliation with Meta and does not use the Cloud API. It connects to a number that admins the groups through the linked devices feature, using a QR code or pairing code, and enforces rules there: anti link, strikes, removal, commands. When a command has to reach your back office, the pattern is a GET, POST or PUT call, covered in the guide to routing WhatsApp group commands into a CRM or ERP.

Operational risks for the runbook

Engineering conclusion: authorization picks the layer

Choose the layer by the privilege the workload needs. For a short lived service conversation between one business and a handful of people, the Groups API offers a verified identity, opt in membership and auditable webhook events. If you must delete content or remove members in groups of hundreds, the privilege required is group admin, and the API never grants it. The admin number then becomes a privileged account: 2FA on, a short list of people allowed to scan the pairing QR code, and periodic review of linked sessions. Three checks settle it: headcount above eight, OBA plus developers, a moderation requirement. Fail any and the work moves to the operation layer.