QA Meta WhatsApp MCP Sends With HubSpot Consent Before They Go Live

On September 15, 2026, Meta announced WhatsApp Business Tools MCP, a server that lets AI coding agents work inside the WhatsApp Business Platform setup flow. TechCrunch reported that agents like Claude, Cursor, Codex, and ChatGPT can help create WhatsApp Business accounts, verify phone numbers, register for Cloud API access, manage templates, test webhooks, and check items like Terms of Service and Business Verification.

That saves time. It also makes one mistake easier to ship at scale.

The useful how-to is not asking an agent to create a template. The useful how-to is putting that agent behind HubSpot consent checks, template-status logging, and a manual approval step before any lifecycle workflow can send a WhatsApp message. I would treat this like a release gate, because for marketing operators the blast radius is not theoretical. One bad enrollment rule can message 4,000 people who never opted into WhatsApp.

Start With The System Of Record

HubSpot should own contact eligibility. Meta should own WhatsApp account and template state. The AI agent can fetch and compare both, but it should not decide that a contact is probably fine to message.

HubSpot’s own WhatsApp template documentation, updated September 3, 2026, says contacts must provide verifiable opt-in consent before WhatsApp messages are sent via contact-based or conversation-based workflows. It also says templates created in Meta sync into HubSpot and can be sent from contact records, the conversations inbox, help desk, or workflows once configured. That is the operating line I would use.

Create explicit contact properties before the first campaign. I use fields like whatsapp_marketing_opt_in, whatsapp_opt_in_date, whatsapp_opt_in_source, whatsapp_opt_in_text, whatsapp_phone_normalized, whatsapp_suppressed, and whatsapp_suppression_reason. The text field is dull until someone asks what the March 2026 pricing-page form actually said. Store the disclosure shown at signup, not a vague note from a rep.

HubSpot’s Subscription Preferences V3 API documentation says that API handles email subscription types and does not currently retrieve or update WhatsApp subscription information for a contact. So do not assume your existing email preference center covers WhatsApp cleanly. If you use HubSpot’s native WhatsApp integration, check its subscription behavior in your portal. If you use a custom Cloud API sender, keep your own WhatsApp consent fields tight and auditable.

Build One List Per Send

I would not run WhatsApp sends from a giant master list called WhatsApp OK. Make one active list per campaign. A real name might be WA - Trial Started - Day 2 - US - Sep 2026. Its filters should include lifecycle stage, country, normalized phone, opt-in boolean, opt-in timestamp, opt-in source, and suppression status.

For most founder-led teams, I also block anyone who is globally unsubscribed from marketing email. That is stricter than a narrow channel-by-channel reading in some cases, but it matches customer intent better. If Elena told your company to stop marketing to her on August 29, 2026, sending her a WhatsApp promo on September 2 because the field name is different is a bad call.

A list is still only a starting point. HubSpot filters drift. Someone adds an OR group before a webinar push. A CSV from Web Summit gets imported with the wrong source. A sales ops teammate creates whatsapp_opt_in while marketing automation uses whatsapp_marketing_opt_in. The QA agent should inspect records, not just trust the list label.

Check Meta Template State At Send Time

Meta templates are not static files. They have names, languages, categories, statuses, and review states. The WhatsApp Business Management API exposes templates from the /{waba-id}/message_templates edge, and public examples show fields like name, language, status, category, and id in the response. Meta’s status webhooks also report events such as APPROVED, REJECTED, PAUSED, and DISABLED.

That means your QA step should ask Meta for the current template state during the campaign review, not rely on a spreadsheet note from yesterday. If trial_activation_day_2_v1 was approved at 9:10 a.m. UTC but paused after negative feedback at 4:30 p.m., a 5:00 p.m. lifecycle send should stop.

I log one row for every template check. In HubSpot, that can be a custom object called WhatsApp Template QA. In a more technical stack, use Postgres or BigQuery. The fields I want are campaign key, HubSpot list ID, WABA ID, template ID, template name, language, category, status, check timestamp, checked-by identity, and a SHA-256 hash of the template body the agent saw.

The hash catches quiet edits. If the template body changes after approval, the send approval should no longer match. Force another QA run. This is the same logic you would use for a paid landing page where the legal disclaimer changed after media went live.

Give The Agent A Narrow Job

The MCP-assisted agent should gather evidence and write QA records. It should not have send permission.

For a basic campaign, I want the agent to confirm that the selected template exists in the expected WABA, that the language matches the campaign brief, that the template is approved or active according to the current Meta state, and that the HubSpot list contains only contacts with explicit WhatsApp opt-in and no suppression flag. Then it should sample contacts and write a plain result.

Sampling is not a substitute for a real eligibility query on a high-volume send. For lists under 5,000 contacts, I usually sample 25 to 100 records. For a paid-lead nurture with 80,000 contacts, inspect every row through an export or synced warehouse table. Two minutes of counting is cheap. Explaining a bad send to 1,700 suppressed leads is not.

A passing QA note can be short. For example: PASS. HubSpot list 128734 contains 3,842 contacts. Sampled 100. All sampled contacts have whatsapp_marketing_opt_in=true, opt-in timestamp, opt-in source, E.164 phone, and no suppression flag. Meta template trial_activation_day_2_v1 en_US is APPROVED as of 2026-09-21T18:12:44Z.

A failing note should be blunt too. Example: FAIL. Sampled 100 contacts from list 128734. 7 have whatsapp_marketing_opt_in=false. 3 have whatsapp_suppressed=true. Template is approved, but audience is not eligible. Nobody needs a paragraph of agent prose when the send is blocked.

Add A Manual Approval Object

I like a HubSpot custom object called WhatsApp Send Approval. It should store the campaign key, owner, HubSpot list ID, eligible count, suppressed count, missing-consent count, Meta template ID, template hash, QA timestamp, approver email, approval timestamp, and approval status.

The lifecycle workflow should require that object before enrollment. In HubSpot terms, the workflow should only enroll contacts when whatsapp_send_approval_status is approved, approval_timestamp is within the last 24 hours, and template_body_hash equals the latest QA hash. If the planned send slips from Monday to Wednesday, rerun QA. Paid campaigns, demo forms, and product signups keep feeding the CRM while everyone is asleep.

This is where a lot of teams get too clever. They let the agent approve because it found no issues. I would not. AI can read faster than a person, but approval is accountability. A founder, lifecycle marketer, or ops lead should press the final button.

Block The Weird Cases

A few checks are worth adding even if they feel fussy on day one.

Block contacts with missing opt-in source. A true boolean with no source is not enough for WhatsApp marketing in 2026. Block contacts whose phone country disagrees with the campaign market. If a US trial cohort has 6 percent of sampled numbers starting with +44, stop and inspect. Maybe those are legitimate UK users in a US segment. Maybe enrichment copied company headquarters into a person record. Either way, do not guess.

Block contacts with support escalations from the last 30 days. I usually add manual_hold or support_escalation as suppression reasons because some contacts are technically opted in but should not receive lifecycle nudges right after a refund request.

Block templates that were edited after QA. Block templates with PENDING, REJECTED, PAUSED, DISABLED, ARCHIVED, or DELETED states. Approved means approved now, in the correct WABA and language, for the exact template you plan to send.

A Practical V1 Stack

A small team can build this with HubSpot Marketing Hub Professional or Enterprise workflows, a HubSpot custom object, Meta’s WhatsApp Business Tools MCP, one serverless function, and a private Slack channel. Keep the agent prompt in a versioned repo if engineering is involved. If there is no repo, lock it in Notion with an owner and a changelog.

The first version does not need a warehouse, Airflow, or a polished internal app. It needs a field map, a QA run, a log, and a human approval record. I would rather see a boring 200-line function with clear checks than a beautiful automation that lets a prompt rewrite the rules at 5:40 p.m. before a launch.

Use boring names too. wa_trial_day2_2026_09 is better than activation blast. Two months later, when someone compares Meta template logs, HubSpot list membership, Slack approvals, and unsubscribes, boring names pay rent.

The Operating Rule

Meta’s September 2026 MCP release makes WhatsApp Business setup less painful. That is good for operators who already bounce between Business Manager, HubSpot, docs, and a half-finished campaign brief. It does not replace consent design.

My rule is simple. Let the agent speed up setup, fetch template status, inspect HubSpot fields, and write the QA record. Keep contact eligibility in HubSpot. Keep template truth in Meta. Keep final approval with a person who owns the campaign.

WhatsApp sits closer to the customer than email. Treat that closeness as a constraint, not a growth hack.