---
title: "Get all DeviceOperations for a specific Operation"
method: GET
path: "/v0/operations/{operationsId}/devices/"
tags: ["device_DeviceOperations"]
---

# Get all DeviceOperations for a specific Operation

`GET /v0/operations/{operationsId}/devices/`

Retrieves the per-device breakdown of a single Dispatch operation, showing where every targeted device stands in the operation's lifecycle.

Use this endpoint after checking an operation's aggregate status to see exactly which devices succeeded, failed, or are still processing. Supports filtering by device operation state and ordering, which makes it the primary tool for isolating the devices that failed a Converge, install, or uninstall action.

**About Device Operations for an Operation**

When a Dispatch operation targets many devices, Esper tracks each device's progress as a separate DeviceOperation record nested under the parent Operation. This endpoint lists all of those records for a given operationsId, each carrying its own state and activity history distinct from the operation's overall state. It is the standard way to move from "this operation had failures" to "these are the specific devices that failed."

**Key Fields / Query Parameters**

state — filters by device operation state using integer codes; common values are 10 for Created, 30 for Dispatched, 40 for Processing, 50 for Success, and 60 for Failure

ordering — orders results by created_at, state, or updated_at; prefix with a minus sign to reverse order

**Common Use Cases**

Listing every device that failed a fleet-wide Converge operation by filtering state to the failure code

Monitoring how many devices in a large install or uninstall operation are still processing

Building a per-device progress view for a dispatch operation shown in the Activity Feed

**Best Practices**

Filter by state rather than paging through the full device list when you only need failures

Combine with ordering by created_at to review the most recently updated devices first

For a single device's status within the operation, use GET /v0/operations/{operationsId}/devices/{deviceId}/ instead of filtering this list

**Workflow**

Create or identify the operation using the Operations endpoints

Call this endpoint with the operationsId to retrieve the full device breakdown

Filter by state to isolate failed or still-processing devices

Re-drive the operation for any failed devices once their connectivity is confirmed

## Path parameters

- `operationsId` string, uuid, required

## Query parameters

- `limit` integer
- `offset` integer
- `state` integer
- `ordering` 'created_at' | 'state' | 'updated_at'

## Response `200`

Device Operation information for the Operation

- object
  - `content` object
    - `count` integer
    - `previous` string
    - `next` string
    - `results` DeviceDeviceOperationWithStats[]
      - `id` string, uuid
      - `operation_id` string, uuid
      - `device_id` string, uuid
      - `state` 'CREATED' | 'INITIATED' | 'SUCCEDED' | 'FAILED'
      - `reason` string
      - `created_at` string, date-time
      - `updated_at` string, date-time
      - `device_operation_activity` DeviceDeviceOperationActivity[]
        - `device_operation_state` string — The state of the device operation (e.g., queued, processing).
        - `created_at` string, date-time — The start time of the device operation state.

---

[API](https://skmtc.net/esper/apis/esper-api-reference.md) · [All operations](https://skmtc.net/esper/apis/esper-api-reference/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/esper/esper-api-reference/revisions/e1f64cbb488e/schema)