---
title: "List all DEP sync requests for the tenant"
method: GET
path: "/onboarding/v0/depsyncs/"
tags: ["device_onboarding_DEP Sync Request"]
---

# List all DEP sync requests for the tenant

`GET /onboarding/v0/depsyncs/`

⚠️ Apple devices only. DEP (Device Enrollment Program) is an Apple provisioning technology, now part of Apple Business Manager.

Retrieves a paginated list of all DEP sync requests for the tenant, including each request's status and any device-level failure details.

**About List DEP Sync Requests**

Apple's Device Enrollment Program (DEP), accessed through Apple Business Manager, assigns managed devices to an MDM server. A DEP sync request triggers Esper to pull the latest device assignments from Apple's DEP service, ensuring that newly enrolled or reassigned Apple devices are reflected in the tenant. Each DEPSyncRequestForGetResponse record includes the request's lifecycle status (QUEUED, INPROGRESS, COMPLETE, SUCCESS, or FAILURE), the user or service that created the request (created_by), and the timestamps for when the request was created and last updated. On failure, a failure_reason and a devices object may contain details about specific devices that failed to sync. Use POST /api/onboarding/v0/depsyncs/ to trigger a new sync, and GET /api/onboarding/v0/depsyncs/{id}/ to retrieve a specific request.

**Key Response Fields**

id — DEP sync request UUID

status — QUEUED, INPROGRESS, COMPLETE, SUCCESS, or FAILURE

failure_reason — High-level reason for sync failure (present on FAILURE status)

devices.failure — Array of {serial, reason} objects for devices that failed to process

created_by — User who triggered the sync

created_at / updated_at — Timestamps

**Common Use Cases**

Reviewing the history of DEP sync operations to confirm when devices were last successfully synced from Apple

Identifying which specific devices failed in a DEP sync and why

Auditing DEP sync activity for compliance or onboarding reporting

**Best Practices**

On FAILURE status, inspect both failure_reason for the overall cause and devices.failure for per-device detail — they may differ

Paginate with limit and offset for tenants with a long sync history

## Response `200`

DEP sync request list for the Tenant

- object
  - `code` integer
  - `message` string
  - `content` object
    - `count` integer
    - `previous` string
    - `next` string
    - `results` DeviceOnboardingDEPSyncRequestForGetResponse[]
      - `id` string, uuid — Unique DEP sync request identifier
      - `status` 'QUEUED' | 'INPROGRESS' | 'COMPLETE' | 'FAILURE' | 'SUCCESS' — Status of the DEP sync request
      - `failure_reason` string — Reason for DEP Sync failure. If this field is included in the response, a list of devices with which failed to process DEP sync will also be returned in the API response.
      - `devices` object
        - `failure` DeviceOnboardingDEPSyncDeviceStatus[]
          - `serial` string
          - `reason` string
      - `created_by` string — user id of the user
      - `created_at` string, date-time
      - `updated_at` string, date-time

## Other responses

- `401` — Authorization information is missing or invalid.
- `500` — Internal server error

---

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