Changelog

Sep 2, 2026

• Preview (experimental). Added two optional geomap field-config variants, ibmRegionConfig and allRegionConfig, to the dashboard payload. Both are published at the preview stability tier and carry x-stability: preview in the OpenAPI document: they are usable and documented, but experimental. Preview elements are not covered by the backward-compatibility guarantee — they may change shape, be renamed, or be withdrawn in any release, and such a change is not announced as breaking. Do not depend on them in production integrations until they are promoted to stable, which will be its own changelog entry. They join the existing coordinateConfig and awsRegionConfig as alternatives in the geomap config object at dashboard.layout.sections[].rows[].widgets[].definition.dynamic.visualization.geomap.config, which accepts exactly one of the four. ibmRegionConfig takes a regionField whose data returns IBM Cloud region strings (e.g. us-south, eu-de); allRegionConfig takes a regionField whose data returns region strings from any supported cloud provider, aggregating every provider's regions. Non-breaking; additive — omitting both leaves existing geomap behaviour unchanged. The two variants are reachable across the dashboards REST API as follows:
  • Request bodies: POST /dashboards/dashboards/v1 (create) and PUT /dashboards/dashboards/v1 (replace) accept either variant inside the dashboard object, and POST /dashboards/check/v1 (validate) accepts them in the dashboard object it validates. None of these three returns a dashboard payload, so neither field appears in their response bodies.
  • Response bodies: both variants appear in the dashboard object returned by GET /dashboards/dashboards/v1/{dashboard_id} (get) and GET /dashboards/dashboards/v1/slugs/lookup/{slug} (get by URL slug). On GET /dashboards/dashboards/v1/{dashboard_id} they additionally appear in each entry of the resolvedWidgets map, at resolvedWidgets.{widgetId}.definition.dynamic.visualization.geomap.config.
• New endpoint GET /aaa/identity/v1/whoami resolves the identity behind the credentials used to call the API. It takes no parameters — the identity is derived entirely from the Authorization header — and returns the required integer teamId and string teamName always, plus the optional string teamUrl when the team has a web-app URL slug configured and the optional string username when the caller authenticates as a user. Authenticating with an API key resolves a team but no user, so username is absent in that case. Documented responses are 401 for missing or invalid credentials, 404 when the authenticated team no longer exists, and 500. Non-breaking; new surface.
• Team groups can now be created and updated by role name as an alternative to roleId. On POST /aaa/team-groups/v2 the request body accepts an optional string roleName (1-255 characters). On PUT /aaa/team-groups/v2/{group_id} the roleUpdate.action oneOf accepts a new setRoleByName branch, selected with actionType: "set_role_by_name" alongside the existing set_role_id and clear; the branch is an object with a single required string property value (1-255 characters), i.e. {"actionType": "set_role_by_name", "setRoleByName": {"value": "Platform Admin"}}. Names resolve against the team's own custom roles plus the global built-in roles, matching is case-insensitive, and the response reports the resolved role's id and canonical name. On create, roleName and roleId are mutually exclusive and setting both is rejected. An unmatched name returns 400, and so does a name matching more than one role in the team, with the colliding role ids named in the message rather than one being silently picked. Non-breaking; additive, and roleId remains the canonical form and the only one used in responses.
• POST /aaa/teams/v2/{team_id}/members now returns a per-user result instead of an empty body. The response gains results, an array of objects with one entry per requested user in request order. Each entry carries the required string username, echoing the request so callers can join on it rather than on position, and the enum status; where the outcome produced them it also carries the integer userAccountId and the string userId, plus the string message for outcomes a status alone cannot explain. Only username is required by the schema, so treat the others as optional. The status enum gains CREATE_USER_STATUS_ALREADY_INVITED, CREATE_USER_STATUS_DOMAIN_NOT_ALLOWED, and CREATE_USER_STATUS_FAILED, so its full set of accepted wire values is now CREATE_USER_STATUS_UNSPECIFIED, CREATE_USER_STATUS_CREATED, CREATE_USER_STATUS_ALREADY_EXISTS, CREATE_USER_STATUS_INVITED, CREATE_USER_STATUS_ALREADY_INVITED, CREATE_USER_STATUS_DOMAIN_NOT_ALLOWED, and CREATE_USER_STATUS_FAILED. Non-breaking; additive — the response schema previously declared no properties, so callers reading only the status code are unaffected. Note the operation is not atomic: the request is validated before anything is written, but a failure occurring after writing has begun leaves already-created entries in place and returns a non-OK status with no body.

Sep 1, 2026

• Corrected the request body schema for POST and PUT /aaa/teams/v2/{team_id}/members. The body is now a top-level array of user objects instead of one user object. OpenAPI does not mark the request body as required. When sent, the body must use the array form required by the runtime. This is a breaking schema correction for clients generated from the previous OpenAPI document.
• The OpenAPI document now declares openapi: 3.1.0 (was 3.0.0), and schema-level example values are emitted as examples arrays (JSON Schema 2020-12). Non-breaking at the schema level, but consumers whose OpenAPI tooling only supports 3.0 must upgrade to 3.1-capable tooling to process the document.

Aug 27, 2026

• 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.

v5.0.6 — Aug 12, 2026

• 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.

v5.0.5 — Aug 6, 2026

• 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.

v5.0.4 — Jul 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.

v5.0.3 — Jul 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.

v5.0.2 — Jun 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.

v5.0.1 — Jun 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.

Jun 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.

Jun 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.