Skip to main content
Canvas components are the cards a PAL can render on the Magic Canvas surface during a conversation. Four are interactive, three display-only: Magic Canvas adds Canvas actions - built-in LLM functions such as canvas_show_question - when the skill is attached. These are not the same as Tools you create via the Tools API and attach to a PAL. If a name collides, your Tools API definition wins.
ComponentDescriptionInteractive
questionAsk a multiple-choice question, optionally with a free-text “Other”Yes
inputAsk for a single typed value: text, email, number, or phoneYes
calendarLet the user pick a date, a time slot, or a date rangeYes
scheduling_embedEmbed your real scheduling page (e.g. Calendly) for live bookingYes
textShow a card of formatted textDismiss only
chartShow a bar, line, or pie chartDismiss only
alertShow a dismissible noticeDismiss only
All components are versioned v1.

Enabling and configuring components

Components come from the PAL’s magic_canvas skill. Attach it:
curl -X PUT https://tavusapi.com/v2/pals/{pal_id}/skills/magic_canvas \
  -H "x-api-key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{ "config": {} }'
Attaching the skill enables every component with its defaults. config.components is a sparse overlay, not an allowlist; add an entry only to configure or disable:
{ "config": { "components": { "chart": { "enabled": false } } } }
Overlay rules:
  • Per-component enabled defaults to true.
  • scheduling_embed stays inactive until scheduling_url is set; a bare attach doesn’t error.
  • Unknown component names and stray fields inside a component entry are rejected with a 400.
Tavus compiles Canvas actions only for conversations with a rendering surface. Audio-only, text-chat, and external meeting_url (Zoom, Teams, Meet) conversations get no Canvas actions, regardless of PAL configuration.
See Canvas configuration for the full config shape, PATCH/bulk-PUT/DELETE endpoints, and validation errors.

Control actions

Each active component gives the PAL one canvas_show_<component> action. With at least one component active, the PAL also gets two control actions:
ActionDescription
canvas_clearRemove a card by its tool_call_id, or clear the whole canvas when no target is given.
update_componentRevise a visible card in place (new chart data, reworded text, updated options) without dismissing and re-showing it. The card keeps its tool_call_id, so interactions stay tied to the same instance.
Canvas actions are model-driven, steered by the PAL’s system prompt. A Canvas action never overwrites a tool you defined with the same name; your tool wins (see Canvas configuration).

Shared layout and display_mode controls

Every Canvas action accepts two optional shared arguments, placement hints the PAL sets when showing a card:
FieldTypeValuesDescription
layoutobjectpreferred_slot: one of safe-area-right, safe-area-leftPlacement hint. The client may adapt it for viewport, keyboard, and safety constraints.
display_modestringinlineCards render inline within their slot. inline is the only supported value.
The PAL can also pass preferred_slot at the top level as shorthand for layout.preferred_slot. Steer placement from the system prompt, for example “keep cards on the left.”

Default placement

GA renders every card in a side rail (safe-area-right), inline, regardless of the component or the hint the PAL passes, so the effective placement is the same for all components:
ComponentEffective slot
question, input, calendar, scheduling_embedsafe-area-right
text, chart, alertsafe-area-right