Get compliance alerts, optionally narrowed by a filter
Return the paginated list of active compliance alerts, narrowed by a filter — use it to answer any targeted question about non-compliance (“which macOS devices are not encrypted”, “who owns the offline devices”). Send an empty body to list everything. Every filter entry is keyed by a key from getComplianceAlertsFilterCatalog (GET /compliance/alerts/filters-options) and its value is always a clause { "operationType": "INCLUDE" | "EXCLUDE", "values": [...] } — never a bare value, never an operator like eq. Criteria are ANDed. Example: non-encrypted macOS devices → {"filter":{"platform":{"operationType":"INCLUDE","values":["MACOS"]},"status":{"operationType":"INCLUDE","values":["NOT_ENCRYPTED"]}}}. An unknown key is rejected with 400 — the criterion is never silently ignored. Each alert already carries its device name, platform and owner, so no per-row getDevice chaining is needed. ownerId values are employee ids — resolve them with getEmployees. For the remediation context of the alerts found, pass their ids to getComplianceAlertsDetails (up to 25 per call).
Authorizations
Use your Primo API key in the Authorization header as Bearer <API_KEY>.
Body
1 <= x <= 90071992547409911 <= x <= 100One entry per criterion, keyed by the key returned by the filter catalog (GET /compliance/alerts/filters-options). Every value is a clause { operationType, values } — never a bare value, never an operator like eq. Criteria are ANDed. An unknown key is rejected with 400 rather than ignored.