> ## Documentation Index > Fetch the complete documentation index at: https://coralogix-193a2008-facade-sync-4ab5cdd.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Changelog > Public API changes, grouped by release version and the date it shipped. * `POST /dataplans/policies/v1`, `PUT /dataplans/log-policies/v1`, `PUT /dataplans/span-policies/v1`, and `PUT /dataplans/rum-policies/v1` now document a `429 Too Many Requests` response, returned when the request would exceed the team's maximum number of policies for that data type (logs, spans, or RUM). The response body is the standard error object (`code`: 429, `message`: string). To resolve it, request a limit increase or reduce the number of policies. This replaces the `400` previously returned for this case on `POST /dataplans/policies/v1` — **breaking** for callers that key on `400` to detect the limit; the overwrite endpoints previously did not report this condition. * Added an `INCIDENT_IO` value to the notification-center `ConnectorType` string enum, which now holds `CONNECTOR_TYPE_UNSPECIFIED`, `SLACK`, `GENERIC_HTTPS`, `PAGERDUTY`, `IBM_EVENT_NOTIFICATIONS`, `SERVICE_NOW`, `EMAIL`, `PAGERDUTY_INCIDENTS`, `MICROSOFT_TEAMS`, `EVENTBRIDGE`, and `INCIDENT_IO`. Non-breaking; additive. The enum is reachable across the notification-center REST API as follows: * **Connectors**: the `type` field accepts it in the request and response bodies of `POST /notifications/notification-center/v1/connectors` (create) and `PUT /notifications/notification-center/v1/connectors` (replace); it also appears in the response body of `GET /notifications/notification-center/v1/connectors` (list), `GET /notifications/notification-center/v1/connectors/{id}` (get), and `GET /notifications/notification-center/v1/connectors/all/list` (batch-get). The `connector_type` query parameter on `GET /notifications/notification-center/v1/connectors` also accepts it. The request body's `type` field on `POST /notifications/notification-center/v1/connectors:testConfig` accepts it too. * **Connector summaries**: the `type` field appears in the response body of `GET /notifications/notification-center/v1/connectors/all/summaries` and `GET /notifications/notification-center/v1/connectors/list/summaries`; the `connector_type` query parameter on the latter also accepts it. * **Connector types**: the `type` field appears in the response body of `GET /notifications/notification-center/v1/connectors/types/summaries`, and both the `type` query parameter and the response body's `type` field on `GET /notifications/notification-center/v1/connector-schemas` accept/return it. * **Presets**: the `connectorType` field accepts it in the request body, and appears in the response body, of `POST /notifications/notification-center/v1/presets:createCustom` (create custom) and `PUT /notifications/notification-center/v1/presets:replaceCustom` (replace custom); it also appears in the response body of `GET /notifications/notification-center/v1/presets` (batch-get) and `GET /notifications/notification-center/v1/presets/{id}` (get). The `connector_type` query parameter, and the returned preset summary's `connectorType` field, on `GET /notifications/notification-center/v1/presets/summaries/system` (system default summary), `GET /notifications/notification-center/v1/presets:getDefaultSummary` (default summary), and `GET /notifications/notification-center/v1/presets:summariesList` (list summaries) also accept/return it. * Renamed the OpenAPI tag on `POST /dataplan/data-usage/v1/query` and `GET /dataplan/data-usage/v1/capabilities` from `Data Usage Query service` to `Data Usage Query Service`. Docs grouping only; no path, HTTP method, request, or response change. Non-breaking. * **Deprecated:** the v2 data usage endpoints are now marked deprecated and are no longer published in the API reference. They continue to be served exactly as before — no path, HTTP method, request body, response shape, field name, or field type changes, and existing integrations keep working — but they are no longer documented, and new integrations should not adopt them. The deprecated operations are `GET /dataplans/data-usage/v2`, `GET /dataplans/data-usage/v2/spans/count`, `GET /dataplans/data-usage/v2/logs/count`, `POST /dataplans/data-usage/v2/daily/units`, `POST /dataplans/data-usage/v2/daily/processed-gbs`, `POST /dataplans/data-usage/v2/daily/evaluation-tokens`, and both `GET` and `POST /dataplans/data-usage/v2/export-status`. * **Replacement for usage queries:** `POST /dataplan/data-usage/v1/query` (note the singular `dataplan` in the new path) returns billable data usage aggregated into daily or hourly buckets, with filtering and grouping by supported labels. Use `GET /dataplan/data-usage/v1/capabilities` to discover the labels, measurement kinds, units, and per-request limits it accepts before submitting a query. Between them these cover the six usage-reading operations above; the v1 query response is bucket-first and is not shaped like the v2 responses, so callers need to map fields rather than swap the path. * **No replacement yet for export status:** `GET` and `POST /dataplans/data-usage/v2/export-status` have no v1 equivalent. They remain available and keep working; callers relying on them should not migrate yet. * No removal date is set, and nothing is being switched off by this change. * The dashboard API now rejects a spans-query `fieldValue` variable source that has both `observationField` (an object) and `value` (an object) set simultaneously. Both fields live at `dashboard.variablesV2[].source.query.spansQuery.type.fieldValue` in the request bodies. Previously at least one of the two had to be set, and setting both was silently accepted (the extra field ignored); the API now returns a validation error when both are present, so exactly one of the two must be set. The deprecated `value` field (legacy span-field addressing) remains accepted when used alone; `observationField` remains accepted alone and is the preferred field. This is a breaking change for callers that were sending both fields together — they must drop `value` and send only `observationField`. Affected request bodies: `POST /dashboards/dashboards/v1`, `PUT /dashboards/dashboards/v1`, and `POST /dashboards/check/v1` (which carries the dashboard in the same `dashboard` field); clients can verify the object shapes of both fields from that path in the OpenAPI spec. * Added new comparison values to the alert threshold enums in the alert-definition payload. Non-breaking; additive. The values are reachable across the alerts REST API as follows: * **Request bodies**: `POST /alerts/alerts/v3` (create), `PUT /alerts/alerts/v3` (replace), `POST /alerts/alerts/v3/all/create` (batch-create), and `PUT /alerts/alerts/v3/all/replace` (batch-replace). * **Response bodies**: in the `alertDef` object of `POST /alerts/alerts/v3`, `PUT /alerts/alerts/v3`, `GET /alerts/alerts/v3/{id}`, and `GET /alerts/alerts/v3/version-ids/{alert_version_id}`; and in the `alertDefs` array of `GET /alerts/alerts/v3` (list), `POST /alerts/alerts/v3/all/create`, and `PUT /alerts/alerts/v3/all/replace`. * The metric threshold `conditionType` string enum gains `METRIC_THRESHOLD_CONDITION_TYPE_EQUALS` and `METRIC_THRESHOLD_CONDITION_TYPE_NOT_EQUALS`; it now holds `METRIC_THRESHOLD_CONDITION_TYPE_MORE_THAN_OR_UNSPECIFIED`, `METRIC_THRESHOLD_CONDITION_TYPE_LESS_THAN`, `METRIC_THRESHOLD_CONDITION_TYPE_MORE_THAN_OR_EQUALS`, `METRIC_THRESHOLD_CONDITION_TYPE_LESS_THAN_OR_EQUALS`, `METRIC_THRESHOLD_CONDITION_TYPE_EQUALS`, and `METRIC_THRESHOLD_CONDITION_TYPE_NOT_EQUALS`. * The logs threshold `conditionType` string enum gains `LOGS_THRESHOLD_CONDITION_TYPE_EQUALS` and `LOGS_THRESHOLD_CONDITION_TYPE_NOT_EQUALS`; it now holds `LOGS_THRESHOLD_CONDITION_TYPE_MORE_THAN_OR_UNSPECIFIED`, `LOGS_THRESHOLD_CONDITION_TYPE_LESS_THAN`, `LOGS_THRESHOLD_CONDITION_TYPE_EQUALS`, and `LOGS_THRESHOLD_CONDITION_TYPE_NOT_EQUALS`. * The analytics threshold `operator` string enum gains `ANALYTICS_THRESHOLD_OPERATOR_NOT_EQUALS`; it now holds `ANALYTICS_THRESHOLD_OPERATOR_MORE_THAN_OR_UNSPECIFIED`, `ANALYTICS_THRESHOLD_OPERATOR_LESS_THAN`, `ANALYTICS_THRESHOLD_OPERATOR_MORE_THAN_OR_EQUALS`, `ANALYTICS_THRESHOLD_OPERATOR_LESS_THAN_OR_EQUALS`, `ANALYTICS_THRESHOLD_OPERATOR_EQUALS`, and `ANALYTICS_THRESHOLD_OPERATOR_NOT_EQUALS`. * Added an optional `customDataprimeQueries` array of strings to alert indicators in the Cases REST API response payload. It appears at `case.caseIndicators.alertIndicators[].customDataprimeQueries` in the responses of `PUT /cases/acknowledged/v1/{id}`, `DELETE /cases/acknowledged/v1/{id}`, `POST /cases/assigned/v1/{id}`, `DELETE /cases/assigned/v1/{id}`, `GET /cases/cases/v1/{id}`, `PUT /cases/cases/v1/{id}`, `POST /cases/closed/v1/{id}`, `POST /cases/indicators/v1/get`, `PUT /cases/priority-override/v1/{id}`, `DELETE /cases/priority-override/v1/{id}`, and `PUT /cases/resolved/v1/{id}`; and at `cases[].caseIndicators.alertIndicators[].customDataprimeQueries` in the responses of `POST /cases/acknowledged/v1`, `PUT /cases/assigned/v1`, `DELETE /cases/assigned/v1`, `POST /cases/cases/v1`, `POST /cases/closed/v1`, `POST /cases/priority-override/v1`, `DELETE /cases/priority-override/v1`, and `POST /cases/resolved/v1`. The array holds up to 1000 entries, each a custom DataPrime query string configured on the alert definition and up to 65535 characters long. Non-breaking; additive. * Added an `EVENTBRIDGE` value to the notification-center `ConnectorType` string enum, which now holds `CONNECTOR_TYPE_UNSPECIFIED`, `SLACK`, `GENERIC_HTTPS`, `PAGERDUTY`, `IBM_EVENT_NOTIFICATIONS`, `SERVICE_NOW`, `EMAIL`, `PAGERDUTY_INCIDENTS`, `MICROSOFT_TEAMS`, and `EVENTBRIDGE`. Non-breaking; additive. The enum is reachable across the notification-center REST API as follows: * **Connectors**: the `type` field accepts it in the request and response bodies of `POST /notifications/notification-center/v1/connectors` (create), `PUT /notifications/notification-center/v1/connectors` (replace), `POST /notifications/notification-center/v1/connectors:initialize`, and `POST /notifications/notification-center/v1/connectors:initializeUpdate`; it also appears in the response body of `GET /notifications/notification-center/v1/connectors` (list), `GET /notifications/notification-center/v1/connectors/{id}` (get), and `GET /notifications/notification-center/v1/connectors/all/list` (batch-get). The `connector_type` query parameter on `GET /notifications/notification-center/v1/connectors` also accepts it. The request body's `type` field on `POST /notifications/notification-center/v1/connectors:testConfig` accepts it too. * **Connector summaries**: the `type` field appears in the response body of `GET /notifications/notification-center/v1/connectors/{id}/summary`, `GET /notifications/notification-center/v1/connectors/all/summaries`, and `GET /notifications/notification-center/v1/connectors/list/summaries`; the `connector_type` query parameter on the latter also accepts it. * **Connector types**: the `type` field appears in the response body of `GET /notifications/notification-center/v1/connectors/types/summaries`, and both the `type` query parameter and the response body's `type` field on `GET /notifications/notification-center/v1/connector-schemas` accept/return it. * **Presets**: the `connectorType` field accepts it in the request body, and appears in the response body, of `POST /notifications/notification-center/v1/presets:createCustom` (create custom) and `PUT /notifications/notification-center/v1/presets:replaceCustom` (replace custom); it also appears in the response body of `GET /notifications/notification-center/v1/presets` (batch-get) and `GET /notifications/notification-center/v1/presets/{id}` (get). The `connector_type` query parameter, and the returned preset summary's `connectorType` field, on `GET /notifications/notification-center/v1/presets/summaries/system` (system default summary), `GET /notifications/notification-center/v1/presets:getDefaultSummary` (default summary), and `GET /notifications/notification-center/v1/presets:summariesList` (list summaries) also accept/return it. * Documented the validation the incidents REST API already enforces, across `GET` and `POST /incidents/incidents/v1`, `GET /incidents/incidents/v1/{id}`, `GET /incidents/incidents/v1/{incident_id}/events`, `POST /incidents/incidents/v1/all/acknowledge`, `POST /incidents/incidents/v1/all/resolve`, `POST /incidents/incidents/v1/all/closed`, `POST` and `DELETE /incidents/incidents/v1/all/by-user`, `GET /incidents/aggregations/v1`, `GET /incidents/events/v1`, `GET /incidents/events/v1/{event_id}`, `POST /incidents/events/v1/{event_id}/acknowledge`, `POST /incidents/events/v1/{event_id}/resolve`, `GET /incidents/events/v1/all/count`, `POST /incidents/filter-values/v1`, and `GET /incidents/filter-values/v1/events`. Strings gained `minLength`/`maxLength`/`pattern`, integers `minimum`/`maximum`, and arrays `minItems`/`maxItems`. Values outside these bounds were already rejected, so this is non-breaking. By field: * **Incident identifiers** are UUID strings (`minLength` and `maxLength` 36, UUID `pattern`, hex accepted in either case): the `id` path parameter of `GET /incidents/incidents/v1/{id}`, the `incident_id` path parameter of `GET /incidents/incidents/v1/{incident_id}/events`, the `ids` query parameter of `GET /incidents/incidents/v1` (array of 1–10000 items), the `incidentIds` array in the request bodies of `POST /incidents/incidents/v1/all/acknowledge`, `POST /incidents/incidents/v1/all/resolve`, `POST /incidents/incidents/v1/all/closed`, and `POST /incidents/incidents/v1/all/by-user` (1–10000 items), the `incident_ids` query parameter of `DELETE /incidents/incidents/v1/all/by-user` (an array of 1–10000 items — that operation takes no request body), the response `notFoundIds` array (0–10000 items), and the incident payload's `id`. * **Incident payload** — returned by `GET` and `POST /incidents/incidents/v1`, `GET /incidents/incidents/v1/{id}`, the four bulk operations (`POST /incidents/incidents/v1/all/acknowledge`, `POST /incidents/incidents/v1/all/resolve`, `POST /incidents/incidents/v1/all/closed`, and `POST` and `DELETE /incidents/incidents/v1/all/by-user`), and the event operations `GET /incidents/events/v1/{event_id}`, `POST /incidents/events/v1/{event_id}/acknowledge`, and `POST /incidents/events/v1/{event_id}/resolve`: `name` string 1–500; `description` string 1–2000; `lastStateUpdateKey` string 1–2000; `assignments` array ≤1000 items, each with a `userId` string 1–300; `metaLabels` array ≤1000 items, each with `key` and `value` strings 1–255; `events` array ≤10000 items; `createdAt`, `closedAt`, and `lastStateUpdateTime` strings 20–30 characters. * **Aggregation payload** (`incidentAggs[]` of `GET /incidents/aggregations/v1`, which does not carry the incident payload): `groupBysValue`, `aggStateCount`, `aggStatusCount`, `aggSeverityCount`, `aggAssignmentsCount`, and `aggMetaLabelsCount` arrays ≤1000 items; `listIncidentsId` array ≤1000 UUID-string items; `allValuesCount` and each nested `count` integer 0–1000000000; `firstCreatedAt`, `lastClosedAt`, and `lastStateUpdateTime` strings 20–30 characters. * **Pagination**: `pageSize` integer 1–10000 and `pageToken` string 1–4096, in the `pagination` object of the `POST /incidents/incidents/v1` request body and of the `pagination` query parameter on `GET /incidents/aggregations/v1` and `GET /incidents/events/v1`; the response `pagination.nextPageToken` string is 1–4096. `GET /incidents/events/v1` accepts at most 1000 items per page and defaults to 100 when `pageSize` is omitted — its operation description and the description of its `pagination` parameter now say so, while the shared `pageSize` schema keeps `maximum: 10000` because the other two operations do accept 10000. * **Filters, ordering and search** (`POST /incidents/incidents/v1`, `POST /incidents/filter-values/v1`, the `filter` query parameter of `GET /incidents/aggregations/v1`, and `GET /incidents/events/v1`): `assignee` array ≤1000 items of strings 1–300; `applicationName` and `subsystemName` arrays ≤1000 items of strings 1–256; `searchQuery.query` string 1–4096; the order-by/search field selector's `applicationName` and `subsystemName` strings 1–256; the `contextualLabels` and `displayLabels` maps' `contextualLabelValues` and `displayLabelValues` arrays hold ≤1000 items of strings 0–4096, and the filter-value responses' `contextualLabelValue` and `displayLabelValue` are strings 0–4096 — an empty label value is accepted, matching the empty values readable from the incident payload's `contextualLabels`/`displayLabels` maps. * **Response collections**: `incidents` (list and bulk responses) and `incidentAggs` (`GET /incidents/aggregations/v1`) arrays ≤10000 items, matching the maximum page size; the incident-events `items` array ≤1000; `count` and the aggregation count fields integers 0–1000000000. The events total `count` on `GET /incidents/events/v1/all/count` is a numeric string of 1–20 characters. * **Incident-event payload** (`GET /incidents/events/v1`, `GET /incidents/events/v1/{event_id}`, `POST /incidents/events/v1/{event_id}/acknowledge`, `POST /incidents/events/v1/{event_id}/resolve`, and `GET /incidents/incidents/v1/{incident_id}/events`): each `items[]` entry's `cxEventKey` string 1–4096 and `incidentEvent.id` string 1–64; the extended metadata's `alertId` string 1–64, `alertName` string 1–4096, `alertGroupByFields` array ≤100 items of strings 1–256, and `alertLabels` array ≤1000 items; the originator's `userId` string 1–300 and `systemName` string 1–256; and the `incidentEvents` array of `GET /incidents/incidents/v1/{incident_id}/events` ≤10000 items. On the request side, the `event_id` path parameter is a string 1–64 on `GET /incidents/events/v1/{event_id}`, `POST /incidents/events/v1/{event_id}/acknowledge`, and `POST /incidents/events/v1/{event_id}/resolve` (event IDs are free-form, not UUIDs), and the event filter's `name` is a string 1–500 on `GET /incidents/events/v1`, `GET /incidents/events/v1/all/count`, and `GET /incidents/filter-values/v1/events`. * **Snooze event**: `durationMinutes` integer 1–525960 and `userId` string 1–300. * **Filter, ordering and filter-value collections** (`POST /incidents/incidents/v1`, `GET /incidents/aggregations/v1`, `POST /incidents/filter-values/v1`, `GET /incidents/filter-values/v1/events`, `GET /incidents/events/v1`, and `GET /incidents/events/v1/all/count`): the `status`, `state`, and `severity` filter arrays hold ≤1000 items; `orderBys` and `groupBys` ≤100 items; the filter-value count arrays (`assigneeWithCount`, `statusWithCount`, `stateWithCount`, `severityWithCount`, `metaLabelsWithCount`, and the contextual- and display-label `valuesWithCount`) ≤1000 items; the `contextualLabel` field of a group-by, order-by, or search selector is a string 1–256; the contextual-label pair's `fieldName` is 1–256 and `fieldValue` 0–4096; and the list response's `totalSize` is an integer 0–1000000000. * Documented the validation the cases REST API already enforces, and corrected three bounds the spec had stated incorrectly. Strings gained `minLength`/`maxLength`/`pattern` and arrays `minItems`/`maxItems`. Non-breaking; the service already rejected values outside these bounds. UUID strings below are 36 characters with a `pattern` that accepts hex in either case. By payload: * **Case payload** — returned by `POST /cases/cases/v1` (list), `GET` and `PUT /cases/cases/v1/{id}`, `POST /cases/indicators/v1/get`, and the case-state operations `POST /cases/acknowledged/v1`, `PUT` and `DELETE /cases/acknowledged/v1/{id}`, `PUT` and `DELETE /cases/assigned/v1`, `POST` and `DELETE /cases/assigned/v1/{id}`, `POST /cases/closed/v1`, `POST /cases/closed/v1/{id}`, `POST /cases/resolved/v1`, `PUT /cases/resolved/v1/{id}`, `POST` and `DELETE /cases/priority-override/v1`, and `PUT` and `DELETE /cases/priority-override/v1/{id}`: `title` is 1–512, previously documented as 4096; `aiSummary` is 1–10000, previously documented as 4096, which understated what the service returns. * **Update-case request** (`PUT /cases/cases/v1/{id}`): `title` 1–512 and `resolutionReason` 1–500, both previously documented as 4096. Requests above the real limits were already rejected, and `aiSummary` values above 4096 were already being returned, so no working request or response changes behavior. * **Case labels** — `key` and `value` strings 1–4096, in both directions. As a **request** input they appear at `filters.caseLabelsFilter.flatLabels[]` of `POST /cases/cases/v1` (list) and `POST /cases/filter-values/v1`, and in the indicator label settings of `POST /cases/cases/case-settings/v1/configs` and `PATCH /cases/cases/case-settings/v1/configs/{id}`. In **responses** they appear in the case payload's `labels`, `groupings[]`, and `caseIndicators.genericIndicators[].labels[]` on the operations above, in the `flatLabelsAggregation[].filter` of `POST /cases/filter-values/v1`, and in the settings payload of those two operations plus `GET /cases/cases/case-settings/v1/configs/{id}`, `GET /cases/cases/case-settings/v1/configs:getActive`, and `GET /cases/cases/case-settings/v1/configs:getSystemDefaults`. On the case-settings operations the indicator settings' `filteringConditions` array also holds ≤1000 items. * **Case events** (`POST /cases/cases/v1/{case_id}/comments`, `GET /cases/cases/v1/{case_id}/events`, `GET /cases/events/v1/{event_id}`, `PUT /cases/events/v1/{event_id}/comments`): `eventId` a UUID string; the title-changed event's `from`/`to` 1–512 and the resolution-reason-changed event's `from`/`to` 1–500; comment `text` (request) and `unsafeText` (response) 1–10000, with `attachments` ≤100 items; a log attachment's `logId` a UUID, `logContent` 1–10000, and `queryLinkSuffix` 0–4096; a dashboard-widget attachment's `customDashboardId` and `widgetId` 1–4096 with its own `queryLinkSuffix` 0–4096; a file attachment's `fileId` a UUID and `fileName` 1–4096; `assigneeUserId` and `previousAssigneeUserId` UUID strings; Slack comment metadata `workspaceId`, `channelId`, `threadId`, `userId`, and `userEmail` 1–256; the notification-sent event's `notificationRequestId` a UUID with `notifications` ≤1000 items, each carrying a `token` string 1–4096; the notification-failed event's `error` 1–4096; and an unknown-assignee error's `unknownAssigneeEmail` 1–256. * **Case-event actor** (same four operations, at `event.actor`): a user actor's `id` is a UUID string; a Slack actor's `slackUserId`, `displayName`, and `userEmail` are strings 1–256 with `coralogixUserId` a UUID; a ServiceNow actor's `id`, `username`, and `userEmail` are strings 1–256 with `coralogixUserId` a UUID; an API-key actor's `id` and `name` are strings 1–256. * **`event_id` path parameter** — a UUID string on `GET /cases/events/v1/{event_id}` and on `PUT` and `DELETE /cases/events/v1/{event_id}/comments`. * **Deep links** (`GET /cases/cases/v1/{case_id}/deep-links`): `detail` and each impacted entity `url` are strings 1–2048, `alertDef` is 0–2048, and `impactedEntities` holds ≤1000 items. Every alert-indicator deep-link URL variant under `alertIndicators` is likewise a string 1–2048: `logs`, `metrics`, `rum`, `slo`, and `tracing`. * **Notification deliveries** (`POST /cases/notifications/v1/deliveries`): request `caseIds` array 1–1000 items of strings 1–64; response `notificationDeliveries` and `matchedRouters` arrays ≤1000 items; `attempts` array ≤100 items; `requestNotificationId` a UUID string and `timestamp` 20–30 characters; `connectorId` and `routerId` strings 1–128 matching `^[a-zA-Z0-9][a-zA-Z0-9_-]*$` — the same shape the notification-center API documents for connector and router IDs, so custom (non-UUID) IDs stay valid; `connectorName` and `routerName` strings 1–256; `evidenceUrl` 1–2048; `errorMessage` 1–4096. * **Whitespace-only values are rejected** for the fields the service trims before checking they are non-empty: `title`, `resolutionReason`, `aiSummary`, comment `text` and `unsafeText`, `logContent`, `fileName`, `customDashboardId`, `widgetId`, and the `from`/`to` of the title-changed and resolution-reason-changed events. Their `pattern` now requires at least one non-whitespace character, so a value such as `" "` no longer validates — it was already rejected by the service. The service also applies the maximum length *after* trimming, which a `maxLength` cannot express, so a value whose trimmed form fits may still exceed the documented maximum. * Added an optional `resolveWithSignal` boolean to alert indicators in the Cases REST API response payload. It appears at `case.caseIndicators.alertIndicators[].resolveWithSignal` in the responses of `PUT /cases/acknowledged/v1/{id}`, `DELETE /cases/acknowledged/v1/{id}`, `POST /cases/assigned/v1/{id}`, `DELETE /cases/assigned/v1/{id}`, `GET /cases/cases/v1/{id}`, `PUT /cases/cases/v1/{id}`, `POST /cases/closed/v1/{id}`, `POST /cases/indicators/v1/get`, `PUT /cases/priority-override/v1/{id}`, `DELETE /cases/priority-override/v1/{id}`, and `PUT /cases/resolved/v1/{id}`; and at `cases[].caseIndicators.alertIndicators[].resolveWithSignal` in the responses of `POST /cases/acknowledged/v1`, `PUT /cases/assigned/v1`, `DELETE /cases/assigned/v1`, `POST /cases/cases/v1`, `POST /cases/closed/v1`, `POST /cases/priority-override/v1`, `DELETE /cases/priority-override/v1`, and `POST /cases/resolved/v1`. `true` or omission means the case resolves together with the alert signal; `false` means the case stays open for manual resolution. Non-breaking; additive. * Added an optional `pbacTruncated` boolean to the response body of `POST /cases/cases/v1` (list cases). It indicates whether the returned list was truncated because of PBAC (Policy-Based Access Control) restrictions, meaning the caller may not have access to every case matching the filters. Non-breaking; additive. * Added documented validation constraints on the Actions REST API (`GET`, `POST`, and `PUT` on `/actions/actions/v2`, `GET` and `DELETE` on `/actions/actions/v2/{id}`, `POST /actions/order/v2`, and `POST /actions/batch/v2`). The action `name` is limited to 1–50 characters and `url` to 32768 characters and must start with `http://` or `https://` (both matching the validation the service already enforces); `description` and `dpxlFilter` allow up to 65535 characters; `createdBy` up to 255. Action `id` values (including the `id` path parameter on get and delete) are documented as 36-character UUID strings. The `applicationNames` and `subsystemNames` arrays declare up to 1000 items of up to 1024 characters each, `urlFields` up to 1000 items (each entry requires both `name` and `required`, unique by `name`), the batch `requests` array up to 1000 items, and the `actions`/`matchingResponses` response arrays up to 10000/1000 items. The integer map values of `privateActionsOrder` and `sharedActionsOrder` declare an explicit 0–4294967295 range. Documentation-only — the constraints describe validation the API already enforces. Non-breaking. * Added documented validation constraints on the enrichment-rules REST API (`GET`, `POST`, `PUT`, and `DELETE` on `/enrichment-rules/enrichment-rules/v1`, `PUT /enrichment-rules/enrichment-rules/v1/all`, `GET /enrichment-rules/enrichment-rules/v1/limit`, `GET /enrichment-rules/enrichment-rules/v1/settings`, `GET`, `POST`, and `PUT` on `/enrichment-rules/custom-enrichment-rules/v1`, `GET` and `DELETE` on `/enrichment-rules/custom-enrichment-rules/v1/{id}`, and `POST /enrichment-rules/custom-enrichment-rules/v1/all/contents`). String fields backed by stored columns — `name`, `description`, `fieldName`, `enrichedFieldName`, and `fileName` — are limited to 255 characters (the custom enrichment `name` additionally accepts only letters, digits, and underscores) (`name`, `fieldName`, and `enrichedFieldName` require at least 1 character). The file content fields allow up to 20971520 characters for `textual` and 27962028 characters for `binary` (base64 of the default 20 MiB file-size limit), and the file `extension` must be `csv` (the only supported format). Integer fields such as `id`, `version`, `fileSize`, `limit`, `used`, `enrichmentAmountLimit`, `enrichmentsInUse`, `rowLimit`, and `queryOnlyRowLimit` declare an explicit 0–2147483647 range. Arrays declare `minItems`/`maxItems` bounds: `requestEnrichments` up to 100 items, the `enrichment_ids` delete query parameter up to 1000, `searchClauses` and `customEnrichmentsData` up to 1000, `selectedColumns` up to 100 items of up to 1024 characters, and the `enrichments` response arrays up to 1000 (`customEnrichments` up to 30). Documentation-only — the constraints describe validation the API already enforces. Non-breaking. * Added documented validation constraints on the dataplans policies REST API (`GET`, `POST`, and `PUT` on `/dataplans/policies/v1`, `GET` and `DELETE` on `/dataplans/policies/v1/{id}`, `POST /dataplans/policies/v1/all/reorder`, `POST /dataplans/policies/v1/all/test-policies`, `POST /dataplans/policies/v1/all/forecast-usage`, `PUT /dataplans/log-policies/v1`, `PUT /dataplans/span-policies/v1`, and `PUT /dataplans/rum-policies/v1`). Policy `id` values (including the `id` path parameter, reorder `orders[].id`, and `archiveRetention.id`) are documented as 36-character UUID strings. `name` and `description` are limited to 255 Latin-1 characters (pattern-enforced), `tagName` to 255 characters and must start with `tags.`, and `dpxlExpression`, rule `name`, and `tagValue` allow up to 65535 characters (rule values must be non-empty). The target `dataset` allows up to 512 characters. The policy `order` integer documents that negative values occur (range −2147483648 to 2147483647), while reorder `orders[].order` requires a positive value; `companyId` declares 0–2147483647 and `usageTiers[].dailyQuotaPercentage` declares its enforced 0–100 range. Arrays declare `minItems`/`maxItems` bounds matching service limits: `targets` up to 5 per policy, `tagRules` up to 100, `severities` up to 6, `usageTiers` up to 3, overwrite `policies` up to 200 per source type (10000 for RUM), reorder `orders` up to 200, `metaFieldsValuesList` up to 50 (each field non-empty, up to 1024 characters), and the list response `policies` up to 30000. Documentation-only except where noted — the constraints describe validation the API already enforces. Non-breaking. * Message and enum fields across the Management API that previously appeared as a bare `$ref` now keep their field-level OpenAPI metadata — `description`, and where annotated also `example`, `deprecated`, and `readOnly` — by wrapping the `$ref` in `allOf`. The same metadata is kept on array fields whose items are a message or enum `$ref`. Non-breaking; documentation-only — request and response wire shapes are unchanged. * 10 query parameters that were documented as optional are now documented as required, so the spec matches what the services already enforce. Server behavior is unchanged — omitting any of these was already rejected. Affected parameters, with their JSON shapes: * `ids`, an array of strings: `GET /aaa/team-scopes/v1` and `GET /slo/slos/v1/all/list` (the latter is a batch-get by IDs, not a filtered list). * `enrichment_ids`, an array of `int64` integers: `DELETE /enrichment-rules/enrichment-rules/v1`. * `incident_ids`, an array of strings: `DELETE /incidents/incidents/v1/all/by-user`. * `alert_ids`, an array of strings, and `timestamp_range`, an object with `from` and `to`: `GET /alerts/alerts/v3/all/events`. * `filter`, an object with `cxEventKeys`, `cxEventLabelsFilters`, `cxEventMetadataFilters`, `cxEventTypes`, and `timestamp`: `GET /alerts/events/v3`, `GET /alerts/events/v3/all/count`, `GET /alerts/events/v3/all/statistics`. * `pagination`, an object with `pageSize` and `pageToken`: `GET /alerts/events/v3`. * Added documented OpenAPI validation constraints across the integrations and extensions REST API (`GET`, `POST`, and `PUT` on `/integrations/contextual-data/v1`; `GET` and `DELETE` on `/integrations/contextual-data/v1/{id}`; `GET /integrations/contextual-data/v1/definitions/{id}`; `POST /integrations/contextual-data/v1/test/{integration_id}`; `POST /integrations/extensions/v1`; `GET /integrations/extensions/v1/catalog/{id}`; `GET`, `POST`, `PUT`, and `DELETE` on `/integrations/extensions/v1/deployed`; `GET /integrations/integrations/v1`; `GET /integrations/integrations/v1/{id}`; `GET /integrations/integrations/v1/definitions/{id}`; `GET /integrations/integrations/v1/deployed/{integration_id}`; `DELETE /integrations/integrations/v1/instances/{integration_id}`; `GET /integrations/integrations/v1/rum/app-versions`; `GET /integrations/managed/v1`; `GET /integrations/managed/v1/{integration_id}`; `POST` and `PUT` on `/integrations/metadata/v1`; `POST /integrations/metadata/v1/test`; and `GET /integrations/template/v1`). Non-breaking; the constraints describe values the service already accepts: * Most string fields (for example `id`, `name`, `description`, `version`, `integrationKey`, and parameter `key`) now declare `maxLength: 65535` and a permissive `^[\s\S]*$` pattern. * Larger free-form content fields — installation commands/templates, Terraform configuration block values, parameter `apiKey.value`/`stringValue`, and markdown descriptions (`descriptionMd`, `upgradeInstructionsMd`) — declare `maxLength: 1048576` characters with the same pattern. * Extension binary payloads (`binaries[].data`), returned only in the responses of `GET /integrations/contextual-data/v1/{id}`, `GET /integrations/extensions/v1/catalog/{id}`, and `GET /integrations/integrations/v1/{id}`, declare `maxLength: 5000000` characters. * Extension item `stableId` fields declare `maxLength: 63`. * Array fields declare `maxItems: 10000`. * Integer count fields — `amountIntegrations` and the deployed-extension/revision item counts (`actions`, `alerts`, `customDashboards`, `enrichments`, `eventsToMetrics`, `grafanaDashboards`, `kibanaDashboards`, `metricsRuleGroup`, `parsingRules`, `savedViews`) — declare an explicit `maximum` of `4294967295`. * Added an optional `impactedEntities` array to the case filters object in the request bodies of `POST /cases/cases/v1` (list cases) and `POST /cases/filter-values/v1` (filter values). Each item must set exactly one of `apmService` (object with a required `name` string) or `apmDatabase` (object with a required `name` string) — an item with neither arm set is rejected. A case is returned if it impacts ANY of the listed entities (OR logic); names are matched case-insensitively; an empty array applies no filtering. Non-breaking; additive. * Documented the connector summary object in the notification-center REST API. It now declares the title `Connector Summary` and the description "A summary of a connector, excluding sensitive configuration values.", which renders on the values of the `connectorSummaries` object map in the `GET /notifications/notification-center/v1/connectors/all/summaries` response and on the items of the `connectors` array in the `GET /notifications/notification-center/v1/connectors/list/summaries` response. Non-breaking; documentation-only. * Added an optional `highlighted` boolean to a widget in the dashboard payload — `true` means the widget is marked as highlighted for all users of the dashboard, `false` (or omitted) means it is not. It appears in the request bodies of `POST /dashboards/dashboards/v1` (create), `PUT /dashboards/dashboards/v1` (replace), and `POST /dashboards/check/v1` (check), and in the dashboard read responses of `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. Not allowed on a widget reference (a widget whose `reference` field is set instead of a `definition`); the API rejects it. Additive — the field is new and does not alter existing fields. Note that `PUT /dashboards/dashboards/v1` is a full-replace operation: a client must send the current `highlighted` value (or `true` to keep the widget highlighted, or `false`/omit it to clear highlighting) when replacing a dashboard, otherwise the field is reset to `false` on the written-back widget. * Added optional `caseLifecycle.autoClose` object to the case-settings REST API. When present, the object requires a `postResolutionPeriod` string for configuring automatic closure of resolved cases. It is accepted in the request bodies of `POST /cases/cases/case-settings/v1/configs` and `PATCH /cases/cases/case-settings/v1/configs/{id}`; returned as `caseSettings.caseLifecycle.autoClose` in the response bodies of `POST /cases/cases/case-settings/v1/configs`, `GET /cases/cases/case-settings/v1/configs/{id}`, `PATCH /cases/cases/case-settings/v1/configs/{id}`, and `GET /cases/cases/case-settings/v1/configs:getActive`; and returned as `caseLifecycle.autoClose` in the response body of `GET /cases/cases/case-settings/v1/configs:getSystemDefaults`. Non-breaking; omitting it preserves existing behavior. * Documented existing requiredness and semantics of the `variablesV2` payload in the dashboard REST API — request bodies of `POST /dashboards/dashboards/v1` and `PUT /dashboards/dashboards/v1` and the `dashboard` field of `POST /dashboards/check/v1`, and dashboard read responses of `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. The spec now declares what the service already enforces, so this is non-breaking: each variable requires `id` (UUID string), `name` (string), `displayName` (string), `displayType` (enum string), `source` (object), and `value` (object); a static source requires `values` (array of `{ value, label }` objects), `valuesOrderDirection` (enum string), and `allOption` (object), and each static value entry requires both `value` (string) and `label` (string); a query source requires `valuesOrderDirection` (enum string) and `allOption` (object), and exactly one of the query objects `logsQuery` / `metricsQuery` / `spansQuery` / `dataprimeQuery` (a `oneOf`) must be set — the service rejects a `query` object with no arm (this exactly-one rule is enforced by the API, not by the OpenAPI `oneOf` schema); `allOption` requires an explicit `includeAll` boolean. Also documented that the zero values `VARIABLE_DISPLAY_TYPE_V2_UNSPECIFIED` and `ORDER_DIRECTION_UNSPECIFIED` are rejected (accepted `displayType`: `VARIABLE_DISPLAY_TYPE_V2_LABEL_VALUE` / `VARIABLE_DISPLAY_TYPE_V2_VALUE` / `VARIABLE_DISPLAY_TYPE_V2_NOTHING`; accepted `valuesOrderDirection`: `ORDER_DIRECTION_ASC` / `ORDER_DIRECTION_DESC` / `ORDER_DIRECTION_NONE`), and that a spans query `fieldValue` should set `observationField` (its legacy alternative `value` is documented as deprecated). Also fixed the description of the variable `name` field. Separately, clarified the shared `dataModeType` enum description — an omitted value (or `DATA_MODE_TYPE_HIGH_UNSPECIFIED`) queries high-priority ("Frequent Search") data while `DATA_MODE_TYPE_ARCHIVE` queries archive ("Monitoring") data. Because that enum is shared, the clarified description also renders on the other `dataModeType` fields that reference it — the dashboard annotation fields (`annotations[].source.logs.dataModeType`, `annotations[].source.spans.dataModeType`, `annotations[].source.dataprime.dataModeType`) the variable textbox Lucene default (`variablesV2[].source.textbox.defaultValue.defaultLuceneValue.dataModeType`), and the variable Dataprime query default (`variablesV2[].source.query.dataprimeQuery.type.queryText.dataModeType`) — across the same create/replace/check/read dashboard payloads. Additionally documented several existing backend constraints the spec had not surfaced: `displayFullRow` may be `true` only for a textbox source; a logs `fieldValue` requires `observationField`; a metrics `labelValue` requires `labelName`; and PromQL (`metricsQuery.type.promqlQuery`) and Dataprime (`dataprimeQuery.type.queryText`) query text is syntax-checked only by `POST /dashboards/check/v1` (create and replace accept it without compiling). Non-breaking; documentation-only. * Added a bulk-create operation for alert definitions: `POST /alerts/alerts/v3/all/create`. The request body's required `alertDefsToCreate` array accepts 1–100 items; each item holds a required `alertDefProperties` object (the same alert-definition properties object used by the `POST /alerts/alerts/v3` create request) and an optional `accessPolicy` string (raw access-policy JSON, 0–65536 characters; setting it requires the `alerts:UpdateAccessPolicy` permission, and when it is omitted the alert is created without an access policy). The operation is best-effort per entry: the response's `alertDefs` array returns the successfully created alert definitions in the order of their corresponding request entries, and `failedToCreateAlertDefs` reports each failed request entry as an object with a required zero-based integer `index` (0–99) into the request list and a required human-readable `reason` string; a failed entry does not prevent other entries from being created. Non-breaking; additive (new endpoint). * Capped bulk alert operations at 100 items per request. In the `PUT /alerts/alerts/v3/all/replace` request body, the `alertDefsToReplace` array now accepts at most 100 items (previously up to 1000); requests with more than 100 items are rejected, and an empty array remains valid. This is a breaking change for callers that sent more than 100 alert definitions in a single request — split such requests into batches of at most 100. Batching is safe: the operation updates only the alert definitions referenced in the request (matched by `id`) and leaves all others unchanged, so consecutive batches do not overwrite each other. The operation description has been clarified accordingly, and now also states that the operation is best-effort — entries that fail are reported in the response arrays (`notFoundIds`, `failedToReplaceAlertDefs`, `skippedIds`) and do not prevent other entries from being applied. These description updates document existing service behavior; the wire behavior is unchanged. Additionally, each item in the `failedToReplaceAlertDefs` response array now documents an optional `reason` string explaining why the entry failed to be replaced; the field may be omitted when no further detail is available. Non-breaking; additive. The bulk-delete request limit on `POST /alerts/alerts/v3/all/delete` is unchanged (`ids` already accepted 1–100 items). Accordingly, the documented maximum size of the bulk response arrays dropped from 1000 to 100 items: `alertDefs`, `failedToReplaceAlertDefs`, `notFoundIds`, and `skippedIds` in the `PUT /alerts/alerts/v3/all/replace` response, and `deletedIds` and `notFoundIds` in the `POST /alerts/alerts/v3/all/delete` response. Non-breaking on the response side. * Added an optional `microsoftTeams` object to the comment case event payload — a sibling of the existing `slack` object — carrying Microsoft Teams source metadata for the comment. In the response bodies it appears at `event.eventData.comment.microsoftTeams` in `POST /cases/cases/v1/{case_id}/comments` (create comment), `GET /cases/events/v1/{event_id}` (get event), and `PUT /cases/events/v1/{event_id}/comments` (update comment), and at `events[].eventData.comment.microsoftTeams` in `GET /cases/cases/v1/{case_id}/events` (list case events). The object holds optional string fields `tenantId` (a UUID), `teamId`, `channelId`, `messageId`, `userId`, `userEmail`, and `messageUrl`. Non-breaking; additive. * Added an `OLLY_SCHEDULED_TASKS` value to the notification-center `EntityType` string enum, which now holds `ENTITY_TYPE_UNSPECIFIED`, `ALERTS`, `TEST_NOTIFICATIONS`, `CASES`, and `OLLY_SCHEDULED_TASKS`. Non-breaking; additive. The enum is reachable across the notification-center REST API as follows: * **Entity types**: `GET /notifications/notification-center/v1/entity-types` returns it as a possible value in the response `entityTypes[]` array; the `entity_type` path parameter on `GET /notifications/notification-center/v1/entity-types/{entity_type}/attachment-types` and `GET /notifications/notification-center/v1/entity-types/{entity_type}/entity-subtypes` also accepts it. * **Connectors**: the `configOverrides[].entityType` field accepts it in the request body of `POST /notifications/notification-center/v1/connectors` (create) and `PUT /notifications/notification-center/v1/connectors` (replace), and appears in the response body of those two plus `GET /notifications/notification-center/v1/connectors` (list), `GET /notifications/notification-center/v1/connectors/{id}` (get), `GET /notifications/notification-center/v1/connectors/all/list` (batch-get), `GET /notifications/notification-center/v1/connectors/all/summaries` (batch-get summaries), and `GET /notifications/notification-center/v1/connectors/list/summaries` (list summaries). The `supported_by_entity_type` query parameter on `GET /notifications/notification-center/v1/connectors`, `GET /notifications/notification-center/v1/connectors/list/summaries`, and `GET /notifications/notification-center/v1/connectors/types/summaries` also accepts it. The request body's `entityType` field on `POST /notifications/notification-center/v1/connectors:testConfig` and `POST /notifications/notification-center/v1/destinations:test` accepts it too. * **Presets**: the `entityType` field accepts it in the request body of `POST /notifications/notification-center/v1/presets:createCustom` (create custom) and `PUT /notifications/notification-center/v1/presets:replaceCustom` (replace custom), and appears in the response body of those two plus `GET /notifications/notification-center/v1/presets` (batch-get) and `GET /notifications/notification-center/v1/presets/{id}` (get). The `entity_type` query parameter, and the returned preset summary's `entityType` field, on `GET /notifications/notification-center/v1/presets/summaries/system` (system default summary), `GET /notifications/notification-center/v1/presets:getDefaultSummary` (default summary), and `GET /notifications/notification-center/v1/presets:summariesList` (list summaries) also accept/return it. The request body's `entityType` field on `POST /notifications/notification-center/v1/presets:test` and `POST /notifications/notification-center/v1/presets:testConfig` accepts it too. * **Routers**: the `entityType` field, plus the nested `rules[].entityType` and `fallbackTargets[].entityType` fields, accept it in the request body of `POST /notifications/notification-center/v1/routers` (create) and `PUT /notifications/notification-center/v1/routers` (replace), and appear in the response body of those two plus `GET /notifications/notification-center/v1/routers` (list), `GET /notifications/notification-center/v1/routers/{id}` (get), and `GET /notifications/notification-center/v1/routers/all/summaries` (batch-get). The `entity_type` query parameter on `GET /notifications/notification-center/v1/routers` also accepts it. * **Testing**: the request body's `entityType` field on `POST /notifications/notification-center/v1/routers:testCondition` and `POST /notifications/notification-center/v1/templates:test` accepts it too. * Added optional per-alert access-policy support to the alerts REST API. Non-breaking; additive. * **Write requests**: an optional `accessPolicy` string (raw access-policy JSON, 0–65536 characters) in the `POST /alerts/alerts/v3` (create) request body; and an optional `accessPolicy` object in the `PUT /alerts/alerts/v3` (replace) request body and in each item of the `alertDefsToReplace` array in the `PUT /alerts/alerts/v3/all/replace` (bulk replace) request body. That object is a choice of either `upsert` (a raw access-policy JSON string, 0–65536 characters) or `delete` (an empty object that removes the alert's access policy entirely — after removal a new policy and policy owner can be assigned); omitting `accessPolicy` leaves the current policy unchanged. Setting or changing `accessPolicy` requires the `alerts:UpdateAccessPolicy` permission. * **Read requests**: an optional `include_access_permissions` boolean query parameter on `GET /alerts/alerts/v3/{id}`, `GET /alerts/alerts/v3/version-ids/{alert_version_id}`, and `GET /alerts/alerts/v3` (list). It defaults to `false`; the response `access` is populated only when `include_access_permissions` is `true`. * **Read responses**: an optional `access` object in the `GET /alerts/alerts/v3/{id}` and `GET /alerts/alerts/v3/version-ids/{alert_version_id}` response bodies, and an `access` object map keyed by alert-definition ID in the `GET /alerts/alerts/v3` (list) response body. Each `access` value holds an optional `permissions` object (booleans `canRead`, `canManage`, `canReadAccessPolicy`, `canUpdateAccessPolicy`) and an optional `accessPolicy` string (the alert's raw access-policy JSON, 0–65536 characters, present only when the caller may read it). * Added an optional `notFoundIds` field (an array of up to 1000 UUID strings) to the `GET /alerts/alerts/v3/all/download` (download alerts) response, populated on the first streamed message with any requested `ids` that were not included in the download because they were not found or are not accessible; it is absent/empty when every requested id was downloaded or when no ids were requested. Non-breaking; additive. * Added an optional `ids` query parameter (an array of up to 1000 UUID strings) to `GET /alerts/alerts/v3/all/download` (download alerts). When provided, only the listed alert definitions are downloaded, and ids that are not found or not accessible are reported in the response `notFoundIds`; when omitted, all accessible alert definitions are downloaded (unchanged default). Non-breaking; additive. * Added an optional `submittedStartTime` string to the suppression-rule schedule timeframe (`schedule.oneTime.timeframe` and `schedule.recurring.schedule.timeframe` in the rule payload) across the suppression-rules API (`POST` and `PUT /alerts/suppression-rules/v1`, `POST` and `PUT /alerts/suppression-rules/v1/all/rules`, `GET /alerts/suppression-rules/v1`, and `GET /alerts/suppression-rules/v1/{alert_scheduler_rule_id}`). The service populates it only in create and update responses (`POST`/`PUT`, including the bulk paths), echoing the `startTime` submitted in the request before the service normalized it to the next valid occurrence; it is a read-only echo — ignored in requests and omitted from `GET` responses. Non-breaking; additive. * Documented existing validation bounds on the alerts and alert-event REST APIs (`minLength`/`maxLength`/`pattern` on strings, `minimum`/`maximum` on integers, `minItems`/`maxItems` on arrays). The constraints describe validation the service already enforces; values outside them were already rejected, so this is non-breaking. By field: * **Alert-definition properties** — request bodies of `POST /alerts/alerts/v3` and `PUT /alerts/alerts/v3`, and response bodies of `GET /alerts/alerts/v3` and `GET /alerts/alerts/v3/{id}`: `alertDefProperties.name` string 1–512; `alertDefProperties.description` string 0–3000; `alertDefProperties.groupByKeys` array 0–100 items, each string 1–1024; `alertDefProperties.dataSources` array 0–1 items, each with `dataSpace` string 1–50 and `dataSet` string 1–300; `alertDefProperties.notificationGroupExcess` array ≤100 items. * **Condition / type-definition fields** (same request and response bodies): `evaluationDelayMs` integer 0–10800000; metric `metricFilter.promql` and analytics `dataprimeQuery.query` string 1–65535; metric `forOverPct` and `minNonNullValuesPct` integer 0–100; logs-ratio `numeratorAlias` / `denominatorAlias` string ≤200; `noDataPolicy.autoRetireSeconds` integer ≥60. * **Notification group & schedule** (same bodies): incident-settings/webhook `retriggeringPeriod.minutes` integer 1–10080; schedule `activeOn.startTime` / `endTime` `hours` 0–23 and `minutes` 0–59; `dayOfWeek` array 1–7 items. * **Identifiers**: the `id` path parameter on `GET /alerts/alerts/v3/{id}` and `DELETE /alerts/alerts/v3/{id}` is a UUID string (`maxLength: 36`, canonical UUID pattern); the `alertVersionId` path parameter on `GET /alerts/alerts/v3/version-ids/{alert_version_id}` and the `AlertDef.alertVersionId` response field are 1–36 free-form strings; the response `AlertDef.id` is a UUID string 1–36; response `AlertDef.createdTime` / `updatedTime` / `lastTriggeredTime` strings ≤64. * **Bulk operations**: `POST /alerts/alerts/v3/all/delete` request `ids` array 1–100 items, each a UUID string 1–36; `PUT /alerts/alerts/v3/all/replace` request `alertDefsToReplace[].id` a UUID string 1–36; bulk response id arrays (`notFoundIds`, `deletedIds`, `skippedIds`) ≤100 UUID-string items. * **Pagination** (list endpoints): request `pageSize` integer 0–1000 and `pageToken` string 1–4096; response `alertDefs` array ≤1000 items. * **Filter option counts** — `GET /alerts/alerts/v3/all/counts` response: the per-bucket `count` integers (`typeCounts[].count`, `priorityCounts[].count`, `statusCounts[].count`, `enabledCounts[].count`, `entityLabelCounts[].count`) are 0–4294967295. * **Alert events**: `GET /v3/alert-event/{id}` `id` path parameter free-form string 1–36; `GET /v3/alert-event-stats` request `ids` array ≤1000 free-form strings 1–36; response `AlertEvent.alertId` a UUID string 1–36, and `permutationId` / `preGroupingEventId` / `incidentCorrelationKey` / `payloadType` strings ≤256; event-stats `count` / `resolvedCount` / `triggeredCount` / `isMutedCount` integers 0–4294967295. * Added documented validation constraints across the events-to-metrics REST API (`POST`, `GET`, and `PUT` on `/events2metrics/events2metrics/v2`; `GET` and `DELETE` on `/events2metrics/events2metrics/v2/{id}`; `POST /events2metrics/events2metrics/v2/all/execute`; `GET /events2metrics/labels/v2/cardinalities`; and `GET /events2metrics/limits/v2`). String fields now declare `minLength`, `maxLength`, and `pattern`; integer fields declare `minimum` and `maximum`; and array fields declare `minItems` and `maxItems`. This covers request and response fields including `name`, `description`, `dataSource`, `permutationsLimit`, `metricLabels` (items include `targetLabel`, `sourceField`), `metricFields` (items include `targetBaseMetricName`, `sourceField`, `aggregations`, `targetMetricName`), and the nested query fields: logs query (`lucene`, `alias`, `applicationnameFilters`, `subsystemnameFilters`, `severityFilters`) and spans query (`lucene`, `applicationnameFilters`, `subsystemnameFilters`, `actionFilters`, `serviceFilters`), plus `companyId`, `labelsLimit`, and the `id` identifiers. Non-breaking; constraints describe the values the service already accepts. * Added `PUT /dataplans/rum-policies/v1` to manage RUM TCO policies as an atomic overwrite: it deletes all existing RUM policies and creates the provided list in order, mirroring `PUT /dataplans/log-policies/v1` and `PUT /dataplans/span-policies/v1`. The request body holds a `policies` array (at most 10000 items); each item carries a required `policy` object (required `name`, `description`, and `priority`; optional `applicationRule`, `subsystemRule`, `archiveRetention`, `priorityOverride`, `targets`, and `disabled`) and a required `rumRules` object with the same shape as `logRules` (a `severities` array and an optional `dpxlExpression` string). The response holds a `createResponses` array; each item contains the created `policy`. Non-breaking; additive. * Added a `SOURCE_TYPE_RUM` value to the TCO policy source-type string enum, which now holds `SOURCE_TYPE_UNSPECIFIED`, `SOURCE_TYPE_LOGS`, `SOURCE_TYPE_SPANS`, and `SOURCE_TYPE_RUM` — accepted by the `source_type` query parameter on `GET /dataplans/policies/v1` (list) and the `sourceType` field in the `POST /dataplans/policies/v1/all/reorder` request body — and an optional `rumRules` object to the policy source-type choice (alongside `logRules` and `spanRules`) in the policy payload returned by `GET /dataplans/policies/v1` (list), `GET /dataplans/policies/v1/{id}`, the `POST`/`PUT /dataplans/policies/v1` responses, `PUT /dataplans/rum-policies/v1` (replace RUM policies), `PUT /dataplans/log-policies/v1` (replace log policies), `PUT /dataplans/span-policies/v1` (replace span policies), and `POST /dataplans/policies/v1/all/test-policies` (test policies). `rumRules` has the same shape as `logRules` — a `severities` array and an optional `dpxlExpression` string. Non-breaking; additive. * Added an optional `rumRules` object to the policy source-type choice (alongside `logRules` and `spanRules`) in the request bodies of `POST /dataplans/policies/v1` (create), `PUT /dataplans/policies/v1` (update), and `POST /dataplans/policies/v1/all/forecast-usage` (forecast usage), so RUM policies can also be created, updated, and forecast individually. Non-breaking; additive. * Documented existing validation bounds on the alerts and alert-event REST APIs (`minLength`/`maxLength`/`pattern` on strings, `minimum`/`maximum` on integers, `minItems`/`maxItems` on arrays). The constraints describe validation the service already enforces; values outside them were already rejected, so this is non-breaking. By field: * **Alert-definition properties** — request bodies of `POST /alerts/alerts/v3` and `PUT /alerts/alerts/v3`, and response bodies of `GET /alerts/alerts/v3` and `GET /alerts/alerts/v3/{id}`: `alertDefProperties.name` string 1–512; `alertDefProperties.description` string 0–3000; `alertDefProperties.groupByKeys` array 0–100 items, each string 1–1024; `alertDefProperties.dataSources` array 0–1 items, each with `dataSpace` string 1–50 and `dataSet` string 1–300; `alertDefProperties.notificationGroupExcess` array ≤100 items. * **Condition / type-definition fields** (same request and response bodies): `evaluationDelayMs` integer 0–10800000; metric `metricFilter.promql` and analytics `dataprimeQuery.query` string 1–65535; metric `forOverPct` and `minNonNullValuesPct` integer 0–100; logs-ratio `numeratorAlias` / `denominatorAlias` string ≤200; `noDataPolicy.autoRetireSeconds` integer ≥60. * **Notification group & schedule** (same bodies): incident-settings/webhook `retriggeringPeriod.minutes` integer 1–10080; schedule `activeOn.startTime` / `endTime` `hours` 0–23 and `minutes` 0–59; `dayOfWeek` array 1–7 items. * **Identifiers**: the `id` path parameter on `GET /alerts/alerts/v3/{id}` and `DELETE /alerts/alerts/v3/{id}` is a UUID string (`maxLength: 36`, canonical UUID pattern); the `alertVersionId` path parameter on `GET /alerts/alerts/v3/version-ids/{alert_version_id}` and the `AlertDef.alertVersionId` response field are 1–36 free-form strings; the response `AlertDef.id` is a UUID string 1–36; response `AlertDef.createdTime` / `updatedTime` / `lastTriggeredTime` strings ≤64. * **Bulk operations**: `POST /alerts/alerts/v3/all/delete` request `ids` array 1–100 items, each a UUID string 1–36; `PUT /alerts/alerts/v3/all/replace` request `alertDefsToReplace[].id` a UUID string 1–36; bulk response id arrays (`notFoundIds`, `deletedIds`, `skippedIds`) ≤1000 UUID-string items. * **Pagination** (list endpoints): request `pageSize` integer 0–1000 and `pageToken` string 1–4096; response `alertDefs` array ≤1000 items. * **Filter option counts** — `GET /alerts/alerts/v3/all/counts` response: the per-bucket `count` integers (`typeCounts[].count`, `priorityCounts[].count`, `statusCounts[].count`, `enabledCounts[].count`, `entityLabelCounts[].count`) are 0–4294967295. * **Alert events**: `GET /v3/alert-event/{id}` `id` path parameter free-form string 1–36; `GET /v3/alert-event-stats` request `ids` array ≤1000 free-form strings 1–36; response `AlertEvent.alertId` a UUID string 1–36, and `permutationId` / `preGroupingEventId` / `incidentCorrelationKey` / `payloadType` strings ≤256; event-stats `count` / `resolvedCount` / `triggeredCount` / `isMutedCount` integers 0–4294967295. * Added non-breaking OpenAPI validation metadata to existing views and folders REST payloads; no endpoints, JSON fields, or field requiredness changed. For view payloads in `POST /data-exploration/views/v1/views`, `PUT /data-exploration/views/v1/views/{id}`, `GET /data-exploration/views/v1/views`, and `GET /data-exploration/views/v1/views/{id}`, the spec now documents bounds for `id` integer (`1..2147483647`, where present), `name` string (`1..250`), `searchQuery.query` string (`1..65535`), `filters.filters` array (`1..1000`), `filters.filters[].name` string (`1..65535`), `timeSelection.quickSelection.caption` string (`1..100`), `timeSelection.quickSelection.seconds` integer (`0..4294967295`), and `timeSelection.customSelection.fromTime` / `timeSelection.customSelection.toTime` date-time strings (`1..35`). The shared `id` path parameter on `GET`, `PUT`, and `DELETE /data-exploration/views/v1/views/{id}` is also documented as integer `1..2147483647`; the `views` response array on `GET /data-exploration/views/v1/views` is documented as `0..100000` items. For folder payloads in `POST /data-exploration/views/v1/folders`, `PUT /data-exploration/views/v1/folders`, `GET /data-exploration/views/v1/folders`, and `GET /data-exploration/views/v1/folders/{id}`, the spec now documents `name` string bounds (`1..100`) and the `folders` response array bounds (`0..100000` items). * Added an optional `arcDisplay` object (with `valueArc` and `thresholdArc` booleans) and an optional `showMinMax` boolean to the gauge widget and the dynamic-widget gauge visualization inside the dashboard payload. The fields appear in the request body of `POST /dashboards/dashboards/v1` and `PUT /dashboards/dashboards/v1`, and in the dashboard read responses of `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. The presence of `arcDisplay` indicates the gauge arcs are shown; omitting it hides them. Deprecated the `showInnerArc` and `showOuterArc` booleans on both gauges. Non-breaking; omitting the new fields preserves existing behavior. * Added optional `dpxlExpression` string to the span-rules object (`spanRules`) in the quota policy payload, mirroring the existing `dpxlExpression` on log rules. It appears in the request bodies of `POST /dataplans/policies/v1` (create), `PUT /dataplans/policies/v1` (update), `PUT /dataplans/span-policies/v1` (replace span policies), and `POST /dataplans/policies/v1/all/forecast-usage` (forecast usage); and in the response payloads of `GET /dataplans/policies/v1/{id}`, `GET /dataplans/policies/v1` (list), the `POST`/`PUT /dataplans/policies/v1` responses, `PUT /dataplans/span-policies/v1` (replace span policies), `PUT /dataplans/log-policies/v1` (replace log policies), and `POST /dataplans/policies/v1/all/test-policies` (test policies). Optional and non-breaking. * Breaking OpenAPI schema change for `/logs/data-setup/v2`: in the `POST` request body, the `s3` object is now documented as required alongside `isActive`, matching existing server-side validation. In the `GET` and `POST` 200 response bodies, `target.archiveSpec` is now documented as required. This is an OpenAPI contract clarification only; the REST wire behavior is unchanged. * Added optional `histogramBucketUnit` string enum to the dynamic heatmap widget's `heatmap` visualization object. It is accepted in dashboard request widgets for `POST /dashboards/check/v1`, `POST /dashboards/dashboards/v1`, and `PUT /dashboards/dashboards/v1`, and returned in dashboard response widgets from `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. Values are `HEATMAP_HISTOGRAM_BUCKET_UNIT_UNSPECIFIED`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_NANOSECONDS`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_MICROSECONDS`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_MILLISECONDS`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_SECONDS`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_BYTES_IEC`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_KIBYTES`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_MIBYTES`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_GIBYTES`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_BYTES`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_KBYTES`, `HEATMAP_HISTOGRAM_BUCKET_UNIT_MBYTES`, and `HEATMAP_HISTOGRAM_BUCKET_UNIT_GBYTES`. Non-breaking; omitting it preserves existing behavior. * Added documented validation constraints across the dashboards REST API: `POST /dashboards/check/v1`; `POST` and `PUT` on `/dashboards/dashboards/v1`; `GET` and `DELETE` on `/dashboards/dashboards/v1/{dashboard_id}`; `GET /dashboards/dashboards/v1/catalog/list`; `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`; `PUT /dashboards/dashboards/v1/{dashboard_id}/default`; `POST /dashboards/dashboards/v1/{dashboard_id}/folder`; `GET`, `POST`, and `PUT` on `/dashboards/folders/v1`; `GET` and `DELETE` on `/dashboards/folders/v1/{folder_id}`; and `PUT` and `DELETE` on `/dashboards/pinned/v1/{dashboard_id}`. String, array, and integer fields throughout the dashboard, folder, and widget request and response payloads now declare `minLength`/`maxLength`/`pattern`, `minItems`/`maxItems`, and `minimum`/`maximum` limits. Specifically: * Dashboard identifiers are 21-character strings: the `dashboard_id` path parameter on `PUT /dashboards/dashboards/v1/{dashboard_id}/default` and `POST /dashboards/dashboards/v1/{dashboard_id}/folder`, the `dashboardId` in the `POST /dashboards/dashboards/v1` response, each catalog item's `id` in the `GET /dashboards/dashboards/v1/catalog/list` response, and the dashboard body's `id` (string) all require exactly 21 characters. * Folder and annotation identifiers are UUID strings (36 characters, canonical UUID pattern): a folder's `id` and `parentId` and the `POST /dashboards/folders/v1` response's `folderId`, and each dashboard annotation's `id` together with its action `id` and `widgetId`. * Annotation, folder, and variable `name` and variable `displayName` strings are limited to 1–100 characters. * Annotation-source `messageTemplate` strings are limited to 0–1000 characters, and their `labelFields`/`labels` arrays to at most 10 items. * A folder `path`'s `segments` array holds 1–2 items, each a 1–100-character string. * The `accessPolicy` string in the `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}` responses accepts an empty string (`minLength: 0`). * The line chart's `queryDefinitions` array declares `minItems: 1`. Widget, section, row, filter, and variable `id` fields are UUID strings (36 characters, canonical UUID pattern). * The `slug` path parameter on `GET /dashboards/dashboards/v1/slugs/lookup/{slug}` is limited to 1–255 characters; the `request_id` query parameter on `DELETE /dashboards/dashboards/v1/{dashboard_id}`, `GET` and `DELETE` on `/dashboards/folders/v1/{folder_id}`, and `PUT` and `DELETE` on `/dashboards/pinned/v1/{dashboard_id}` is limited to 1–128 characters. * The data-usage query API is now public: the following endpoints now appear in the public OpenAPI spec and customer-facing docs. `POST /dataplan/data-usage/v1/query` returns billable usage aggregated into daily or hourly buckets and supports filtering and grouping by labels. `GET /dataplan/data-usage/v1/capabilities` returns the supported labels, measurement kinds, units, and per-request limits. Both require the `data-usage:Read` permission. Additive; no request or response shapes changed. * Added documented validation constraints on the recording rules REST API (`POST`, `GET`, `PUT`, and `DELETE` on `/recording-rules/recording-rules/v1`). Request and response fields now declare string length and pattern limits, integer ranges, and array size bounds; nested `groups[].name`, `groups[].rules[].record`, and `groups[].rules[].expr` are required on create and update, and `id` is required on create responses and on items returned by list and get. The `id` path parameter on get, update, and delete is limited to 1–128 characters. Non-breaking. * Added `GET /notifications/notification-center/v1/entity-types/{entity_type}/attachment-types` (List Entity Type Attachment Types). Returns all supported attachment types for the given entity type. The response body contains `supportedAttachmentTypes` (array, 0–100 items), where each item is `{ "name": string, "defaultEnabled": boolean }` — `name` is the attachment type identifier (e.g. `"alert_graph"`) and `defaultEnabled` indicates whether the type is included by default when the policy is `AUTO`. Non-breaking; new endpoint. * Added the time-to-update KPI to Cases. The `KPIType` string enum now contains `KPI_TYPE_UNSPECIFIED`, `KPI_TYPE_TIME_TO_ACKNOWLEDGE`, `KPI_TYPE_TIME_TO_RESOLVE`, and `KPI_TYPE_TIME_TO_UPDATE`. * `caseLifecycle.kpi.thresholds[].type` in the request bodies for `POST /cases/cases/case-settings/v1/configs` and `PATCH /cases/cases/case-settings/v1/configs/{id}`. * `caseSettings.caseLifecycle.kpi.thresholds[].type` in the response bodies from `POST /cases/cases/case-settings/v1/configs`, `GET /cases/cases/case-settings/v1/configs/{id}`, `PATCH /cases/cases/case-settings/v1/configs/{id}`, and `GET /cases/cases/case-settings/v1/configs:getActive`; and `caseLifecycle.kpi.thresholds[].type` in the response body from `GET /cases/cases/case-settings/v1/configs:getSystemDefaults`. * `case.kpiBreaches.breachedKpis[].kpiType` in the response bodies from `GET /cases/cases/v1/{id}`, `PUT /cases/cases/v1/{id}`, `PUT /cases/acknowledged/v1/{id}`, `DELETE /cases/acknowledged/v1/{id}`, `POST /cases/assigned/v1/{id}`, `DELETE /cases/assigned/v1/{id}`, `POST /cases/closed/v1/{id}`, `POST /cases/indicators/v1/get`, `PUT /cases/priority-override/v1/{id}`, `DELETE /cases/priority-override/v1/{id}`, and `PUT /cases/resolved/v1/{id}`. * `cases[].kpiBreaches.breachedKpis[].kpiType` in the response bodies from `POST /cases/cases/v1`, `POST /cases/acknowledged/v1`, `PUT /cases/assigned/v1`, `DELETE /cases/assigned/v1`, `POST /cases/closed/v1`, `POST /cases/priority-override/v1`, `DELETE /cases/priority-override/v1`, and `POST /cases/resolved/v1`. * `event.eventData.kpiBreached.kpiType` in the response bodies from `POST /cases/cases/v1/{case_id}/comments`, `GET /cases/events/v1/{event_id}`, and `PUT /cases/events/v1/{event_id}/comments`; and `events[].eventData.kpiBreached.kpiType` in the response body from `GET /cases/cases/v1/{case_id}/events`. * The `KPIFilter` string enum used by optional `filters.breached[]` arrays in the request bodies for `POST /cases/cases/v1` and `POST /cases/filter-values/v1` now contains `KPI_FILTER_UNSPECIFIED`, `KPI_FILTER_TIME_TO_ACKNOWLEDGE_BREACHED`, `KPI_FILTER_TIME_TO_RESOLVE_BREACHED`, `KPI_FILTER_NOT_BREACHED`, and `KPI_FILTER_TIME_TO_UPDATE_BREACHED`. Non-breaking. * Error responses (`400`, `401`, `403`, `404`, `409`, `500`) across the Management API now document their `application/json` body with an `Error` schema, where previously the body carried no schema. `Error` is `{ "code": integer, "message": string }` — `code` is the HTTP status code (100–599) and `message` is a human-readable description. Response-only; non-breaking. * `PUT /aaa/custom-roles/v1` (create custom role) no longer documents a `201` response; a successful create returns `200` with `{ "id": integer }` — the new role's identifier. * `DELETE /aaa/custom-roles/v1/{role_id}` (delete custom role) `204` response no longer declares an `application/json` body, matching its no-content semantics. * Added explicit validation bounds to request fields and response arrays across the notification-center REST APIs (`/notifications/notification-center/v1/connectors`, `/notifications/notification-center/v1/presets`, `/notifications/notification-center/v1/routers`). Specifics: * The `id` path parameter on `GET /notifications/notification-center/v1/connectors/{id}`, `DELETE /notifications/notification-center/v1/connectors/{id}`, `GET /notifications/notification-center/v1/presets/{id}`, `DELETE /notifications/notification-center/v1/presets/custom/{id}`, `POST /notifications/notification-center/v1/presets/custom/{id}/default`, `POST /notifications/notification-center/v1/presets/{id}/default/apply`, `GET /notifications/notification-center/v1/routers/{id}`, and `DELETE /notifications/notification-center/v1/routers/{id}` now has `minLength: 1`, `maxLength: 128`, and pattern `^[a-zA-Z0-9][a-zA-Z0-9_-]*$`. * String request fields including `name`, `id`, `connectorId`, `presetId`, `payloadType`, `fieldName`, `template`, and `description` in the request bodies of `POST /notifications/notification-center/v1/connectors`, `PUT /notifications/notification-center/v1/connectors`, `POST /notifications/notification-center/v1/presets:createCustom`, `PUT /notifications/notification-center/v1/presets:replaceCustom`, `POST /notifications/notification-center/v1/routers`, `PUT /notifications/notification-center/v1/routers`, and related `:test`/`:testConfig` endpoints now have `minLength`, `maxLength`, and `pattern` in the spec. * Response arrays on `GET /notifications/notification-center/v1/connectors/all/list`, `GET /notifications/notification-center/v1/connectors/all/summaries`, `GET /notifications/notification-center/v1/presets`, `GET /notifications/notification-center/v1/routers`, and `GET /notifications/notification-center/v1/routers/all/summaries` now have `maxItems` bounds. * Added a Microsoft Teams actor variant to case event actors. The `microsoftTeams` actor carries `teamsUserId` (string), `displayName` (string), optional `userEmail` (string), and optional `coralogixUserId` (string, UUID). It appears in the `actor` field of events returned by `GET /cases/cases/v1/{case_id}/events`, in the `event` field of responses from `POST /cases/cases/v1/{case_id}/comments`, `GET /cases/events/v1/{event_id}`, and `PUT /cases/events/v1/{event_id}/comments`. Response-only; non-breaking. * Added a `microsoftTeams` resolver variant to `resolvedBy` in the `ResolutionDetails` object in case responses. The variant is an empty marker object indicating the case was resolved through a Microsoft Teams connector. It appears wherever a `case` object is returned: `GET /cases/cases/v1/{id}`, `PUT /cases/cases/v1/{id}`, `POST /cases/cases/v1` (list); `PUT /cases/acknowledged/v1/{id}`, `DELETE /cases/acknowledged/v1/{id}`, `POST /cases/acknowledged/v1` (bulk); `POST /cases/assigned/v1/{id}`, `DELETE /cases/assigned/v1/{id}`, `PUT /cases/assigned/v1` (bulk assign), `DELETE /cases/assigned/v1` (bulk unassign); `POST /cases/closed/v1/{id}`, `POST /cases/closed/v1` (bulk); `POST /cases/indicators/v1/get`; `PUT /cases/priority-override/v1/{id}`, `DELETE /cases/priority-override/v1/{id}`, `POST /cases/priority-override/v1` (bulk set), `DELETE /cases/priority-override/v1` (bulk clear); `PUT /cases/resolved/v1/{id}`, `POST /cases/resolved/v1` (bulk). Response-only; non-breaking. * Added optional `timeBucketMs` string to the request body of `POST /dataplans/policies/v1/all/forecast-usage` (forecast TCO policy usage). When set, the forecast is bucketed into intervals of the given millisecond width. Non-breaking; omitting it preserves existing behavior. * Added optional `usageBuckets` array to the response of `POST /dataplans/policies/v1/all/forecast-usage` (forecast TCO policy usage). Each item is `{ "bucketStartMs": string, "bytes": string }`, where `bucketStartMs` is the bucket window start in epoch milliseconds and `bytes` is the matched bytes within that bucket. Populated only when `timeBucketMs` is set on the request; otherwise empty. Non-breaking; `estimatedBytes` is unchanged. * Added company model pricing REST API under `/ai/model-pricing/v3` (company resolved from auth context; non-breaking, new endpoints). `GET /ai/model-pricing/v3` returns `{ "pricing": { "id": string (UUID), "companyId": string, "prices": object } }` where `prices` is keyed by model name and each value is `{ "inputPricePerMillionTokens": number, "outputPricePerMillionTokens": number, "cacheReadPricePerMillionTokens": number, "cacheWritePricePerMillionTokens": number }` (USD per one million tokens). `PUT /ai/model-pricing/v3` accepts request body `{ "prices": object (required) }` with the same per-model value shape as a full replacement map and returns `{ "pricing": { "id": string (UUID), "companyId": string, "prices": object } }`. `DELETE /ai/model-pricing/v3` returns `{ "id": string (UUID) }`. * Added `CONNECTOR_TYPE_MICROSOFT_TEAMS` to the `connectorType` enum in the cases connector type schema. The value appears in `connectorTypeFilters` in the request body of `POST /cases/cases/v1` (list cases) and `POST /cases/filter-values/v1`, and in the `connector` object within delivery attempts in the response of `POST /cases/notifications/v1/deliveries`. Non-breaking. * Added read-only `resolvedConnectorConfig` field to the `Connector` and `ConnectorSummary` response schemas in the notification-center connectors API. The field exposes the full effective connector configuration including backend auto-resolved values (e.g. a Slack integration ID). It is response-only and ignored on create/replace request bodies. It appears in `Connector` responses from `POST /notifications/notification-center/v1/connectors` (Create), `PUT /notifications/notification-center/v1/connectors` (Replace), `GET /notifications/notification-center/v1/connectors/{id}` (Get), `GET /notifications/notification-center/v1/connectors` (List), and `GET /notifications/notification-center/v1/connectors/all/list` (BatchGet); and in `ConnectorSummary` responses from `GET /notifications/notification-center/v1/connectors/all/summaries` (BatchGetConnectorSummaries) and `GET /notifications/notification-center/v1/connectors/list/summaries` (ListConnectorSummaries). Non-breaking. * Added optional `layoutColumns` integer to dashboard widgets in the request bodies for `POST /dashboards/check/v1`, `POST /dashboards/dashboards/v1`, and `PUT /dashboards/dashboards/v1`, and in the response payloads from `GET /dashboards/dashboards/v1/{dashboard_id}` and `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. Non-breaking; omitting it preserves existing layout behavior. * Added `POST /cases/indicators/v1/get` to return a `case` object for a source indicator. The request body supports a `prometheusAlert` object with required `fingerprint` string and `startedAt` date-time string. Non-breaking. * Added `minimum: 0` to the optional `threshold` number in AI evaluation payloads: request bodies for `POST /ai/evaluations/v3` and `PATCH /ai/evaluations/v3/{id}`, and response payloads from `GET /ai/evaluations/v3`, `GET /ai/evaluations/v3/{id}`, `POST /ai/evaluations/v3`, and `PATCH /ai/evaluations/v3/{id}`. Non-breaking; it documents the existing inclusive lower bound. * Added optional `genericIndicators` array under `caseIndicators` in the case response payloads returned by `GET /cases/cases/v1/{id}`, `PUT /cases/cases/v1/{id}`, and the list response from `POST /cases/cases/v1`. * Added optional `indicatorTypes` array to the `filters` object in the request body for `POST /cases/cases/v1`, allowing callers to filter the case list by indicator type. * Added a `MICROSOFT_TEAMS` value to the connector type enum in the connectors payload (`POST` / `PUT` `/notifications/notification-center/v1/connectors`), enabling notification routing to Microsoft Teams. * Added `POST /dashboards/check/v1` for validating a dashboard definition or an existing dashboard by ID without persisting changes. The response contains an `issues` array; each issue carries `severity` (enum: `SEVERITY_UNSPECIFIED`, `SEVERITY_ERROR`, `SEVERITY_WARNING`), `message` (string), and `location` (string, RFC 6901 JSON Pointer). The request body accepts either a `dashboard` object or `dashboardId` (string), and an optional `requestId` (string). Non-breaking; the endpoint is additive. * Added the AI Center v3 REST API for managing AI applications and AI evaluations: * **AI applications** — `GET /ai/applications/v3` (list), `GET /ai/applications/v3/{id}` (get), `DELETE /ai/applications/v3/{id}` (delete). * **AI evaluations** — `POST /ai/evaluations/v3` (create), `GET /ai/evaluations/v3` (list), `GET /ai/evaluations/v3/{id}` (get), `PATCH /ai/evaluations/v3/{id}` (update), `DELETE /ai/evaluations/v3/{id}` (delete), and `GET /ai/evaluation-counts/v3/per-type` (counts per evaluation type). * **Custom evaluations** — `POST /ai/custom-evaluations/v3` (create), `GET /ai/custom-evaluations/v3` (list), `PATCH /ai/custom-evaluations/v3/{id}` (update), `DELETE /ai/custom-evaluations/v3/{id}` (delete), `GET /ai/custom-evaluations/v3/by-application/{application_id}` (list for an application), and `POST` / `DELETE /ai/custom-evaluations/v3/{id}/applications/{application_id}` (link / unlink a custom evaluation to an application). * Added two analytics alert types to the alert payload, which appears in the request and/or response of the alert-definition endpoints: `POST /alerts/alerts/v3` (request and response), `PUT /alerts/alerts/v3` (request and response), `PUT /alerts/alerts/v3/all/replace` (request and response), `GET /alerts/alerts/v3` (response), `GET /alerts/alerts/v3/{id}` (response), and `GET /alerts/alerts/v3/version-ids/{alert_version_id}` (response). The alert type-definition object gains an `analyticsImmediate` variant (fires when a DataPrime query returns a result) and an `analyticsThreshold` variant (fires when a numeric result column violates a threshold). Both carry a `dataprimeQuery` object, `useRowsAsPermutations` (boolean), `evaluationDelayMs` (integer), `noDataPolicy` (object), and `timeframeMinutes` (integer); `analyticsThreshold` additionally carries a `rules` array (1–5 items), a `targetColumn` (string), and an `operator` enum (`ANALYTICS_THRESHOLD_OPERATOR_MORE_THAN_OR_UNSPECIFIED`, `ANALYTICS_THRESHOLD_OPERATOR_LESS_THAN`, `ANALYTICS_THRESHOLD_OPERATOR_MORE_THAN_OR_EQUALS`, `ANALYTICS_THRESHOLD_OPERATOR_LESS_THAN_OR_EQUALS`, `ANALYTICS_THRESHOLD_OPERATOR_EQUALS`). The `type` enum on the same payload gains `ALERT_DEF_TYPE_ANALYTICS_IMMEDIATE` and `ALERT_DEF_TYPE_ANALYTICS_THRESHOLD`. Optional and non-breaking. * **Breaking:** Removed the `Extension testing service` REST API: `POST /integrations/testing/v1/extensions/initialize`, `DELETE /integrations/testing/v1/extensions`, and `POST /integrations/testing/v1/extensions`. These operations are no longer available. * Added an optional `ollyAnalysis` object to the `Case` schema in case responses under `/cases/cases/v1`. Reports the result of an automated Olly analysis attached to a case (status, optional payload, completion timestamp). Response-only, non-breaking. * A path parameter shared by multiple operations on the same path is now declared once at the path level instead of being repeated on each operation. Purely structural and non-breaking — the same parameters apply to the same operations, so the request contract is unchanged. * Added optional `useDataTimeRange` boolean to the line-chart and time-series-lines widgets in the dashboard payload under `/dashboards/dashboards/v1`. When `true`, the widget derives its time window from the returned data instead of the dashboard time range — useful for time-shifted DataPrime queries (e.g. `addTime($m.timestamp, 14days)`) whose output timestamps fall outside the dashboard's selected window. Optional and non-breaking; omitting it preserves existing behavior. * **Breaking (spec contract):** Integer fields that carry 64-bit values are now declared as `type: string` with a digit `pattern` (`^[0-9]+$` unsigned, `^-?[0-9]+$` signed) and `minLength: 1` / `maxLength: 20`, instead of as numbers. This matches the actual JSON wire format — servers already emit and accept these values as quoted strings — so there is no runtime behavior change; only the declared type in the spec changes. * Array schemas now declare `minItems: 0` (on every array, regardless of item type) and unsigned integer fields declare `minimum: 0` by default in the spec. Additive and non-breaking (least-restrictive constraints); no runtime behavior change. * Added optional `dataspace` string to the policy target in the log, span, and generic TCO policy payloads (`/dataplans/log-policies/v1`, `/dataplans/span-policies/v1`, `/dataplans/policies/v1`), request and response. A free-form identifier for the target's dataspace, mirroring `dataset`. Non-breaking. * Added optional `priority` (enum: `PRIORITY_TYPE_UNSPECIFIED`, `PRIORITY_TYPE_BLOCK`, `PRIORITY_TYPE_LOW`, `PRIORITY_TYPE_MEDIUM`, `PRIORITY_TYPE_HIGH`), `priorityOverride` (object), and `archiveRetention` (object with an `id` string) to the policy target in the same log/span/generic policy payloads, request and response. Optional in the spec; server validation determines required semantics. Non-breaking. * 46 PUT/POST request bodies across the aaa, alerts, cases, dashboards, data-exploration, dataengine, dataplan(s), enrichment-rules, events2metrics, incidents, logs, metrics, and slo APIs are now declared `required` in the spec. Non-breaking — clients were already required to send these bodies; the spec now reflects it. * Added a PagerDuty actor variant to case event actors, returned at `GET /cases/cases/v1/{case_id}/events`. The `pagerDuty` actor carries `pagerDutyUserId` (string), `displayName` (string), optional `userEmail` (string), and optional `coralogixUserId` (string, UUID). Response-only; non-breaking. * Removed the optional `source` string from the APM-database impacted-entity in case responses under `/cases/cases/v1`. The field had no consumers. * Added optional `accessPolicy` string to the dashboard create/replace request bodies (`POST` / `PUT /dashboards/dashboards/v1`) and the dashboard get responses (`GET /dashboards/dashboards/v1/{dashboard_id}`, `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`), letting callers read and write a per-dashboard PBAC access policy (opaque JSON string). On create/replace a non-empty value sets the policy; omitting it leaves the policy unchanged. Non-breaking. * Added a PromQL variant to the dashboard variable query source in the dashboard payload under `/dashboards/dashboards/v1`. Variables can now be sourced from a PromQL query in addition to metric name, label name, and label value sources. The `promqlQuery` object carries the query string and an optional `promqlQueryType` enum (`PROM_QL_QUERY_TYPE_UNSPECIFIED`, `PROM_QL_QUERY_TYPE_RANGE`, `PROM_QL_QUERY_TYPE_INSTANT`) to opt into range queries. Non-breaking. * Added `resolvedValues` (array of strings) to the SLO ownership tag in the SLO payload under `/slo/slos/v1`, request and response. A flat, deduplicated union of the tag's static values and the values resolved from its label keys (empties excluded), giving a single searchable list regardless of source. Non-breaking. * Added Prometheus Alert Manager support to the cases responses. The case payload returned by `GET /cases/cases/v1/{id}` and the list at `POST /cases/cases/v1` gains a `prometheusAlertIndicators` array (an array of Prometheus alert indicator objects, under `caseIndicators`) listing the Prometheus alerts contributing to the case, and the case events list at `GET /cases/cases/v1/{case_id}/events` gains a `prometheusAlertManager` event-actor variant. Response-only; non-breaking. * **Breaking:** moved two `/integrations/*` endpoints to resolve OpenAPI path ambiguities. The legacy paths have been removed; clients must switch over. * `POST /integrations/contextual-data/v1/{integration_id}/test` → `POST /integrations/contextual-data/v1/test/{integration_id}`. * `GET /integrations/extensions/v1/{id}` → `GET /integrations/extensions/v1/catalog/{id}`. * Added `allocationType` (enum: `QUOTA_ALLOCATION_TYPE_UNSPECIFIED`, `QUOTA_ALLOCATION_TYPE_PERCENTAGE`, `QUOTA_ALLOCATION_TYPE_LOCKED_UNITS`) and `cxManaged` (boolean, response-only) to the quota allocation rule in the quota-rules payload under `/dataplan/quota-rules/v1`, letting quota rules distinguish percentage allocation from locked units and identify Coralogix-managed rules. Non-breaking. * Added `GET /cases/cases/v1/{case_id}/deep-links` for retrieving deep-link URLs from a case to related product views. * Added a `PAGERDUTY_INCIDENTS` value to the connector type enum in the connectors payload (`POST` / `PUT /notifications/notification-center/v1/connectors`), enabling notification routing to PagerDuty via the Incidents API. Non-breaking. * **Breaking:** removed the deprecated team-configs endpoints. The following paths have been deleted; clients must migrate to the equivalent case-settings paths under `/cases/cases/case-settings/v1/configs` (see the 2026-05-19 entry). * `POST /cases/cases/team-configs/v1/configs` * `GET /cases/cases/team-configs/v1/configs/{id}` * `PATCH /cases/cases/team-configs/v1/configs/{id}` * `DELETE /cases/cases/team-configs/v1/configs/{id}` * `GET /cases/cases/team-configs/v1/configs:getActive` * `GET /cases/cases/team-configs/v1/configs:getSystemDefaults` * Cases API is now public: the following endpoints now appear in the public OpenAPI spec and customer-facing docs. * `GET /cases/cases/v1/{id}` * `POST /cases/cases/v1` * `PUT /cases/cases/v1/{id}` * `PUT /cases/priority-override/v1/{id}` * `DELETE /cases/priority-override/v1/{id}` * `POST /cases/assigned/v1/{id}` * `DELETE /cases/assigned/v1/{id}` * `PUT /cases/acknowledged/v1/{id}` * `DELETE /cases/acknowledged/v1/{id}` * `POST /cases/closed/v1/{id}` * `PUT /cases/resolved/v1/{id}` * `POST /cases/filter-values/v1` * `PUT /cases/assigned/v1` * `DELETE /cases/assigned/v1` * `POST /cases/acknowledged/v1` * `POST /cases/resolved/v1` * `POST /cases/closed/v1` * `POST /cases/priority-override/v1` * `DELETE /cases/priority-override/v1` * `GET /cases/grouping-keys/v1` * Added a new public case-settings API for managing team-level case settings. It supersedes the team-configs endpoints, which are now deprecated and will be removed in a future release — clients should migrate to the new paths below. * `POST /cases/cases/case-settings/v1/configs` * `GET /cases/cases/case-settings/v1/configs/{id}` * `PATCH /cases/cases/case-settings/v1/configs/{id}` * `DELETE /cases/cases/case-settings/v1/configs/{id}` * `GET /cases/cases/case-settings/v1/configs:getActive` * `GET /cases/cases/case-settings/v1/configs:getSystemDefaults` * **Breaking:** moved five `/notifications/notification-center/v1/presets/*` endpoints to resolve OpenAPI path ambiguities with `/presets/{id}` and `/presets/{id}/default`. The legacy paths have been removed; clients must switch over. * `POST /notifications/notification-center/v1/presets/custom` → `POST /notifications/notification-center/v1/presets:createCustom`. * `PUT /notifications/notification-center/v1/presets/custom` → `PUT /notifications/notification-center/v1/presets:replaceCustom`. * `POST /notifications/notification-center/v1/presets/{id}/default` → `POST /notifications/notification-center/v1/presets/{id}/default/apply`. (This also resolves the `/notifications/notification-center/v1/presets/custom/{id}` collision, so `DELETE /notifications/notification-center/v1/presets/custom/{id}` keeps its existing path.) * `GET /notifications/notification-center/v1/presets/summaries` → `GET /notifications/notification-center/v1/presets:getDefaultSummary`. * `POST /notifications/notification-center/v1/presets/tests` → `POST /notifications/notification-center/v1/presets:test`. * **Breaking:** moved two cases team-config read endpoints to resolve OpenAPI path ambiguities with `/cases/cases/team-configs/v1/configs/{id}`. The legacy paths have been removed; clients must switch over. * `GET /cases/cases/team-configs/v1/configs/active` → `GET /cases/cases/team-configs/v1/configs:getActive`. * `GET /cases/cases/team-configs/v1/configs/system-defaults` → `GET /cases/cases/team-configs/v1/configs:getSystemDefaults`. * **Breaking:** moved three `/aaa/*` endpoints to resolve OpenAPI path ambiguities. The legacy paths have been removed; clients must switch over. * `GET /aaa/api-keys/v3/list` → `GET /aaa/api-keys/v3/list/all`. * `GET /aaa/team-groups/v2/{group_id}/users` → `GET /aaa/team-groups/v2/{group_id}/users/list`. * `PATCH /aaa/teams/v2/{team_id}/members/status` → `PATCH /aaa/teams/v2/{team_id}/members:updateStatuses`. * Added `POST /dataplans/policies/v1/all/forecast-usage`, which forecasts the usage in bytes of a draft TCO policy based on the bytes matched by its filter rules over a given time window. * **Breaking:** moved two dashboards read endpoints to new REST paths to resolve OpenAPI path ambiguities with `/dashboards/dashboards/v1/{dashboard_id}`. The legacy paths have been removed; clients must switch over. * `GET /dashboards/dashboards/v1/catalog` → `GET /dashboards/dashboards/v1/catalog/list`. * `GET /dashboards/dashboards/v1/slugs/{slug}` → `GET /dashboards/dashboards/v1/slugs/lookup/{slug}`. * Added optional `targets` (array, 1–10 items) to enrichments in the enrichment-rules payload under `/enrichment-rules/enrichment-rules/v1`, request and response. Each entry is an object with a `dataset` string, scoping the enrichment to specific datasets. Non-breaking. * Added optional `roleArn` and `externalId` strings to the S3 target spec in the archive setup payload under `/logs/data-setup/v2`, request and response, supporting `sts:AssumeRole` + external-ID cross-account S3 access. Non-breaking. * Added Cases KPI support across two cases payloads. Team-level KPI thresholds appear in the case-settings config under `caseLifecycle.kpi` (an object whose `thresholds` array holds the per-KPI settings) — written on `POST /cases/cases/case-settings/v1/configs` and `PATCH /cases/cases/case-settings/v1/configs/{id}`, and read on `GET /cases/cases/case-settings/v1/configs/{id}` (and the `:getActive` / `:getSystemDefaults` reads). Case-level breach data appears in the case payload as `kpiBreaches` (an object with a `breachedKpis` array; each entry carries `kpiType`, `casePriority`, `breachedAt`, and `breachStatus`) in the case payload returned by `GET /cases/cases/v1/{id}` and the list at `POST /cases/cases/v1`, response-only. Non-breaking. * Added optional `metadata` object (string-to-string map) to the success result of notification test endpoints (response), e.g. `POST /notifications/notification-center/v1/connectors:test`. Non-breaking. * Added optional `description` (string), `dpxlFilter` (string), and `urlFields` (array) to the action payload under `/actions/actions/v2`, request and response. Each `urlFields` entry is an object with `name` (string) and `required` (boolean). Non-breaking.