Server Connect Actions: URL inputs (GET + Param)

URL inputs: query string (GET) + path params

This tour builds a clear mental model for URL-based inputs.

Query string (GET): ?page=2&q=hello (after the ?). Path params ($_PARAM): /api/items/42 (in the URL path).

You’ll learn where to define these inputs in the action, and how to bind them in step Properties.

GET (query)

?page=2
&q=hello

PARAM (path)

/items/:id
/items/42

Binding

Use $_GET and $_PARAM
in expressions

Define inputs under Inputs so they’re typed and validated.

Use GET for optional filters, sorting, and paging.

Use PARAM for resource identity, such as the :id in a route.

Screenshot: URL inputs: query string (GET) + path paramsClick to open the larger image

The sample GET action is ready

This tour uses the real clients/get.json action from Demo Projects HQ. It already defines $_GET.id as a typed input and uses it in the query step, so the Properties panel shows meaningful values instead of an empty placeholder.

Screenshot: The sample GET action is readyClick to open the larger image

The Server Connect editor is ready

The sample action is now open in the dedicated editor, so the next steps can focus on the workflow tree and the selected query step.

Screenshot: The Server Connect editor is readyClick to open the larger image

Where to define inputs

In a Server Connect Action, inputs are defined under Inputs.

This is where you add named, typed parameters for each source (GET / POST / PARAM / SESSION / COOKIE). Defining inputs up front lets you:

• validate early
• set defaults
• keep bindings predictable

Screenshot: Where to define inputsClick to open the larger image

$_GET: query string values

This real action defines $_GET.id under Inputs. In Demo Projects HQ it is typed as a number and validated as required before the query runs.

That makes the API contract explicit: the action expects an id, and the rest of the flow can rely on it.

Screenshot: $_GET: query string valuesClick to open the larger image

The selected step consumes that input

The client query step uses the validated input directly in its WHERE rule: {{$_GET.id}}.

This is the pattern to teach in tours: define the input under Inputs, then show a real step consuming it in Properties.

Screenshot: The selected step consumes that inputClick to open the larger image

Trace the contract in the workflow tree

The workflow tree is the quick visual check that your input contract is easy to follow: define the input under Inputs, then keep the consuming step clearly named so you can trace what depends on it.

Use the same pattern for route params: define them under Inputs, type them, then bind them in the step that uses them.

Screenshot: Trace the contract in the workflow treeClick to open the larger image

Wrap-up

You now know where URL-based inputs come from and how to bind them.

Pick a next tour based on what you want to handle next.

Quick recap

GET is the query string for optional filters. PARAM is the URL path for resource identity.

Keep inputs typed and validated so the rest of the workflow stays predictable.

Define GET and PARAM inputs under Inputs with clear names, types, and rules.

Bind the values in the steps that use them so the contract stays easy to trace.

Use path params for identity and query params for filters.

Next steps

Continue with Body inputs (POST) for form and JSON payloads, or Session & Cookie inputs for logged-in context and preferences.

POST: validate incoming form fields and JSON body values.

SESSION/COOKIE: read authenticated context and persisted preferences.

Back to the editor hub when you want the broader map again.