---
title: "Get all Operations in the Tenant"
method: GET
path: "/v0/operations/"
tags: ["device_Operations"]
---

# Get all Operations in the Tenant

`GET /v0/operations/`

Retrieves a paginated list of all Dispatch operations created within the tenant.

Use this endpoint to see every large-scale fleet operation issued through the Operations API, including Converge actions and group-level app installs and uninstalls, along with each operation's aggregate progress. Supports filtering by state, operation type, and group.

**About Operations (Dispatch Commands)**

Operations, also called Dispatch commands, are designed for large fleet actions that need to be issued once and tracked as a single unit rather than as many individual device commands. Currently supported operation types are CONVERGE and group-level app INSTALL and UNINSTALL (immediate only). Each operation moves through a lifecycle from Created through Dispatching, Dispatched, and Processing to a final Success or Failure, and this endpoint surfaces that lifecycle across every operation in the tenant.

**Key Fields / Query Parameters**

state — filters by operation state using integer codes, for example 10 for Created, 50 for Dispatched, 80 for Success, and 90 for Failure

operation_type — filters by type, for example CONVERGE, INSTALL, or UNINSTALL

group_multi — filters to operations targeting one or more group IDs and their subgroups

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

**Common Use Cases**

Auditing every Converge operation issued across the tenant over a time period

Finding all operations currently stuck in a Dispatching or Processing state, which usually points to device connectivity issues

Filtering operations by group to review fleet actions scoped to a specific store or region

**Best Practices**

Filter by operation_type and state together to narrow large result sets before paging through them

Investigate operations that remain in Dispatched or Processing for an extended period, since this usually indicates devices are not picking up the command due to network issues

Use group_multi rather than fetching all operations and filtering client-side when working with group-scoped fleets

**Workflow**

Call this endpoint with the desired state or operation_type filters

Identify the operation of interest and note its id

Call GET /v0/operations/{operationId}/ for the full status and aggregate device counts

Drill into GET /v0/operations/{operationsId}/devices/ if the operation shows failures

## Query parameters

- `limit` integer
- `offset` integer
- `state` integer
- `ordering` 'created_at' | 'state' | 'updated_at'
- `operation_type` string
- `group_multi` string, uuid

## Response `200`

Operations information for the Tenant

- object
  - `content` object
    - `count` integer
    - `previous` string
    - `next` string
    - `results` DeviceOperationWithStats[]
      - `id` string, uuid
      - `operation` 'CONVERGE'
      - `state` 'CREATED' | 'RESOLVING' | 'RESOLVED' | 'DISPATCHING' | 'COMPLETED' | 'FAILED'
      - `schedule_type` 'IMMEDIATE' | 'WINDOW' — Following Schedule types are supported ``` * IMMEDIATE: Schedule the command to execcute Immediately * WINDOW: Schedule the command to execute within the given window
      - `schedule_args` DeviceScheduleArgs
        - `start_datetime` string, date-time — Start date and time in ISO 8601 format, including timezone (e.g., 2024-08-08T14:30:00Z or 2024-08-08T14:30:00+05:30).
        - `end_datetime` string, date-time — End date and time in ISO 8601 format, including timezone (e.g., 2024-08-08T15:30:00Z or 2024-08-08T15:30:00+05:30).
        - `time_type` 'console' | 'device' — The Time-Type argument, in Schedule args, is to indicate which timezone the Command Framework should utilize when scheduling the command. Following Schedule Args for Time-Type are supported: ``` * CONSOLE: Use the local timezone of the user creating the schedule. * DEVICE: Use the local timezone of the device, to which the command is issued, wherever it may be. ```
        - `window_start_time` string, date-time — It is automatically populated by the time field from the request's start_datetime and cannot be injected via the API request body.
        - `window_end_time` string, date-time — It is automatically populated by the time field from the request's end_datetime and cannot be injected via the API request body.
        - `days` integer[]
      - `operation_device_query` object
      - `arguments` object
        - `converge_with_provision` boolean
        - `sample_key` string
        - `geofence_ids` string[] — List of geofence UUIDs to apply (APPLY_GEO_FENCE).
      - `reason` string
      - `created_at` string, date-time
      - `created_by` string, uuid
      - `updated_at` string, date-time
      - `updated_by` string, uuid
      - `operation_activity` object[]
        - `operation_state` 'CREATED' | 'QUERY INITIATED' | 'QUERY RESOLVED' | 'DISPATCHING' | 'DISPATCHED' | 'PROCESSING' | 'PROCESSED' | 'SUCCESS' | 'FAILURE' | 'CANCELLED'
        - `created_at` string, date-time
      - `operation_stats` DeviceOperationStats
        - `device_operation_statuses_count` object
          - `resolved_device_count` integer
          - `dispatched_device_count` integer
          - `dispatch_failed_count` integer
          - `failed_device_count` integer
          - `success_device_count` integer
          - `cancelled_device_count` integer

---

[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)