Skip to content

Messages & Toasts Reference ​

Type: Reference | Audience: Interface builder user (and the backend developer you pass this to)

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.

TagPurpose
<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.

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 sendsUser 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:

VariantToast typeInline alert style
defaultSuccessNeutral
successSuccessGreen
destructiveErrorRed
warningWarningYellow
infoInfoBlue

Unknown values fall back to default.

Where messages appear ​

Each response shape decides where the message ends up.

ResponseAppears as
{ message, variant } after Wait for responseToast
{ message, title, variant } after Wait for response, with Show message after submission offToast (title = primary text, message = description)
{ message, title, variant } after Wait for response, with Show message after submission onInline alert that replaces the form; view scrolls to it
{ oneclick_data: { message } } after a submit or URL buttonToast
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 viewSuccess 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.

See also ​