Every method below is reachable as window.Intuify.survey.<method>()
from the browser console, the planned onLoad/onSubmit editor, or
any embed/Tag Manager script.
All methods are read-only on the snapshot of the current page.
Mutations (setResponse, setVariable) feed back into the runtime so
piping, skip logic, and other engine stages re-evaluate on the next
render — they do not navigate the survey by themselves.
Screen#
| Method | Returns |
|---|---|
getScreenType() | "welcome", "questions", "complete", "terminated", "password", "email_gate" |
getProgress() | { current, total, percentage, firstQuestionNumber } | undefined |
isFirstPage() | boolean |
isLastPage() | boolean |
Questions#
| Method | Returns |
|---|---|
getCurrentQuestions() | array of resolved Question objects (piped, carry-forward applied) |
getQuestion(id) | the question, or null if it isn't on the page |
getQuestionText(id) | resolved question text, or "" |
getChoices(id) | answers / ranking items / numeric items array |
getRows(id) | matrix rows array |
getColumns(id) | matrix columns array |
getPluginConfig(id) | defensive copy of configuration.pluginConfig |
getQuestionPayload(id) | full PluginQuestionPayload (same as widget iframe initQuestion message) |
getQuestion returns the engine-resolved object, so the answers, rows,
columns, and configuration you see already reflect:
- piping (
${q://QID1},${e://Field/Score}, etc.) - carry-forward
- localized translations for the active locale
- randomization
Answers#
| Method | Returns |
|---|---|
getResponse(id) | current value for the question (loop-aware) |
getAllResponses() | copy of every answer in the session |
getResponseKey(id) | the actual storage key (e.g. itemId::q1 inside a loop) |
setResponse(id, value) | writes the value through the orchestrator |
setResponse accepts the same shape the renderer would have stored on
its own (string for short-text, string[] for multi-choice, etc.).
The orchestrator runs validation + piping after the mutation.
Variables & embedded data#
| Method | Returns |
|---|---|
getVariable(name) | the variable value |
setVariable(name, value) | writes back through the orchestrator |
getAllVariables() | copy of all variables |
getEmbeddedData() | { urlParams, variables } (both as copies) |
getMetadata() | { sessionId, surveyId, surveyTitle, locale, navPosition, themeColor } |
URL parameters are captured at session start. Custom JS can read but
not rewrite them — store derived values via setVariable instead.
Piping#
window.Intuify.survey.resolveText("Hello ${e://Field/name}");
Resolves piped tokens against the current snapshot (variables, responses, loop context). Useful when you have authored text that uses piping and you need the post-resolution string in custom JS.
Backward-compatible shortcuts#
For scripts written against the old runtime API, three top-level shortcuts remain:
window.Intuify.setVariable(name, value); // → survey.setVariable
window.Intuify.getVariable(name); // → survey.getVariable
window.Intuify.getAllVariables(); // → survey.getAllVariables
New scripts should call window.Intuify.survey.* directly so they
have access to the full surface.
Planned methods (next phase)#
These are reserved on the API and will land alongside the
onLoad/onSubmit sandbox:
advance()— programmatic Next.goBack()— programmatic Previous.terminate(message, type)— surfaces the same termination screens as the no-code rules.dispatchEvent(name, payload)— opens a sandbox-safe channel into widget iframes (e.g. trigger a custom transition).- TypeScript ambient types in the in-app editor for autocomplete.
If you have a use case that needs one of these today, prefer the no-code alternative (skip logic, termination rules) until the sandbox ships.
Related guides#
Was this page helpful?