Werk #22317: Autocomplete endpoint: choice ids can now be null
| Component | REST API | ||
| Title | Autocomplete endpoint: choice ids can now be null | ||
| Date | Sep 28, 2026 | ||
| Level | Trivial Change | ||
| Class | New Feature | ||
| Compatibility | Incompatible - Manual interaction might be required | ||
| Checkmk versions & editions |
|
What changed
The POST /objects/autocomplete/{autocomplete_id} endpoint used to drop every
choice that had no id. Those choices are now returned, so the id field of a
choice can be null.
Why this matters
Some autocompleters use a choice without an id to carry a hint rather than a
value you can pick. The most common one is the truncation notice:
monitored_hostname and monitored_service_description return at most 200
matches, and when more exist they prepend a choice reading "(Max suggestions
reached, be more specific)" that has no id. The endpoint discarded it, so you
received 200 results with nothing to tell you that more were waiting behind a
narrower search.
A response now looks like this:
{
"choices": [
{"id": null, "value": "(Max suggestions reached, be more specific)"},
{"id": "myhost01", "value": "myhost01"}
]
}
What you need to do
If you generate a client from our OpenAPI specification, regenerate it. The
id field of AutocompleteChoiceModel went from a string to a nullable
string, which may otherwise surface as a compile or typing error.
If you call the endpoint directly, treat a choice with id: null as
informational: show it, but do not offer it as something the user can select.