Messages & Toasts Reference

View as Markdown

Any time Interface Builder shows the user a server-authored message — a toast after a submission, an inline alert, or a data-source message view — the text passes through an HTML sanitiser before rendering. This page describes exactly what is allowed, what is stripped, and where each message surface appears.

Allowed HTML

Messages and titles may include a narrow subset of HTML: inline formatting, links, paragraph and list structures.

Tag	Purpose
`<b>` / `<strong>`	Bold
`<i>` / `<em>`	Italic
`<u>`	Underline
`<br>`	Line break
`<code>`	Inline monospace
`<a href="...">`	Link
`<p>`	Paragraph
`<div>`	Generic block wrapper
`<ul>` / `<ol>` / `<li>`	Bulleted or numbered list

Every other tag is stripped. Text inside stripped tags is kept; the tags themselves vanish:

"<h1>y</h1>" → "y"
"<table><tr><td>x</td></tr></table>" → "x"
"<script>alert(1)</script>ok" → "ok"

Allowed attributes

<a> accepts href. All other attributes are dropped.
Event-handler attributes (onclick, onerror, and so on) are stripped from every tag.
<img>, <iframe>, and similar embeds are removed entirely.

Link behaviour

Anchors are rewritten to open safely:

rel="noopener noreferrer" and target="_blank" are added automatically. Your server cannot override them.
Only https:, http:, mailto:, and tel: schemes are allowed. Any other href is removed, including javascript:, data:, a relative path and an anchor.
An <a> with no href left, or with an empty href or a bare #, renders as its text only.

Example:

Server sends	User sees / clicks
`Visit <a href="https://example.com">our site</a>`	“our site” link, opens `https://example.com` in a new tab
`Email <a href="mailto:help@example.com">us</a>`	opens mail client
`<a href="javascript:alert(1)">click</a>`	“click” with no link
`Email <a href="">us</a>`	“Email us” as plain text

Variants

The variant field in a response controls the message’s colour and icon. Five values are recognised:

Variant	Toast type	Inline alert style
`default`	Success	Neutral
`success`	Success	Green
`destructive`	Error	Red
`warning`	Warning	Yellow
`info`	Info	Blue

Unknown values fall back to default.

Where messages appear

Each response shape decides where the message ends up.

Response	Appears as
`{ message, variant }` after Wait for response	Toast
`{ message, title, variant }` after Wait for response, with Show message after submission off	Toast (`title` = primary text, `message` = description)
`{ message, title, variant }` after Wait for response, with Show message after submission on	Inline alert that replaces the form; view scrolls to it
`{ oneclick_data: { message } }` after a submit or URL button	Toast
View data source error `{ oneclick_data: { error_message: { title, message, variant? } } }` or `{ oneclick_data: { message_view: { … } } }`	Full-page message view with Go Back / Retry buttons
`{ success: "…" }` after Select view	Success toast just before navigation

Titles and messages in every one of these surfaces go through the same allowlist.

Empty messages

If title is empty or missing, the primary display uses message instead. If both are empty, nothing is rendered for that field.