A city Wi-Fi ChatOps reply must bold the site name, @mention the on-call engineer, and include a dashboard link. Which message body field should the constructed Webex API call use?
Select an answer to reveal the explanation.
Short Explanation
Plain text is like a sticky note with no formatting—bold, mentions, and rich links need the markdown field. Webex Markdown is a small, intentional dialect, not a full CSS or HTML exam.
Full Explanation
When a city Wi-Fi ChatOps reply must bold a site name, @mention an on-call engineer, and carry a dashboard link, the Webex Messages API expects those constructs in the markdown field using Webex’s limited Markdown dialect. That dialect supports a constrained set of formatting markers, link syntax, and person mentions keyed by person id (or the documented mention forms), which bots and integrations can emit reliably without inventing a full document format.
Relying only on the plain text field fails when the requirement includes bold and mentions: plain text is unformatted body content and does not apply Webex Markdown rendering for those cues. An HTML field with full CSS classes fails because Webex message posts are not a general HTML/CSS rendering surface for ChatOps bots; embedding stylesheet classes is not how mentions or bold are expressed in this API. A raw MIME multipart body with no markdown or text key fails the Messages resource contract—clients construct JSON (or form fields) with documented keys such as markdown/text/attachments, not an arbitrary MIME tree that omits those keys.
Exam caveat: Webex Markdown is intentionally smaller than CommonMark or HTML email; features outside the documented subset may be stripped or ignored, so “rich formatting” does not mean arbitrary HTML.
Operational check: POST a test message with markdown that includes bold, a person mention using the on-call engineer’s person id, and a markdown link; confirm the space renders bold, notifies the person, and opens the dashboard URL before wiring the Wi-Fi automation path.