Skip to main content
The Labels feature manages WhatsApp chat labels (etiquetas) — the colored tags WhatsApp Business uses to organize chats. Outbound calls create, rename, recolor, or delete labels and add or remove a label on a chat. Inbound label changes made on a linked device (such as WhatsApp Web or the phone) are delivered as events. Labels sync across all linked devices via WhatsApp’s app state sync mechanism (the regular collection, action version 3).

Access

Access label operations through the client:

Create or update a label

create_label

Create a new label or update an existing one. Because app state is an upsert keyed by label_id, calling this with an existing label_id renames or recolors that label.
Parameters:
  • label_id — Stable identifier for the label. Must be non-empty. Reuse the same label_id to update the label later.
  • name — Display name shown in the WhatsApp UI. Must be non-empty.
  • color — WhatsApp color index for the label swatch.
Example:

Delete a label

delete_label

Delete a label. Existing chat associations are kept by the server; WhatsApp Web prunes them from its local database on receipt of the delete.
Parameters:
  • label_id — The label to delete. Must be non-empty.
Example:

Associate a label with a chat

add_chat_label

Tag a chat with a label.
Parameters:
  • label_id — The label to apply. Must be non-empty.
  • chat_jid — The chat to label.
Example:

remove_chat_label

Remove a label from a chat.
Parameters:
  • label_id — The label to remove. Must be non-empty.
  • chat_jid — The chat to untag.
Example:

Associate a label with a message

add_message_label

Use this to associate a label with a single message. Unlike add_chat_label above, this association is keyed by the message as well as the chat, under the label_message action.
Parameters:
  • label_id — The label to apply. Must be non-empty.
  • chat_jid — The chat containing the message.
  • message_id — The message to label. Must be non-empty.
Example:

remove_message_label

Remove a label association from a single message.
Parameters:
  • label_id — The label to remove. Must be non-empty.
  • chat_jid — The chat containing the message.
  • message_id — The message to unlabel. Must be non-empty.
Example:
Both calls send one mutation per message. There is no batch form on the wire, matching WhatsApp Web’s own builder.
label_message is not in the generated app-state schema registry, because WhatsApp Web’s current live action table no longer builds this mutation (only label_edit and label_jid remain there). It is still a first-class protocol action: the protobuf action registry declares it, and both whatsmeow and Baileys build the identical index. For that reason the schema is hand-maintained separately from the generated set. The wire index is ["label_message", labelId, chatJid, messageId, "0", "0"] on the regular collection at action version 3. The trailing "0", "0" pair is the message-key fromMe/participant tail every message-scoped action carries, and no observed source shows it holding anything but its defaults.

Inbound label events

Label changes made on a linked device are delivered through the event bus. All three events carry the underlying app state action so you can read the new name, color, deleted flag, or labeled state directly.
from_full_sync is true when the event came from an initial app state full sync, so you can suppress UI notifications during bootstrap.

App state sync

App state sync requires the relevant encryption keys, which arrive during initial sync after pairing. Outbound label calls may fail if invoked immediately after pairing before sync completes.
create_label, delete_label, add_chat_label, and remove_chat_label are thin wrappers over the same app-state send path as chat actions. They share its conflict-retry behavior, added in PR #1158. A call that loses a version race with another linked device is no longer silently dropped. The client applies the winning patches, rebuilds the mutation, and resends. It retries up to 5 times before returning Err. See Chat actions — App state sync for the full explanation.

Error handling

All methods return Result<(), AppStateError>. If you pass an empty label_id (or an empty name to create_label), the call fails immediately with AppStateError::InvalidRequest before any network work is done. A call can also return AppStateError::Internal if no app state sync key is available yet, a network error occurred, or an app-state version conflict with another device could not be resolved after 5 rebuild-and-resend attempts (see App state sync above).

Complete example

See also

  • Events — Handle LabelEditUpdate, LabelAssociationUpdate, and MessageLabelAssociationUpdate
  • Chat actions — Archive, pin, mute, star, and other app-state-synced chat operations
  • State management — How app state sync works under the hood