Skip to main content
The webchat is a channel like the others: each company webchat has a channelId (see GET /webchat or GET /channels) and its conversations land in the inbox. Through the API you do two things with it:

Talk to the visitor

The company sends messages to whoever is on the webchat, with POST /messages, including interactive messages. messages module.

Be the visitor

Your system opens a session for one of your users, sends their messages and reads the team’s replies. webchat module.

Send to a visitor

A webchat visitor does not need a phone number, so the recipient is the ticketId of a conversation or the contactId of someone who has already opened this webchat:
A contact who has never opened this webchat gets 422 ERR_API_CONTACT_UNREACHABLE. The rest of the send works like the other channels: 202 with a jobId, and the job lookup at GET /messages/jobs/{jobId}. See Send messages.
The webchat does not use templates. type: template only applies to official WhatsApp channels.

Interactive messages

The webchat shows the visitor the same interactive messages as the official WhatsApp API, with the same interactive object: the payload you already send to official WhatsApp works on the webchat with no changes. Only the channelId and the recipient change. flow, product, product_list, catalog_message, address_message, voice_call and call_permission_request depend on Meta resources and do not exist on the webchat.
On the webchat, interactive is checked during the call itself, with the WhatsApp limits (3 buttons, 10 rows, 20- or 24-character titles and the others, listed in the interactive field of POST /messages). Outside them, the response is a 422 right away, with the field and the reason in message:
Header and card media only by a public http or https link. The webchat does not use media uploaded to Meta (id).

The visitor’s reply

The choice arrives as it does on WhatsApp: a text message from the visitor with the option title, replying to (quoting) the interactive message. A location arrives like a WhatsApp location, with mediaType: locationMessage. If you follow the conversation with GET /tickets/{ticketId}/messages, nothing changes compared to WhatsApp.

Chat as the visitor

With the webchat module, your system plays the visitor’s part: for example, your own app that shows the support conversation inside it.
1

Open the session

Use the webchat slug (from GET /webchat). With externalId, the same person always returns to the same session and the same contact.
Keep the session.id. The response also includes a visitorToken, which your front end uses to receive messages in real time (/webchat, Socket.IO, auth: { token }) without exposing the API token.
2

Send the visitor's messages

The first message opens the ticket in the webchat queue. A file goes as multipart/form-data, in the media field.
3

Read the replies

Without real time, poll with after set to the createdAt of the last message received:
Mark messages as read with POST /webchat/{slug}/sessions/{sessionId}/read and close the session with POST /webchat/{slug}/sessions/{sessionId}/close.

Reply to an interactive message

In the company’s interactive messages, interactive has what to render (type, header, body, footer and the options) and options lists the reply options with id and title. To choose one, send the message id and the option id:
The saved title comes from the message itself: there is no need, and no way, to send a different one. An option that is not in the message gets 422 ERR_WEBCHAT_INTERACTIVE_REPLY_INVALID. For a location request (interactive.type: location_request), send the coordinates, quoting the request:
Any message can reply to another one with quotedMessageId.

Send messages

The four send types, the jobId and the job states.

Errors

The webchat and message codes.