Skip to content

Breaking Change: Assertions Field Required for Asset Filter-Based API Endpoints

This article describes a breaking API behavior change for asset filter-based bulk operations.

For API endpoints that execute actions by asset filter, the assertions object is now required in the request body.

Previously, this field could be omitted.

You must include:

{
  "assertions": {
    "failIfNumberOfAssetsGreaterThan": NUMBER
  }
}

This safety control reduces the risk of unintended bulk operations caused by broad or incorrect filters.

When failIfNumberOfAssetsGreaterThan is set, the request fails instead of executing if the filter matches more assets than expected.

This helps prevent accidental high-impact actions across large asset sets.

The following API endpoints include assertions and should be treated as requiring this field:

EndpointDocs
/api/public/acquisitions/acquireOpen
/api/public/acquisitions/acquire/imageOpen
/api/public/triages/triageOpen
/api/public/full-text-search-tasksOpen
/api/public/auto-asset-tag/start-taggingOpen
/api/public/baseline/acquireOpen
/api/public/assets/tasks/rebootOpen
/api/public/assets/tasks/shutdownOpen
/api/public/assets/tasks/isolationOpen
/api/public/assets/tasks/retrieve-logsOpen
/api/public/assets/tasks/version-updateOpen
/api/public/assets/uninstall-without-purgeOpen
/api/public/assets/purge-and-uninstallOpen
/api/public/assets/purge-without-uninstallOpen

The full request body varies by endpoint, but the assertions pattern is shared:

{
  "assertions": {
    "failIfNumberOfAssetsGreaterThan": NUMBER
  },
  "...": "other specific fields"
}
  • Update all integrations that call the affected endpoints.
  • Add assertions.failIfNumberOfAssetsGreaterThan to each request body.
  • Set the threshold based on your operational safety limits.
  • Validate behavior in a non-production environment before rollout.