Skip to main content
Use 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 by id, calling this with an existing id edits that quick reply — WhatsApp Web itself builds add and edit from the same mutation.
Parameters:
  • id — Stable identifier for the quick reply. Must be non-empty. Reuse the same id to 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. Pass 0 for a new quick reply.
Example:
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.
Parameters:
  • id — The quick reply to delete. Must be non-empty.
Example:
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 read action.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 return Result<(), 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_action escape 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