Update Tenant Device Model

Configures the auto-update behavior for a Foundation device model — enabling or disabling automatic OS updates and optionally locking updates to a specific approved build or to the latest approved build.

Use this endpoint to control how and when a device model receives Foundation OS updates over the air, as the programmatic equivalent of the auto-update toggle and version selector in Esper Software Updates for Foundation.

About Update Tenant Device Model

Once a Foundation build is approved, auto-update must be separately enabled on the device model before devices begin receiving it. This endpoint manages that configuration. Setting auto_update: true enables OTA delivery; latest: true instructs Foundry to automatically track the newest approved build as it becomes available; locked_build_id pins updates to a specific build UUID. Note that latest and locked_build_id are only processed when auto_update is true. Once auto-update is active, enrolled devices on older builds will receive the update over a rolling 24-hour window — devices not currently communicating with Esper will update when they reconnect.

Key Fields / Query Parameters

device_model_id (path, required) — UUID of the device model to update

auto_update (body) — true to enable automatic OTA updates for this device model; false to disable

latest (body) — When true, Foundry automatically locks to the newest approved build whenever one becomes available; processed only when auto_update is true

locked_build_id (body) — UUID of the specific approved build to lock for auto-update; processed only when auto_update is true

Common Use Cases

Enabling auto-update after approving a new Foundation build so enrolled devices begin receiving it within the 24-hour rollout window

Pinning a device model to a specific build version (locked_build_id) to control the exact OS version deployed across that hardware

Disabling auto-update (auto_update: false) to pause OTA rollouts while investigating a reported issue with a new build

Best Practices

Approve the target build via PUT /v1/foundry/builds/{build_id}/ before enabling auto-update — auto-update only delivers approved builds

Use locked_build_id rather than latest in production environments where you want explicit control over which version is deployed; reserve latest for test or canary device models

Ensure devices are configured to accept system updates (via blueprint System Updates policy) before enabling auto-update here — both the device policy and the Foundry model config must align for updates to apply

Workflow

Approve the target build using PUT /v1/foundry/builds/{build_id}/ with approve: true

Call PUT /v1/foundry/device-models/{device_model_id}/ with auto_update: true and either locked_build_id (specific version) or latest: true (track newest approved)

Monitor the Foundation Event Feed (GET /v1/foundry/events/) to confirm the configuration change was recorded and track rollout progress