A group's direct members for the lazy inventory tree: the nodes whose `group_id` is exactly `group` (or the ungrouped bucket), in tree order, capped. Loaded on demand when a group is expanded, so the initial page never pulls the whole fleet — it fetches the group skeleton plus per-group counts (`/fleet/group-summary`) and streams members per open group.
const url = 'https://example.com/api/v1/nodes/by-group';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://example.com/api/v1/nodes/by-group \ --header 'Authorization: Bearer <token>'Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Query Parameters
Section titled “Query Parameters”Comma-separated group ids. Bounded by [BY_GROUP_BATCH_MAX].
Responses
Section titled “Responses”The group’s direct members in tree order, flagged if capped
One group’s direct members, or several groups’ when groups= was used. Not keyset-paged — a
folder is loaded whole when it is expanded — so it reports truncation instead of offering a
cursor.
object
Which groups this answer actually covers — present only when groups= was understood.
🚨 This field is what makes the batch form safe against an older core (ADR-125), and
without it the failure is silent and wrong rather than loud. GroupNodesQuery is a plain
Deserialize with no deny_unknown_fields, so a core that predates groups= ignores it
— and with no group= either, it falls through to the ungrouped bucket and returns those
nodes with a perfectly ordinary 200. A newer WebUI would read that as “here are the members
of the thirty folders you asked about” and file every ungrouped node under all of them.
⚠️ Inferring coverage from the rows cannot work: a folder with no members and a folder that was never asked about both come back as no rows. The set has to be stated.
None for the single-group form, so an older WebUI sees exactly the response it always did.
One inventory row (mirrors the WebUI NodeSummary).
object
The node’s address. 0.0.0.0 (or ::) means the node has none — a Meraki device the
Dashboard reports no LAN IP for, such as a mesh repeater (ADR-175). The column cannot be
empty, so that is how “no address” is stored; it is not an address anything can reach.
The group this node belongs to (for the inventory tree); null ⇒ ungrouped.
Stable identifier for a monitored node.
A UUID, not a name or address — both of which can change over a node’s life.
What this node is, and therefore how it is polled — the value that distinguishes a URL or DNS monitor from an ordinary ICMP/SNMP device in the inventory.
Resolved by NodeKind::resolve, the same function GET /nodes/{id} and the scheduler ask,
so a list row can never disagree with the detail page it opens.
A Meraki node’s product type as the Dashboard names it — wireless (an MR access point),
switch, appliance, … — and absent on every other node. What the list’s “AP” badge is
read from (ADR-168 decision 11): an MR stays kind: meraki, so the kind alone cannot say it is
an access point. The detail page reads the same value from meraki_device.product_type.
true on a Meraki access point that is a mesh repeater: it has no wired uplink, so the
Dashboard reports no LAN IP for it and its address is 0.0.0.0 (ADR-175). Absent
otherwise. What the list’s “Repeater” badge is read from.
The node’s own poll-pool; null ⇒ inherited from its folder, else the default pool.
The tree’s pool picker edits exactly this value, so it is what marks the active choice —
the effective pool (and the poller holding the node) comes from /nodes/:id/assignment.
Manual order within the group (the tree sorts members by this, then by name).
The current state of a monitored node or check.
Descriptive maker/model for the “name (addr) (vendor) (model)” display.
Example
{ "nodes": [ { "kind": "wireless_ap", "state": "ok" } ]}No valid bearer token
The ADR-019 envelope every failure renders as. pub(crate) and schema-bearing so the OpenAPI
document can name one error shape for every endpoint (ADR-035) instead of leaving 4xx/5xx bodies
undescribed — a client that has to guess the failure shape ends up parsing the success shape and
reading undefined.
object
object
Stable machine-readable code. Clients branch on this, never on the message.
Operator-facing sentence. Safe to display; never carries an internal error’s own text.
Examplegenerated
{ "error": { "code": "example", "message": "example" }}Role lacks the View permission
The ADR-019 envelope every failure renders as. pub(crate) and schema-bearing so the OpenAPI
document can name one error shape for every endpoint (ADR-035) instead of leaving 4xx/5xx bodies
undescribed — a client that has to guess the failure shape ends up parsing the success shape and
reading undefined.
object
object
Stable machine-readable code. Clients branch on this, never on the message.
Operator-facing sentence. Safe to display; never carries an internal error’s own text.
Examplegenerated
{ "error": { "code": "example", "message": "example" }}Too many inventory reads in flight — retry shortly (list_busy)
The ADR-019 envelope every failure renders as. pub(crate) and schema-bearing so the OpenAPI
document can name one error shape for every endpoint (ADR-035) instead of leaving 4xx/5xx bodies
undescribed — a client that has to guess the failure shape ends up parsing the success shape and
reading undefined.
object
object
Stable machine-readable code. Clients branch on this, never on the message.
Operator-facing sentence. Safe to display; never carries an internal error’s own text.
Examplegenerated
{ "error": { "code": "example", "message": "example" }}