Server Connect Actions: Body inputs (POST)

Body inputs (POST): forms + JSON

This tour explains POST body inputs.

HTML forms usually send URL-encoded fields (or multipart when files are included). API clients often send JSON (application/json).

You’ll learn where to define POST inputs, how they show up as $_POST.*, and how to validate them.

POST body

Form fields JSON body

Validation

required min/max length

Binding

Use `$_POST.*` inside steps

POST is the request body (not the URL).

Define POST inputs so they are typed and validated.

Treat user input as untrusted: validate early.

Screenshot: Body inputs (POST): forms + JSONClick to open the larger image

The sample POST action is ready

This tour uses the real clients/update.json action from Demo Projects HQ, so you can inspect actual $_POST fields, real validation rules, and a real update step consuming them.

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

Orient yourself in Server Connect editor

Start with the wider context in the Server Connect editor so the next control makes sense in the full workflow. In the next step, you will focus on Define $_POST inputs under Inputs and see how it fits into this area.

Screenshot: Orient yourself in Server Connect editorClick to open the larger image

Define $_POST inputs under Inputs

POST inputs are defined under Inputs → POST.

This is where you add fields like note, mode, email, etc.

Why define them?

• You get defaults + validation rules
• Bindings become predictable: {{$_POST.note}}
• Your flow reads like a contract (what the action expects)

Screenshot: Define $_POST inputs under InputsClick to open the larger image

Binding POST fields in steps

This real update step consumes POST fields such as {{$_POST.name}}, {{$_POST.email}}, and {{$_POST.status}}.

Because the fields were defined first under Inputs, the bindings in Properties stay readable and predictable.

Screenshot: Binding POST fields in stepsClick to open the larger image

Validate POST inputs (don’t guess types)

The real $_POST inputs in this action show the kind of rules tours should teach: id is required and numeric, name has min/max length, email has email validation, and status is required.

That turns input configuration into a visible contract instead of guesswork inside later steps.

Screenshot: Validate POST inputs (don’t guess types)Click to open the larger image

Form vs JSON (what changes?)

Both forms and JSON send data in the request body.

Form submissions send key/value fields (URL-encoded or multipart). JSON requests send a structured object.

In Server Connect, you still bind to body fields using $_POST.*. The key is to validate and type inputs so later steps don’t guess.

Use form encoding for classic HTML forms.

Use JSON for API-style requests (fetch/mobile).

Use multipart when uploading files (then you’ll use `$_FILES`).

Screenshot: Form vs JSON (what changes?)Click to open the larger image

Wrap-up

You now have a clear model for POST inputs: define + validate, then bind.

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

Quick recap

POST = request body.

Define inputs so you can validate and type them, then bind with $_POST.* in step Properties.

Use POST for creating/updating data and sending longer payloads.

Always validate required fields and constraints.

Keep raw inputs separate from derived values.

Next steps

Continue with sessions/cookies for logged-in context, or go back to the editor hub.

Session & Cookie inputs

Core Concepts tour

Back to the editor hub