---
title: "List Operation Rules"
method: GET
path: "/v2/org/{org}/nico/task/rule"
tags: ["Rule"]
---

# List Operation Rules

`GET /v2/org/{org}/nico/task/rule`

List Operation Rules on a Site. Filters compose with AND; results are paginated
and the `X-Pagination` response header reports the total count over the
post-filter set.

Org must have an Infrastructure Provider entity. User must have authorization
role with `PROVIDER_ADMIN` suffix.

## Query parameters

- `siteId` string, uuid, required
- `operationType` 'PowerControl' | 'FirmwareControl'
- `pageNumber` integer — One-indexed page number.
- `pageSize` integer

## Response `200`

OK

- OperationRule[]
  - `id` string, uuid, required — Unique identifier of the rule.
  - `name` string, required — Human-readable name of the rule. Required and non-empty.
  - `description` string — Optional free-form description.
  - `operationType` 'PowerControl' | 'FirmwareControl', required — Type of operation this rule applies to. Immutable after creation.
  - `operationCode` string, required — Operation code within the operation type. For `PowerControl`, accepted values are `power_on`, `force_power_on`, `power_off`, `force_power_off`, `restart`, `force_restart`, `warm_reset`, and `cold_reset`. For `FirmwareControl`, accepted values are `upgrade`, `downgrade`, and `rollback`. The server validates the code against the selected type. Immutable after creation.
  - `ruleDefinition` RuleDefinition, required — Executable definition of a rule. Structurally identical to Flow's own rule schema, so an existing YAML rule file maps across field for field. The fields declared here use `camelCase` (`componentType`, `mainOperation`, `pollInterval`) rather than the `snake_case` of Flow's YAML; keys inside the free-form `parameters` map pass through unchanged and stay `snake_case` (`expected_status`, `component_types`).
    - `version` 'v1', required — Schema version. Currently always `v1`.
    - `steps` SequenceStep[] — Ordered execution steps. Steps with the same `stage` run in parallel, stages run sequentially in ascending numerical order. May be empty for operations whose sequencing is hardcoded in Flow (e.g. bring-up, firmware update).
      - `componentType` string, required — Component type this step targets. Validated against Flow's component-type set: `Compute`, `NVSwitch`, `PowerShelf`, `ToRSwitch`, `UMS`, `CDU`. Matched case-insensitively.
      - `stage` integer, required — Stage number; steps with the same stage run in parallel, lower stages run first. Component types must be unique within a stage.
      - `maxParallel` integer — Maximum number of components of this type processed concurrently. `0` means unlimited, `1` means strictly sequential.
      - `timeout` string — Optional child-workflow timeout for this step, as a Go duration string (e.g. `30s`, `2m`). Applies to pre + main + post combined.
      - `retry` RetryPolicy — Retry behavior for a step's child workflow.
        - `maxAttempts` integer, required — Maximum number of attempts including the first.
        - `initialInterval` string, required — Initial retry interval, as a Go duration string (e.g. `1s`).
        - `backoffCoefficient` number, required — Exponential backoff multiplier; must be `>= 1.0`.
        - `maxInterval` string — Optional cap on retry interval, as a Go duration string.
      - `preOperation` ActionConfig[] — Actions to run before the main operation.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `mainOperation` ActionConfig, required — Configuration for a single action within a step.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `postOperation` ActionConfig[] — Actions to run after the main operation.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `delayAfter` string — Deprecated legacy field — sleep duration after this step, as a Go duration string. Prefer encoding the wait as an explicit `Sleep` post-operation action.
  - `isDefault` boolean, required — Whether this rule is currently the default for its `(operationType, operationCode)` tuple.
  - `created` string, date-time, required — Timestamp when the rule was created.
  - `updated` string, date-time, required — Timestamp when the rule was last updated.

## Other responses

- `400` — Error response when request data cannot be validated
- `403` — Error response when user is not authorized to call an endpoint or retrieve/modify objects
- `504` — The Site did not return a result within the request budget allocated to Site communication within the request cycle. This can occur if the Site Controller is down or under heavy request load. Operations are in general safe to retry. In rare cases, operations that create or update resources may succeed even if timeout is returned.

## Changes

- **2026-08-18** `c459c6587dee` — 2 warning
  - for the `query` request parameter `pageNumber`, the max was set to `21474836.00`
  - for the `query` request parameter `pageSize`, the max was set to `100.00`
- **2026-08-14** `441cfc1afc1c` — 1 info
  - added the non-success response with the status `504`
- **2026-06-10** `9a135fa35aad` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api/changes/v2/org/:org/nico/task/rule/get.md)

---

[API](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api.md) · [All operations](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/nvidia/nvidia-infra-controller-rest-api/revisions/2096eb1db2c1/schema)