Deprecate using GET /api/v1/fleet/commands w/o host_identifier - #44392
Conversation
…ate example response, and emphasize required parameter for new integrations.
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one. |
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@marko-lisica as discussed in standup |
| > | ||
| > Apple (macOS, iOS, iPadOS) InstallProfile and RemoveProfile commands enqueued by Fleet going forward will have a non-`null` "name" which represents the profile name. Previously-enqueued(prior to v4.84.0) or manually-enqueued commands will have a `null` name, as will other types of Apple MDM commands and all Windows commands. | ||
| > | ||
| > **Deprecated:** calling this endpoint without `host_identifier` is deprecated and will be required in a future Fleet release. Always provide `host_identifier` to scope the response to a single host. Unscoped calls continue to work for backward compatibility but are not recommended; the underlying query is not performant at scale and may time out on large fleets. New integrations must pass `host_identifier`. |
There was a problem hiding this comment.
| > **Deprecated:** calling this endpoint without `host_identifier` is deprecated and will be required in a future Fleet release. Always provide `host_identifier` to scope the response to a single host. Unscoped calls continue to work for backward compatibility but are not recommended; the underlying query is not performant at scale and may time out on large fleets. New integrations must pass `host_identifier`. | |
| > **Deprecated:** This endpoint will be replaced in the next major release. Calling this endpoint without `host_identifier` is **not recommended**. The underlying query is not performant at scale and may time out. |
|
@marko-lisica Why can't we just call it deprecated? Simply calling it deprecated doesn't break backward compatibility, and it sends a clearer signal to users of this API. |
host_identifier calls in /commands REST API, update example response, and emphasize required parameter for new integrations.GET /api/v1/fleet/commands endpoint
|
@rachaelshaw This current I set this to draft because if we want a new endpoint, we should define a milestone and open a new PR against the docs branch. |
I think adding this endpoint under the hosts section is good and I am fully in support of deprecating and removing the multi-host version which has been a problem for quite some time. We only have a few customers who actually use it AFAIK, and most or all with the single-host filter so we could ask them about their usage if we need mroe information. I believe the customers are customer-starchik and customer-deebradel The only concern I have about adding it only under hosts is if a user has a workflow that depends on the host's UUID or serial they might have to do two requests now to get host-by-identifier then commands-by-host whereas now they can put that serial or UUID right into the single request |
|
@marko-lisica @getvictor instead, can we just document that using No new endpoint. Why?
This way, customers using the endpoint w/ the Ultimately up to @rachaelshaw. Heads up that we'll also want to add a deprecation warning to |
|
@noahtalerman Why not make |
@getvictor oh good point. I was thinking this could be a breaking change but I can't think of any automated workflows that would use this |
|
@marko-lisica Can you update this docs PR? |
1 similar comment
|
@marko-lisica Can you update this docs PR? |
GET /api/v1/fleet/commands endpointGET /api/v1/fleet/commands w/o host_identifier
This reverts commit 4090dc5.
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
| | order_key | string | query | What to order results by. Can be any field listed in the `results` array example below. Default is `updated_at`. | | ||
| | order_direction | string | query | **Requires `order_key`**. The direction of the order given the order key. Options include `"asc"` and `"desc"`. Default is `"asc"`. | | ||
| | host_identifier | string | query | The host's `hostname`, `uuid`, or `hardware_serial`. Returns only commands that target the specified host. | | ||
| | host_identifier | string | query | **Required for new integrations.** The host's `hostname`, `uuid`, or `hardware_serial`. Returns only commands that target the specified host. Omitting `host_identifier` is deprecated (see the deprecation notice below) and will be rejected in a future Fleet release. | |
There was a problem hiding this comment.
What does "required for new integrations" mean? Does it error now if not included, or is this just saying it will error in the next major release?
There was a problem hiding this comment.
I think we can just saw Required and mention that it will be removed in Fleet 5. I also moved all the important info to the top (along w/ the required key): https://github.com/fleetdm/fleet/pull/44392/changes#diff-7246bc304b15c8865ed8eaa205e9c244d0a0314e4bae60cf553dc06147c38b64R7688
What do y'all think?
Related issue: Resolves #44170
Immediately deprecate unscoped calls to this endpoint as discussed in 2026/04/29 g-power-to-pc standup.