Appearance
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.
| 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>acceptshref. 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"andtarget="_blank"are added automatically. Your server cannot override them.- Only
https:,http:,mailto:, andtel:schemes are allowed. Any otherhrefis removed, includingjavascript:,data:, a relative path and an anchor. - An
<a>with nohrefleft, or with an emptyhrefor 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.
See also
- HTTP Response Format — the exact response shapes that carry these messages.
- How to format messages — practical guide for what to return from your backend.