{{root.key}} tokens and write values with
publish_fields or set_variable. Six roots are readable inside a tool; two of
them, tooldata and userdata, are also where operations write.
The six roots
Tokens resolve in every string inside an operation’s
config: URL, headers,
query, body, say text, if operands, frontend_rpc payload, handoff
summary, send_dtmf digits — except {{secrets.…}}, which only an http
operation may use (a code operation reads input.secrets). A secret anywhere
else is refused at save, because those operations speak, show, store or compare
what they resolve. Tokens do not resolve in:
- a
codeoperation’s TypeScript, which reads the same roots asinput.args,input.tooldataand so on; - an
httpoperation’smethod; - a
transferdestination, which is always a literal number.
{{args.address.city}}, {{tooldata.slots.0.id}}.
How a token resolves
An
http header or query value that is exactly one token resolving to nothing is
left out of the request.
system_vars.now, .date and .time are rendered at the moment the operation
runs, in the agent’s timezone. The phone keys (human_phone_number,
agent_phone_number, direction) are filled on phone calls, WhatsApp calls and
chats and media streams, and empty on web calls, API chats, Telegram and test
runs, so do not make one the only source of a value the tool needs. channel
says which one the session is.
Tokens that are refused
A token whose root is not one of the six is an error at save, not text: a bare{{name}}, {{customer.number}} pasted from another platform, or a typo
like {{userdate.name}}. There is no escape syntax; literal {{…}} text can
only appear inside a code operation.
A key published before an
if is readable in both branches; a key published
inside a branch is readable only later in that branch.
tooldata or userdata
tooldata is plumbing between two operations of one run. userdata is what the
conversation should still know afterwards: it is readable by other tools and by
the agent’s prompt, persisted with the session and merged onto the contact.
Default to tooldata; a booking reference the agent must repeat later belongs in
userdata, the API envelope you dug it out of does not.
Keys starting with _talqing are reserved; writing one to userdata is refused.
publish_fields
http, code and frontend_rpc results are not visible to later operations
until you publish values out of them. Each entry is {path, key?, store}:
A
path missing from the result fails the operation with
publish field path 'order.status' was not found in operation output, and
on_error decides what happens next. A null on the path is not missing: it
publishes null. A background_execution operation cannot publish.
set_variable
Writes one templated value, with no operation to produce it. All three config
fields are required.
value may be any JSON value; a single-token string keeps the resolved type.
set_variable returns nothing to the model.
Next
The HTTP operation
Request fields, failure rules and network rules.
Variables
Declaring
vars, the system_vars keys and timezone.Testing and publishing
Seed
userdata, vars and a timezone and run the draft.