# Operation parameters

Parameters are what turn a generic operation type into a concrete instruction: not just *reboot*, but
*reboot the hardware*; not just *update*, but *install bundle 1.0*.

There are two distinct parameter blocks in a job request, and confusing them is a common mistake:

| Block | Configures | Defined by |
|---|---|---|
| `parameters` | The operation itself — what the device must do | The operation type's JSON schema |
| `operationParameters` | How the platform manages the execution — timeouts, retries | The platform, identical for every operation type. See [Jobs](../jobs/#per-operation-timeouts-and-retries) |

## Declaring parameters with JSON schema

As an operations administrator you declare an operation's parameters with
[JSON Schema](https://json-schema.org/) when creating or editing an
[operation type](../operation_types/). JSON Schema gives you the whole range from a single enumerated
string to nested objects and arrays, with validation and defaults.

Taking `REBOOT_EQUIPMENT` from the catalog as an example, its parameters are declared as:

```json
{
    "type": "object",
    "properties": {
        "type": {
            "type": "string",
            "title": "Reboot Type",
            "enum": [
                "HARDWARE",
                "SOFTWARE"
            ],
            "default": "HARDWARE"
        }
    },
    "additionalProperties": false
}
```

Three things this declaration buys you:

- **Validation**: a job requesting `"type": "WARM"` is rejected before reaching any device.
- **Defaults**: omitting `type` yields `HARDWARE`.
- **A usable interface**: `title` is what the OpenGate web console renders when a user launches the
  operation by hand, so a well-written schema also produces a well-formed form.

Setting `additionalProperties` to `false`, as above, rejects unknown parameters instead of silently
ignoring them.

## Filling parameters in a north API call

Back-office applications pass parameters as a plain JSON object matching the schema:

```json
{
  "job": {
    "request": {
      "name": "REBOOT_EQUIPMENT",
      "parameters": {
        "type": "HARDWARE"
      },
      "active": true,
      "target": {
        "append": {
          "entities": ["device_1"]
        }
      }
    }
  }
}
```

If the operation type declares no parameters, the block can be omitted entirely.

## How parameters reach the device

The platform does not forward your JSON object verbatim. It translates it into the south API format
before delivering it to the device, where each parameter travels as a named, typed value inside the
operation request.

The exact format the device receives is described in the
[device integration section](../../device_integration/http/operations/). For a complete payload,
including nested array parameters, see the
[update operation example](../examples/update_operation/).