Typing Indicators and Read Receipts in the WhatsApp API

The WhatsApp Cloud API shows “typing…” to a customer when you send a mark-as-read request with a typing_indicator object, using the ID of the message you’re answering. The same call turns the customer’s ticks blue, and the indicator disappears when your reply arrives or after 25 seconds, whichever comes first.

Marking a message as read on its own is the same request without the typing part. This guide gives both requests, what each one does on the customer’s phone, when it’s worth using, the mistakes that make a business look broken, and how Automate AI handles it in the inbox, chatbots and AI replies.

Two requests, one endpoint

Neither of these is a message. They’re status updates about a message the customer sent you, and both go to the same endpoint you use for sending: POST https://graph.facebook.com/<API_VERSION>/<PHONE_NUMBER_ID>/messages, with a system or business access token as a Bearer token.

A successful call returns { "success": true }. There’s no message ID in the response, because nothing was sent. Meta’s examples use API version v26.0, and the version in the path is optional.

Where the message ID comes from

The message_id must be the ID of a message the customer sent you. You get it from the incoming message webhook, in messages[].id, and it starts with wamid.. Meta says to use a valid wamid from a message you received.

1. Receive the webhook for the customer’s message and save messages[].id along with the chat.
2. When a reply is on its way, send the read or typing request with that ID.
3. Send the reply as a normal message. The indicator clears as soon as it lands.

An ID that isn’t valid comes back as error 131009, “Parameter value is not valid”. Meta’s fix is to use a valid ID from a message you received, so check you copied the incoming message’s wamid. More codes are in WhatsApp API error codes, and the webhook payload is covered in WhatsApp Cloud API webhooks.

How marking as read works

Meta’s rules for the read request are short, but two of them matter in practice:

• Earlier messages go too. In a 1:1 chat, marking one message as read also marks the earlier messages in that conversation as read. Use the latest message’s ID and you’re done.
• Groups are different. In a group chat, marking one message doesn’t mark the earlier ones, so each message needs its own request.
• There’s a time limit. Meta says to mark incoming messages as read within 30 days of receipt.

Don’t confuse this with the read statuses you receive. When a customer reads your message, Meta sends a status webhook with status: "read". That’s their side of the blue ticks, and it’s what campaign reports count. The request in this guide is your side: telling the customer you’ve read theirs.

The blue ticks a person sees in the WhatsApp app, and how they turn them off, are explained in green tick vs blue tick.

How long “typing…” shows, and when to use it

The indicator is dismissed when you respond or after 25 seconds, whichever comes first. Meta calls it good practice when your reply will take a few seconds, and warns against showing it if you won’t actually respond.

For long replies, you can send the request again, for example every 20 seconds, while the reply is still being written, and stop as soon as it’s sent or abandoned. One more thing: once you’ve marked a message as read, the customer can see you’ve read it, so a slow reply after blue ticks feels slower than one before them.

Common mistakes

1. Sending it on every keystroke. An inbox that fires a typing request each time an agent presses a key sends dozens of calls for one reply. Throttle it to one every 20 seconds or so per chat.
2. Marking as read the moment a message arrives. If no one will look at the chat for an hour, instant blue ticks tell the customer they’re being ignored. Mark as read when a person or bot actually handles it.
3. Using your own message’s ID. The request needs the customer’s message ID from the webhook.
4. Showing “typing…” and then not replying. Meta specifically says not to.
5. Letting a failure stop the reply. Treat the typing request as best effort. If it fails, log it and send the reply anyway.

What the API doesn’t do

Typing indicators go one way, from your business to the customer. Meta documents how to send one, but its webhook reference has no event for a customer typing, so your inbox can’t show “Customer is typing…” from the API.

It also isn’t a presence signal. The only indicator type in Meta’s request is text, and each one is tied to a message the customer sent, so it can’t work as an “online” status. If you want customers to know when you’re available, say so in your greeting or auto-reply.

Typing indicators in Automate AI

Automate AI does the typing request for you. Turn on Settings › General › Show typing to customers and click Save Changes. Only an owner or manager can change it, and it’s off until someone does. With it on, the customer sees “typing…” on WhatsApp in three cases:

• Someone on your team types a reply in the shared inbox.
• The AI is preparing a reply. The indicator never holds the AI’s answer back.
• A chatbot flow, basic reply or auto-reply is about to answer. These replies wait about 1.5 seconds so the indicator can be seen; with the switch off they go out instantly.

Behind the switch, the app follows the rules above:

Building your own system on top? The WhatsApp Business API page covers the REST API and developer webhooks.