---
title: "Get device models"
method: GET
path: "/v1/foundry/device-models/"
tags: ["foundation_FoundryDeviceModels"]
---

# Get device models

`GET /v1/foundry/device-models/`

Returns a list of Foundation-eligible device models registered to the tenant in the Foundry system, with optional filters for manufacturer, model, profile, and Android API level compatibility.

Use this endpoint to enumerate the device models in your tenant's Foundation catalog and retrieve the device_model_id values needed to manage builds and auto-update configuration.

**About Get Device Models**

In Foundry, a device model record represents a hardware profile eligible to run Foundation OS. Each model is associated with a profile name and variant, a manufacturer and model identifier, and configuration that governs how Foundation builds are deployed to it — including whether auto-update is enabled and which build is currently locked for OTA. Device model IDs are required parameters for filtering builds (GET /v1/foundry/builds/) and for configuring auto-update behavior (PUT /v1/foundry/device-models/{device_model_id}/).

**Key Fields / Query Parameters**

manufacturer — Filter by device manufacturer name

model — Filter by device model name

profile_name — Filter by Foundation build profile name

profile_variant — Filter by profile variant identifier

update_compatible_android_api_level_begin — Filter models compatible with updates from this Android API level

update_compatible_android_api_level_end — Filter models compatible with updates up to this Android API level

device_model_id — UUID returned per result; used as a path parameter in build and auto-update endpoints

auto_update — Indicates whether auto-update is currently enabled for the model

locked_build_id — The build_id currently locked for auto-update on this model (nullable)

latest — Whether the model is configured to auto-update to the latest approved build

**Common Use Cases**

Retrieving device_model_id values to use when filtering builds or configuring auto-update for specific hardware

Auditing which device models have auto-update enabled and which build each is locked to

Filtering models by manufacturer or Android API level compatibility when planning a Foundation rollout across mixed hardware

**Best Practices**

Use manufacturer and model filters to quickly locate the target device model rather than paginating through the full list

Cross-reference locked_build_id with GET /v1/foundry/builds/{build_id}/ to confirm the currently pinned build's approval status and version details

Check auto_update status on all managed models before approving a new build — enabled models will begin rolling out the update to devices within 24 hours of approval

**Workflow**

Call GET /v1/foundry/device-models/ with manufacturer and model filters to locate your target hardware

Note the device_model_id for use in subsequent build filtering and auto-update configuration calls

Review auto_update, latest, and locked_build_id to understand the current update configuration for each model

## Query parameters

- `limit` string
- `offset` string
- `manufacturer` string
- `model` string
- `profile_name` string
- `profile_variant` string
- `update_compatible_android_api_level_begin` string
- `update_compatible_android_api_level_end` string

## Response `200`

List of DeviceModels associated with the TenantId coming from the header

- object
  - `code` integer — returned response code
  - `content` object
    - `count` integer — counter of number of device models retrieved
    - `next` string, url — url of the next ten device models
    - `previous` string, url — url of the previous ten device models
    - `results` FoundationDeviceModelV1[]
      - `model_display_name` string
      - `manufacturer` string
      - `model` string
      - `profile_name` string
      - `profile_variant` string
      - `update_compatible_android_api_level_begin` integer
      - `device_model_id` string, uuid
      - `auto_update` boolean
      - `latest` boolean
      - `locked_build_id` string, nullable
      - `created_at` string, date-time
      - `updated_at` string, date-time
      - `created_by` string
      - `updated_by` string

## Other responses

- `401` — Unauthorized
- `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)