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/paging.

Use ROUTE for resource identity (the :id in the URL).

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

Typed URL inputs make validation visible

This example is intentionally focused on a real $_GET.id input because it shows the full teaching path clearly: input definition, type, validation, and then a real step binding to it.

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

Screenshot: Typed URL inputs make validation visibleClick 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 (optional filters). PARAM is the URL path params (resource identity).

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

Define GET/PARAM inputs under Inputs (name + type + rules).

Bind them in steps using `$_GET.*` and `$_PARAM.*`.

Use path params for identity and query params for filters.

Next steps

Continue with the next input sources: POST body (forms/JSON), then Session/Cookie for logged-in context.

POST: form fields and JSON body values

SESSION/COOKIE: identity and preferences

Back to the editor hub