Inputs
Parameters and request data
Action structure
Understand a Server Connect Action file: inputs/variables, steps, output, and how data flows through an action.
Introduction
Section titled “Introduction”Use this tour to build a dependable mental model of how a Server Connect action file is organized before you try to debug or extend one. You will follow the flow from inputs to nested steps to output, so larger actions feel like readable pipelines instead of a wall of nodes.
Steps
Work happens step-by-step
Output
Shape the JSON response
Think in three layers: inputs → steps → output.
Containers (If / Try / Repeat / Switch) create hierarchy.
Small, named steps make debugging much easier.
The Server Connect editor is ready
Section titled “The Server Connect editor is ready”The action is now open in the dedicated Server Connect editor, so the next steps can focus on the workflow tree and the selected step details.
The Steps tree
Section titled “The Steps tree”The center/left tree is the source of truth for your action.
Each node is a step. Some steps are containers (they contain child steps).
Containers create hierarchy
Section titled “Containers create hierarchy”Some steps are containers (they own a nested list of steps).
Examples: If / Switch / Try-Catch / Repeat / For Each.
Use containers to keep logic readable instead of making one long flat list.
Properties belong to the selected step
Section titled “Properties belong to the selected step”When you select a step in the tree, the Properties panel shows the inputs/options for that step.
Use the tree as the control surface: the current selection is what drives the details on the right.
Outputs shape the response
Section titled “Outputs shape the response”An action returns JSON. Your Output step(s) determine what the client receives.
A useful mental model is: intermediate steps fetch/transform data, then the output decides what to return.
Tip: keep output predictable; it makes front-end binding easier.
Intermediate steps
Build data incrementally
Output
Return a clean JSON shape
Predictable shape
Easier to bind on the client
You can return a single object, arrays, or a structured response with multiple keys.
When debugging, temporarily output intermediate results to inspect them.
Keep naming consistent (e.g., data, total, errors).
Output contract (and terminal steps)
Section titled “Output contract (and terminal steps)”Think of Output as the API contract: a stable JSON shape that your client-side code binds to.
For object/array outputs, describing fields (schema/meta) helps autocomplete, pickers, and keeps bindings consistent over time.
Some steps are “terminal” (they end the flow) such as Response, Error, Redirect, or End. Use them to return early from validation/permission checks or to stop after a final response.
NOTE: Most of the time, the best workflow is: validate → build data → return clean output. Terminal steps are for special cases.
Prefer one main output shape per endpoint.
Use terminal steps when you need a clear early-exit path.
If bindings are missing in the UI, check output + schema first.
Conclusion
Section titled “Conclusion”Recap the structure and continue with a related deep dive.
Next steps
Section titled “Next steps”Pick a related tour to continue.