⚠️ 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

Creates a new Compliance Policy for the enterprise.

Creates a Compliance Policy record defining a set of device restrictions/permissions that can subsequently be applied to Template-provisioned devices.

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

• name — Required — name of the Policy
• description — Free-text description of the policy's purpose
• policy — The underlying Policy Data object — the actual restriction/permission toggles (e.g., cameraDisabled, adbDisabled, phonePolicy) applied to the device
• is_active — Whether the policy should be active immediately

Common Use Cases

• Temporarily re-enabling a restricted feature (e.g., status bar or ADB) on a Kiosk-mode device to pull a bug report
• Defining a restriction profile for a class of legacy Template-provisioned devices
• Making a post-provisioning configuration change without re-running the device through its Template

Best Practices

• Use Blueprints instead of creating a new Compliance Policy for any device not already on the legacy Template system
• Give the policy a clear, descriptive name so it's identifiable later among other Compliance Policies
• Test a new policy on a small device group before rolling it out broadly, since restriction changes can affect Kiosk-mode usability

Workflow

1. Confirm the target devices are still on the legacy Template/Compliance Policy system (not yet migrated to Blueprints)
2. Design the restriction/permission configuration to apply
3. POST it to this endpoint with a name and description, then apply the resulting policy uuid to the relevant devices or groups