WhatsApp as an input — what is actually possible
Two asks, and they are technically very different problems. Researched 20 Aug 2026.
What the official API can and cannot do
Meta opened a Groups API on the WhatsApp Business Platform in 2026. The limits decide everything below:
| Max participants | 8 |
| Groups per number | 10,000 |
| Operating businesses | 1 Cloud API business per group |
| Eligibility | Official Business Account; not WhatsApp Business *app* numbers |
| Inbound | Yes — group messages arrive on webhook |
| Existing groups | No — the API operates groups it creates, not ones a person made on a phone |
That last row is the whole story. It makes ask one easy and ask two hard.
Ask 1 — the content research group (do this)
A dedicated group the API creates and operates. The team drops links or screenshots in; a webhook receives them; the portal files them into the content library.
Fits inside every limit: 8 participants is more than Atlas has, the group is ours to create, and inbound media is supported. No terms-of-service risk, no third party, no unofficial client.
Pipeline once a message lands:
- A link → fetch, tag through
content-tagging, store with the sender and the group as source - A screenshot → vision extraction first (what platform, what brand, what the creative does), then the same tagging path
- Neither → keep it, tag it
unsorted, let a human look; never drop a teammate's input
The lazy path Alex asked for stays lazy: forward, and it is filed.
Prerequisite: an Official Business Account and a phone number that is *not* the WhatsApp Business app number the team already uses.
Ask 2 — the client groups (harder, and worth being honest about)
Client groups already exist. People made them on phones, they usually hold more than 8, and Atlas would be joining as a participant rather than operating them. The official API cannot read them. Anything that does is one of:
| Route | What it is | Cost of being wrong |
|---|---|---|
| Unofficial bridge (Baileys, whatsapp-web.js) | Logs in as a linked device on a real account | Against WhatsApp's terms; account bans are real and documented |
| Managed provider (Periskope, Whapi, Maytapi, Wassenger) | The same protocol, operated by someone else, with an API and a support contract | Same underlying risk, carried by a vendor; ~$20–100/month |
| Ask the AM to forward | A human forwards what matters to the research number | Free and compliant; depends on someone remembering |
Recommendation if we do this: a dedicated number that exists only for this — never an AM's number, never the main business line. A ban then costs a SIM, not the agency's WhatsApp presence. Add it to client groups as "Atlas Assistant", visible to the client, and say what it is in the service agreement. Reading a client's group without telling them is not a technical question.
Recommendation for now: ship ask 1, which is clean, and let it prove the ingestion path. Revisit ask 2 once we know how much the research inbox is actually used.
What this feeds
Both routes end in the same place: the client dossier. The dossier's value is that everything known about a client sits together — meeting notes, ad and social performance, what was decided and why, what has been paid — so planning is pinpoint rather than recalled. Group chatter is one more source, and like every source it arrives with a provenance stamp saying where it came from and who said it.
Sources: Meta Groups API · Group messaging