# Devices

**GET** is available with a **READ** key; creating, updating, or deleting devices needs **WRITE** ([Authentication & scopes](./authentication/)).

## What a “device” represents

Each record is a piece of hardware Fleet tracks for your workspace: identity, assignment, lifecycle **status**, technical **characteristics** (CPU, RAM, optional **keyboard layout**, etc.), and sometimes **MDM** enrollment metadata when Fleet is connected to a device-management source. The **API reference** lists every field returned on list vs detail.

## Listing and filtering

You can page through devices and optionally narrow results with **free-text search**, **assignee user id**, or **client status** filters so integrations can build inventories, support queues, or dashboards without downloading everything at once.

## Batch creation

New hardware is created in **batches**: the body wraps an array of device payloads. Each entry must carry the minimum identity Fleet needs (name, type, category—see **API reference**); many optional fields cover purchase/rental metadata, specs, and assignment. Creation can fail per row for reasons such as invalid serial numbers or provisioning rules—codes are documented on the POST operation.

## Updates and soft delete

**PATCH** changes a subset of fields; omit anything you do not want to touch. **DELETE** performs a **soft delete** in Fleet’s sense: the API may still return a body describing the row, but downstream behavior follows Fleet’s deletion semantics. Some states forbid mutation (`DEVICE_MUTATION_FORBIDDEN` and similar—see **API reference**).

## Keyboard layout

When a device carries a **keyboard layout**, it uses the **same string enum** as catalog **keyboard_layouts** and cart lines, so your UI can stay consistent from quote → cart → asset record.

## Next steps

- [Catalog](./catalog/) — where catalog products and layout choices originate.
- **API reference** — **Devices** tag for paths, bodies, and error codes.