QuickReplies to manage WhatsApp Business quick replies — saved /-triggered shortcuts that expand to a full message. You create, edit, or delete a quick reply with outbound calls. You receive changes made on a linked device (such as WhatsApp Web or the phone) as inbound events.
Quick replies sync across all linked devices via WhatsApp’s app state sync mechanism (the regular collection, action version 2).
Access
Access quick reply operations through the client:Create or update a quick reply
set_quick_reply
Create a new quick reply or update an existing one. Because app state is an upsert keyed byid, calling this with an existing id edits that quick reply — WhatsApp Web itself builds add and edit from the same mutation.
id— Stable identifier for the quick reply. Must be non-empty. Reuse the sameidto edit it later.shortcut— The/-typed trigger text. Must be non-empty.message— The expanded message text. Must be non-empty.keywords— Extra search terms WhatsApp indexes the reply under. You can pass an empty vector.count— Usage counter. Pass0for a new quick reply.
This call always sends
associatedLabelIds empty, matching WhatsApp Web’s own builder. You cannot associate a quick reply with a label through this call.Delete a quick reply
delete_quick_reply
Delete a quick reply.id— The quick reply to delete. Must be non-empty.
Deletion sends the same
Set mutation as set_quick_reply, with deleted = true and the payload fields cleared — not a syncd Remove. WhatsApp Web’s own delete builder (getQuickReplyDeleteMutation) works the same way. This means the inbound event below always fires as a QuickReplyUpdate; check action.deleted to tell a delete apart from a create or edit.Inbound events
QuickReplyUpdate
You receive a quick reply change made on a linked device through the event bus. The event carries the underlying app state action, so readaction.deleted first to tell a deletion apart from a create or edit.
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 quick reply calls may fail if invoked immediately after pairing before sync completes.
set_quick_reply and delete_quick_reply 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 returnResult<(), AppStateError>. If you pass an empty id, shortcut, or message to set_quick_reply (or an empty id to delete_quick_reply), or a negative count, 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
QuickReplyUpdate - Chat actions — The generic
send_app_state_actionescape hatch - Labels — A similarly-shaped app-state feature with the same upsert-by-id pattern
- State management — How app state sync works under the hood