How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries

A PowerShell script that queries device data from the ControlUp Edge API using paginated search_after calls experienced failures starting Sunday, returning a 400 Bad Request error. The error message indicated that sorting or aggregations on the _id metadata field were no longer supported, specifically stating that “Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads… is not supported because it loads fielddata into the heap.” This change caused calls sorting by the internal OpenSearch/Elasticsearch document _id to fail.

The root cause was an upstream change implemented over the weekend by ControlUp. The API now blocks the use of the _id metadata field in queries to prevent severe OpenSearch JVM issues such as Out of Memory (OOM) conditions, which were observed when sorting or aggregating on large indexes by _id. This protective measure was applied after discovering more widespread usage of _id sorting than previously expected. In response to the problem and customer impact, ControlUp temporarily disabled this restriction for affected tenants, including the user’s tenant, to restore functionality while addressing the underlying stability concerns.

The resolution for the user’s scripts was to update their pagination logic to sort and search_after using a real mapped field, such as device name, instead of the internal _id metadata field. This change immediately restored proper API operation without requiring further modifications. The user’s initial script had been generated with assistance from a language model but required this adjustment due to the updated API behavior.

The discussion also raised the topic of API change notifications. ControlUp has yet to provide advance announcements or subscription-based alerts for breaking API changes, which users expressed interest in receiving. ControlUp may consider this feedback to improve communication about future updates.

For users facing similar errors, it is essential to avoid using the internal _id metadata field for sorting or pagination in ControlUp API queries. Instead, rely on indexed, mapped fields to ensure compatibility with recent security and stability improvements to the ControlUp Edge API backend built on OpenSearch.

Relevant ControlUp resources include the official documentation on the Edge API and pagination techniques, available at https://docs.controlup.com, and the ControlUp Academy at https://cuacademy.controlup.com for learning best practices with API integration.

Read the entire ‘How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries’ thread below:

Hi everyone.

I have a couple of PowerShell scripts that query device data from the ControlUp Edge API (paginating through results with search_after). They’ve been running fine for weeks, and stopped working on Sunday.

Now getting a 400 error on the query call:

`Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads… is not supported… sort on a mapped field.`

Nothing changed on my end, no script or config changes around that time. Was there a change to the API that would explain this?

Fixed it on my side by switching pagination to sort/search_after on a real mapped field (device name) instead of the _id metadata field. Working now, just want to understand what changed upstream.

do you know what changed in this weekend’s deployment?

Follow-up with more detail on what I found: I originally built this script with the help of an LLM, and used it again to debug the error. Root cause: the query was paginating through results using search_after, sorted on the _id field (the OpenSearch/Elasticsearch document metadata ID, not a field in the data itself). That’s what triggered the 400. The fix was to sort and paginate on a real indexed field (device name) instead of _id, and that resolved it immediately, no other changes needed on my end.

This is the raw error message:

“`[2026-09-07 11:37:34.339] [ERROR] API call failed: The remote server returned an error: (400) Bad Request.
Invoke-RestMethod : Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads (docvalue_fields, script_fields,
runtime_mappings) is not supported because it loads fielddata into the heap. Use the bucket doc_count instead of value_count on _id, or sort on a mapped
field.
At G:\My Drive\GitHub\DW-ControlUp\Scripts\Device Tagging\Set-DeviceTagbyRebootStatus.ps1:252 char:25
+… $response = Invoke-RestMethod -Uri $Uri -Method Post -WebSession $Web…
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand“`

Dennis confirmed that there was indeed an API change over the weekend, and it ended up causing a few more of our PowerShell scripts to fail as well.

I’ll let Dennis chime in, if he wants, on the technical details. I’m just wondering if there is a way to announce API changes ahead of time, or if there are already notifications available that I’m simply not subscribed to.

we have disabled the blocking of the use of _id field for your tenant and all other tenants where this is now known to cause an issue. The reason for implementing the change to block the use of the _id field is that we have seen issues with some tenants where a sort or aggregation on a large index with _id causes the opensearch JVM to cause an Out of Memory (OOM) issue due to the internal mechanics of OpenSearch. We added this as a protection and now learn that the use of _id is more widespread than the logging we had enabled suggested.

Continue reading and comment on the thread ‘How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries’.  Not a member? Join Here!