Most APIs do not want a flat list of values. They want objects inside objects, or lists of them. In PalDock you do not build that structure anywhere, you write it into the field name and PalDock assembles the payload from it.
Objects
A dot means “inside”. Everything before the dot is the object, everything after it is the field within it.
customer.name
customer.email
sends
json
{
"customer": {
"name": "John Doe",
"email": "john.doe@example.com"
}
}
Nest as deep as the API needs, one dot per level: customer.address.city.
Lists
A number means a position in a list. Counting starts at zero, so the first item is 0.
orders.0.product
orders.0.price
orders.1.product
orders.1.price
sends
json
{
"orders": [
{ "product": "Laptop", "price": "1200 EUR" },
{ "product": "Phone", "price": "650 EUR" }
]
}
The same works for a list inside a list. data.0.0 and data.0.1 are the first and second value of the first list:
json
{
"data": [
["first", "second"]
]
}
Mixing them
Objects and lists combine freely, because both are just steps along the same path.
customer.name
customer.email
orders.0.product
orders.1.price
If it helps, think of an object as a folder and a list as a numbered set of files inside it. The field name is the path that gets you to the exact spot.
Order does not matter
You do not have to keep related fields together in the editor. PalDock groups them by name when it builds the request, so these four produce exactly the same payload whichever order they appear in:
customer.name
orders.1.price
customer.email
orders.0.product
Sort them however makes the editor easiest to read.
Getting it right
Check the API documentation for the structure they expect and copy it path by path. If you have an example payload from them, jsonpath.com with JSONPath Plus is a quick way to confirm which path leads to which value.
The same notation works in the other direction. When you read a response, {parsedBody.offers.0.offerId} walks the same path through what came back.

