> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coralogix.com/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.

<Update label="v5.0.4 — July 20, 2026">
  * 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.
</Update>

<Update label="v5.0.3 — July 10, 2026">
  * 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.
</Update>

<Update label="v5.0.2 — June 30, 2026">
  * 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.
</Update>

<Update label="v5.0.1 — June 23, 2026">
  * 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.
</Update>

<Update label="June 22, 2026">
  * 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.
</Update>

<Update label="June 9, 2026">
  * 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.
</Update>