---
title: "Fetch per-setting Blueprint Drift Audit for a device"
method: GET
path: "/v2/blueprint-drift/{deviceId}/status"
tags: ["drift_Blueprint Drift"]
---

# Fetch per-setting Blueprint Drift Audit for a device

`GET /v2/blueprint-drift/{deviceId}/status`

Fetches a per-setting Blueprint Drift audit for a single device.

Returns a row for every setting evaluated against the device's assigned Blueprint, so you can see exactly which individual settings have drifted rather than just an overall status. Reponse varies by customer and feature availibility. Non-Architect customer where Blueprint Drift is not enabled returns an empty response. Architect customers where Blueprint Drift is not enabled due to not meeting the Esper Agent eligibility criteria returns a Version Mismatch response. Architect customers where Blueprint Drift is enabled returns the full Blueprint Drift response, including drift details.

**About Blueprint Drift Per-Setting Audit**
Blueprint Drift detects when a device's actual configuration diverges from its assigned Blueprint. This endpoint provides the most granular view — a setting-by-setting comparison — used when the summary or batch status endpoints indicate a device has drifted and you need to know exactly what changed.

**Key Fields / Query Parameters**
- `deviceId` — UUID of the device to audit

**Common Use Cases**
- Diagnosing exactly which settings caused a device to be flagged as drifted
- Verifying a specific setting was corrected after a remediation action
- Providing detailed compliance evidence for a single device during an audit

**Best Practices**
- Use this endpoint only after the summary or batch status endpoints indicate the device is drifted, to avoid unnecessary per-setting calls at scale
- Cross-reference drifted settings against the device's assigned Blueprint configuration to plan remediation
- Re-check after remediation to confirm the specific settings returned to compliant

**Workflow**
1. Identify a drifted device via the summary or batch status endpoint
2. GET this endpoint with the device's deviceId for the per-setting breakdown
3. Remediate the drifted settings and re-check to confirm compliance

## Path parameters

- `deviceId` string, uuid, required

## Headers

- `X-Tenant-Id` string, required
- `X-Caller-Id` string, required

## Response `200`

Per-setting Blueprint Drift details

- DriftBlueprintDriftDeviceSettingsResponse
  - `device_id` string, uuid, required — Device identifier
  - `settings` DriftBlueprintDriftDeviceSetting[], required
    - `setting` string, required — Setting identifier
    - `display_name` string — Display name for the setting
    - `section` string — Blueprint section this setting belongs to (e.g., "Connectivity", "Apps & Configuration")
    - `device_state` string, nullable — Current device value (if reported)
    - `desired_state` string, nullable — Desired state defined by blueprint
    - `state` 'drifted' | 'compliant', required — Blueprint Drift status for the setting
    - `severity` 'ignore' | 'critical', required — Blueprint Drift severity
    - `drift_calculated_at` string, date-time, required — Timestamp when drift was calculated
    - `desired_state_reported_at` string, date-time, required — Timestamp when desired state was reported
    - `device_state_reported_at` string, date-time, required — Timestamp when device state was reported

## Other responses

- `400` — Bad request.
- `401` — Authorization information is missing or invalid.
- `404` — Device not found.
- `500` — Internal server error

## Changes

- **2026-09-03** `6b55f43485ae` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/esper/apis/esper-api-reference/changes/v2/blueprint-drift/:deviceId/status/get.md)

---

[API](https://skmtc.dev/esper/apis/esper-api-reference.md) · [All operations](https://skmtc.dev/esper/apis/esper-api-reference/llms.txt) · [OpenAPI document](https://skmtc.dev/esper/apis/esper-api-reference/revisions/aa0eda39dc3e?raw)