Devices

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

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 — where catalog products and layout choices originate.
• API reference — Devices tag for paths, bodies, and error codes.