Grok Bot + WhatsApp: setup and first reply workflow

What this guide verifies

We checked the linked provider documentation on 5 September 2026. The examples below are synthetic inputs and expected outputs, not results from a connected WhatsApp account. We have not verified a native WhatsApp plugin in Grok Bot or an end-to-end message delivery.

Before you connect

Choose one job: classify an incoming request and prepare a reply that a person can approve. Keep booking changes, refunds, and outbound messaging outside the first task.

Requirement	What to establish
Business identity	The company controls the WhatsApp Business account and number.
Source	An approved provider or connection exposes the incoming conversation and its timestamp.
Reply rules	You have the customer's permission where required, an opt-out process, and the applicable reply window.
Review	A named business role can check the answer and handle escalation.

Meta publishes a WhatsApp Cloud API collection and integration examples. These establish the platform's API route; they do not establish a ready-made Grok Bot connector.

Choose the connection actually available

In Grok Bot, check Plugins for a suitable connection. If it is listed, review its permissions and provider authorization, then confirm it appears under Installed. This is the documented generic plugin process, not a promise that WhatsApp is listed.
If your business already has a WhatsApp provider, confirm how an authorized integration reads its incoming queue. Verify incoming access separately from permission to send messages.
If neither route is available, test the task with a supplied conversation first. A successful sample does not mean the live account is connected.

If a supported route needs a credential, use Grok Bot's secure secret entry. Do not put tokens in ordinary chat or a knowledge file.

Check the reply window

The WhatsApp Business Messaging Policy allows free-form replies within 24 hours of the customer's last message. Outside that window, use an approved message template. Consent, opt-out handling, and escalation still apply. A drafted reply is not permission to send it.

First task to give the Bot

Use only the supplied conversation, business policy, and test clock.
Return: message ID, request type, source facts, missing information,
reply-window status, an unsent reply, and the role that must review it.
If the reply window is closed, flag that an approved template is needed.
Do not invent a template name or assume template approval.
Do not send a message, change a record, connect an account, or add a routine.
Escalate billing disputes and anything the supplied policy does not answer.

Worked example: booking question

Illustrative input: message M-021 says, “Has my repair been booked?” The last customer message was 5 September at 09:00 UTC; the test clock is 11:00 UTC that day. Record B-021 says “request received” but contains no appointment time. The supplied policy says only the scheduling owner can confirm appointments.

Expected output:

M-021 | Booking question | Source: B-021
Reply window: open, 2 hours since the last customer message.
Known: the request was received.
Missing: confirmed appointment date and time.
Unsent draft: "Your repair request has been received. I'll ask our
scheduling team to confirm the appointment time."
Reviewer: scheduling owner. Status: approval required.

Run two failure cases: move the test clock to 6 September at 11:00 UTC and expect a template-required flag; remove B-021 and expect a missing-source warning. Neither case should produce a confirmed appointment.

For a connected pilot, separately check that the provider returns the correct message ID and timestamp. Keep the first pilot unsent. Continue with the inbox triage workflow or fill in the free First Grok Bot Workflow Check.