WhatsApp reply formats
Relay’s WhatsApp profile chooses a usable presentation for each supported conversation datatype: native text and controls, a static chart preview, an original file, or an explicit app fallback. Your agent does not need WhatsApp-specific writing instructions.
This mapping is defined in contract PR #1378 and implemented in PR #1380. The hosted service was updated on 22 October 2026. An older self-hosted service needs that update; chart previews also require a connection that negotiates outbound media. Deployment and automated checks do not establish delivery to your phone: verify a fresh reply in the actual WhatsApp conversation.
Text and structured replies
| RFC content | WhatsApp presentation | Limit or fallback |
|---|---|---|
| Paragraphs and headings | Ordered paragraphs; headings become bold text | Markdown heading markers are removed |
| Bold, italic, strikethrough | WhatsApp’s native emphasis | Unsupported nesting remains readable |
| Inline code and fenced code | Literal monospace/code text | Code is not interpreted; language hints stay outside it |
| Bullets, numbered lists and quotations | Readable markers and indentation | Meaning remains clear even when a client shows markers literally |
| Named links and autolinks | Visible safe destination; a differing label appears as Guide (https://example.com/guide) | Unsafe destinations are not active links |
| Markdown tables | Ordered labeled rows with every header and cell | No native table or invented chart dataset |
| Markdown image syntax | Alternate text and safe URL as text | An image-looking link does not trigger a download or attachment send |
| Agent messages, progress and final text | The same conversion, split into numbered parts when needed | A final message does not by itself prove the agent’s work succeeded |
| Public plan deliberately sent as message text | Readable list/status text | Stored plan snapshots, receipts and lifecycle/internal records do not become new WhatsApp messages |
| A2UI Text, Row, Column, List, Card and Divider | Complete text plus missing readable card details and separators | No raw component JSON or duplicate full reply |
| Original question choices; matching A2UI Button | Up to 3 reply buttons, or up to 10 list choices; larger sets use numbered text | Full labels/details stay in the body; answer the original question using its control or WhatsApp Reply |
| A2UI ChoicePicker, TextField, CheckBox; multiple or typed inputs; unmatched Button actions | Explanation of the original inputs/actions | When WhatsApp cannot collect or accept the complete answer shape, use the Local Relay app; supported decline/cancel remain available |
| A2UI AudioPlayer | Description and complete text | Explicitly states playback is unavailable; no fabricated audio or transcript |
Long replies keep their order, close and reopen formatting/code as needed, and keep a URL together when it fits a part. User text and quoted user content stay literal. An app fallback names the limitation; it does not invent an app link, WhatsApp Flow, download or approval. WhatsApp cannot edit an earlier reply into a refreshed card: an update needs a new message, and old closed/superseded controls cannot regain authority.
Charts and files
Media needs the connection’s outbound-media capability and must fit both the service’s configured limits and WhatsApp’s declared limits.
| RFC media datatype | WhatsApp presentation | Limit or fallback |
|---|---|---|
| Admitted, enabled canonical bar, line, area, scatter, pie or donut chart | Generated static PNG plus readable title, description, axes/units, named series and every value | Not interactive. Without the capability, keep text; if rendering/preparation fails, state that the preview is unavailable |
| Original JPEG or PNG attachment | Original verified image bytes after the text | Up to 5 MB, subject to any smaller service limit |
| Original plain-text, PDF, DOCX, XLSX or PPTX attachment | Original verified file as a document after the text | Up to 100 MB, subject to any smaller service limit |
| GIF/WebP images, CSV/Markdown/JSON files, audio and MP4 video | Complete text/description and explicit availability fallback | These protocol types are not declared outbound WhatsApp file types in this profile; incoming support does not imply outgoing support |
| Missing, expired, revoked or inaccessible artifact | Truthful unavailable indication with the message text | No substituted file, renewed expiry or invented download URL |
A chart preview is a derived image, distinct from an uploaded original. It comes from admitted structured chart data; Relay does not infer a dataset from prose, a Markdown table or an image URL. The canonical data and any original-data reference stay unchanged. A successful preview does not add an “attachment is in the app” message for that chart. An omitted original file keeps its own fallback; only content actually retained may be described as available in the app.
For incoming media, the protocol covers images/stickers, UTF-8 text files, audio/voice notes, PDF/Office documents and MP4 video, within negotiated limits. Optional automatic transcripts remain labeled, unreviewed derivatives of the original audio. Receiving bytes does not prove the agent understood a document, recording or video. WhatsApp locations and contacts receive an unsupported-content notice.
Questions, signals and delivery
| Interaction or evidence | What it means on WhatsApp |
|---|---|
| Permission or form | Controls retain the original operation, person, allowed answer and expiry. A partial answer, card label, ordinary message or emoji cannot grant a new permission. Native form acceptance that cannot be represented stays in the app |
| Reply or reaction | Targets the original message. One agent reaction per message can replace the business’s acknowledgement reaction |
| 👀 acknowledgement; typing | Admission/activity signals, not completion or proof the agent read the message |
| Agent-to-agent event | Internal to that exchange; not delivered as a message to the person |
| Capture, generated PNG or uploaded file | Preparation/custody evidence, not delivery to your phone |
| Provider acceptance, delivered/read status | Recorded transport evidence; a read status does not mean the agent read anything |
| Failure after any part was accepted | Delivery is uncertain; Relay does not blindly resend the whole reply |
| Closed customer-service window | Text and media are held until an inbound message reopens the window |
To verify delivery, inspect the actual WhatsApp conversation: confirm readable text and URLs, open each expected image/document, and test an original question control. Compare chart values with the text. A stored conversation, renderer gallery or successful emission call alone does not establish recipient delivery. See WhatsApp setup.
The governing mappings are RFC011 §3, RFC012 §7.7, and the WhatsApp binding profile.