⚠️ Legacy feature. Compliance Policies (along with Templates, which apply them) are a legacy Esper product. For new device configuration work, use Blueprints instead — Compliance Policies remain available for existing Template-based deployments. See Introduction to Compliance Policies: https://help.esper.io/hc/en-us/articles/12653153592977-Introduction-to-Compliance-Policies

Retrieves a single Compliance Policy by ID.

Returns the full details of one Compliance Policy, including its restriction/permission configuration and the count of devices it's currently applied to.

About Compliance Policies A Compliance Policy is a set of device-configuration permissions and restrictions — screen and unlock behavior (keyguard, safe boot), connectivity (USB, tethering, NFC), communication (SMS, outgoing/incoming calls, dialer), hardware (camera, screenshots), and system controls (factory reset, ADB, side-loading, Play Store, app uninstall, date/time configuration) — that gets applied to a device after it has already been provisioned through a Template. They're commonly used to make a post-provisioning change to a Kiosk-mode device, such as temporarily re-enabling the status bar or ADB to pull a bug report, without re-provisioning the device. Templates and Compliance Policies are legacy Esper products; Blueprints are the current, recommended way to define device configuration for new work.

Key Fields / Query Parameters

• policy_id — UUID of the Compliance Policy to retrieve
• device_count — Number of devices this policy is currently applied to

Common Use Cases

• Reviewing a policy's full restriction configuration before applying it to additional legacy devices
• Confirming device_count before changing a policy that's still widely applied to Template-provisioned devices
• Auditing a specific policy's settings during a security review of legacy Kiosk devices

Best Practices

• Check device_count before editing or deleting a policy, since changes affect every device it's applied to
• Use the list endpoint to find the policy_id if it isn't already known
• Treat this as read-only legacy configuration data — plan a Blueprint equivalent if the device fleet is migrating

Workflow

1. List policies to find the policy_id of interest
2. GET this endpoint for full detail on its restriction configuration
3. PATCH or DELETE as needed once the impact (device_count) is understood