Back to monitors
Additive AI classification

Add Entra ID Azure App Registrations endpoints and models

New endpoints and models added for managing Entra ID Azure App Registrations in Security Monitoring:

  • New GET endpoint /api/v2/security_monitoring/configuration/integration_config/entra_id/azure_app_registrations to retrieve Azure App Registrations and Entra ID integration status
  • New POST endpoints for /api/v2/security_monitoring/configuration/integration_config/{integration_type}/activate and /deactivate to manage entity context sync integrations
  • Added schema definitions: SecurityMonitoringAzureAppRegistration, SecurityMonitoringEntraIdAzureAppRegistrations* models, and SecurityMonitoringIntegrationActivate* request models
  • Made secrets field optional in SecurityMonitoringIntegrationConfigCreateAttributes and SecurityMonitoringIntegrationConfigUpdateAttributes to support source types like Entra ID that don't require secrets

All changes are additive and do not break existing integrations.

Alert history

  • Additive

    Add Entra ID Azure App Registrations endpoints and models

    New endpoints and models added for managing Entra ID Azure App Registrations in Security Monitoring:

    • New GET endpoint /api/v2/security_monitoring/configuration/integration_config/entra_id/azure_app_registrations to retrieve Azure App Registrations and Entra ID integration status
    • New POST endpoints for /api/v2/security_monitoring/configuration/integration_config/{integration_type}/activate and /deactivate to manage entity context sync integrations
    • Added schema definitions: SecurityMonitoringAzureAppRegistration, SecurityMonitoringEntraIdAzureAppRegistrations* models, and SecurityMonitoringIntegrationActivate* request models
    • Made secrets field optional in SecurityMonitoringIntegrationConfigCreateAttributes and SecurityMonitoringIntegrationConfigUpdateAttributes to support source types like Entra ID that don't require secrets

    All changes are additive and do not break existing integrations.

  • Breaking

    Remove attached_to, prerequisite, table_id fields from IncidentUserDefinedFieldAttributesResponse

    Three fields — attached_to, prerequisite, and table_id — have been removed from the IncidentUserDefinedFieldAttributesResponse schema, including from its required array. Clients that read or deserialize these fields from incident user-defined field API responses will either fail deserialization (if strict) or silently lose data. All four incident user-defined field endpoints are affected, as reflected in the removed example values.

  • Additive

    Add ServerlessFunction asset type to SBOM list endpoint

    The Datadog SBOM API now supports a new ServerlessFunction asset type alongside existing types. Documentation clarifies that the filter[asset_type] parameter is required for initial requests, and that infrastructure asset types (Host, HostImage, Image, ServerlessFunction) cannot be mixed with code types (Repository, Service) in the same request. This is backward-compatible; existing code continues to work unchanged.

  • Additive

    Add user/org identity provider and OAuth2 client authorization endpoints

    This update introduces new API endpoints and path parameters to manage identity provider overrides for users and OAuth2 client authorizations. New endpoints include GET /api/v2/users/{user_id}/identity_providers, PATCH /api/v2/users/{user_id}/relationships/identity_providers, and related infrastructure for user and organization authorized client management. The changes also add new path parameter types (IdentityProviderId, OAuth2ClientId, OrgAuthorizedClientId, UserAuthorizedClientId, UserAuthorizedClientIdForOrg, UserIdForOrgClient) and new API tags for organizing these capabilities. The DORA deployment schema also changed timestamp fields from Unix nanoseconds to ISO 8601 strings and made finished_at optional, which is a breaking change to the schema but backward-compatible if clients only read the fields.

  • Additive

    Add Linear issue integration for security findings

    Two new endpoints and four new schema types added to support creating and attaching security findings to Linear issues. POST and PATCH /api/v2/security/findings/linear_issues enable bidirectional sync between Datadog security findings and Linear issues; new request/response schema types (AttachLinearIssueRequest, CreateLinearIssueRequestArray, etc.) and linear_issue field added to FindingCase response. All changes are purely additive with no breaking modifications to existing endpoints or schemas.

  • Additive

    Add workload_activity rule type to notification rules

    A new enum value workload_activity has been added to the rule type options for notification rules in the Datadog API. This is an additive change that allows vulnerability-based notification rules to filter by this additional rule type without affecting existing integrations.

  • Additive

    Add IncidentTypeConfiguration schema and configuration field

    Added a new IncidentTypeConfiguration schema with incident-type-scoped behavior settings, and added a read-only configuration field to IncidentTypeAttributes and IncidentTypeUpdateAttributes. Also added a new IncidentTypeSlugSource enum for ServiceNow integration support. These are purely additive changes to the Incident Type resource that do not break existing integrations.

  • Additive

    Add POST /api/v2/snapshot endpoint for graph snapshots

    A new POST /api/v2/snapshot endpoint has been added to create graph widget snapshots. This includes new request/response schemas (CreateSnapshotRequest, CreateSnapshotResponse) and supporting types for template variables, TTL configuration, and legend styling. The endpoint is in preview and subject to change.

  • Additive

    Add S3 server-side encryption options to Observability Pipeline

    New optional fields server_side_encryption and ssekms_key_id added to the Amazon S3 destination configuration for Observability Pipelines, along with a new enum type ObservabilityPipelineAmazonS3DestinationServerSideEncryption. These fields allow customers to specify encryption method (AWS KMS or AES256) and provide a KMS key ID when using KMS encryption, with no breaking changes to existing configurations.

  • Informational

    Clarified test ID documentation across flaky test APIs

    Updated documentation strings for the id field in flaky test schemas to clarify that it represents the @test.fingerprint_fqn facet value and can be used with the new fingerprint_fqn search filter. No API behavior or schema structure changed—these are pure documentation improvements to help engineers better understand and use the existing test ID field.

  • Additive

    Add included field and pagination meta to reference table responses

    The diff adds three new optional response fields: an included array to BatchRowsQueryResponse containing full row resources, and a meta object to ListRowsResponse with pagination details including next_continuation_token. It also expands the list of supported Datadog sites to include uk1.datadoghq.com. These are purely additive changes that do not alter existing fields or break backward compatibility.

  • Additive

    Add field and rule variation support to parse_grok processor

    The parse_grok processor schema was extended with a new optional field parameter (defaults to "message") and introduces a new ObservabilityPipelineParseGrokProcessorRuleItem type that supports either source-based or include-based Grok rules via oneOf. Existing integrations using the original ObservabilityPipelineParseGrokProcessorRule will continue to work; the schema now allows callers to specify which log field to parse and supports an alternative rule structure using include queries.

  • Additive

    Add optional condition fields and S3 access key support

    The API now allows conditions to reference saved filters via an optional saved_filter_id field, making operator, attribute, and value conditionally required rather than always required. Additionally, S3 archive integrations now support both access-key-based and IAM-role-based authentication approaches. A new optional description field was added to critical assets. All changes are backwards-compatible as they only add new optional fields and make previously required fields conditionally required.

  • Informational

    Removed preview notice from security findings endpoints

    Removed the x-unstable preview notice from two security findings endpoints (POST and PUT on a security findings path), indicating these endpoints are no longer in preview status. This is a documentation-only change that does not affect runtime behavior or API contract.

  • Informational

    Update worked_by parameter description for clarity

    The description of the worked_by query parameter was updated to clarify that it filters by user handle rather than user UUID. This is a documentation-only change that does not affect the parameter's actual behavior or API contract.

  • Additive

    Add TLS config to ObservabilityPipelineCloudPremDestination, mark Tag Indexing Rules as preview

    The diff adds a new optional tls field to the ObservabilityPipelineCloudPremDestination schema to support TLS encryption configuration. Additionally, all Tag Indexing Rules endpoints are now marked with x-unstable metadata indicating the feature is in preview. Both changes are additive and backwards-compatible.

  • Breaking

    Remove tls field from ObservabilityPipelineCloudPremDestination

    The tls field (referencing ObservabilityPipelineTls) has been removed from the ObservabilityPipelineCloudPremDestination schema. Any client code that sets or reads tls on this destination object will break. Additionally, uk1.datadoghq.com has been added as a valid server enum value, which is purely additive.

  • Additive

    Add TLS configuration to Observability Pipeline cloud-prem destination

    A new optional tls field has been added to the ObservabilityPipelineCloudPremDestination schema, providing configuration for TLS encryption. This is a purely additive change that does not affect existing integrations.

  • Deprecation

    Deprecate GET /api/v2/compliance_findings/rule_based_view

    The GET /api/v2/compliance_findings/rule_based_view endpoint is now marked as deprecated and will be sunset on 2027-06-26. Clients should migrate to the Security Monitoring - Search Security Findings endpoint instead.

  • Breaking

    CIAppPipelineEventJob schema restructured; FinishedPipeline required field added

    Several breaking changes to CI App pipeline event schemas:

    • CIAppPipelineEventJob was previously a concrete object schema; it is now a oneOf union of CIAppPipelineEventFinishedJob and CIAppPipelineEventInProgressJob. Clients that previously used the flat schema will need to handle both variants.
    • CIAppPipelineEventFinishedPipeline gains a new required field end, which was previously already present but not listed as required — clients sending pipeline-finished events that omit end will now be rejected.
    • CIAppPipelineEventFinishedJob (new schema, extracted from the old CIAppPipelineEventJob) changes required fields: unique_idid, and adds pipeline_unique_id and pipeline_name as required; removes partial_retry as required.
    • CIAppPipelineEventInProgressJob (new schema, extracted from the old CIAppPipelineEventJob) changes its status reference from CIAppPipelineEventJobStatus to the new CIAppPipelineEventJobInProgressStatus (enum ["running"]), and drops end from required fields.
    • New schema CIAppPipelineEventJobInProgressStatus added with enum value running.
  • Additive

    Add CycloneDX BOM import endpoint for security vulnerabilities

    Datadog API adds support for importing security vulnerabilities via POST /api/v2/security/findings using the CycloneDX 1.5 Bill of Materials format. This new endpoint accepts CycloneDXBom objects containing vulnerability data for external security scanners. The change includes 11 new schema definitions (CycloneDXBom, CycloneDXComponent, CycloneDXMetadata, etc.) and does not affect existing endpoints or functionality.

  • Additive

    Add metric volumes relationship and filtering for list metrics endpoint

    The Datadog v2 API adds support for querying metric volumes alongside metric configurations. New optional query parameters filter[is_configurable], include, and sort enable fetching and organizing metrics by their ingested/indexed volume, with response structures updated to support relationships and included metric volume data. This is purely additive—existing integrations continue working unchanged.

  • Additive

    Add optional buffer field to ClickHouse destination

    A new optional buffer field has been added to the ObservabilityPipelineClickhouseDestination schema, referencing ObservabilityPipelineBufferOptions. This is a purely additive change that enables new buffering configuration options for ClickHouse destinations without affecting existing integrations.

  • Additive

    Report Schedules: Add list and toggle operations, new schemas

    Added three new endpoints for report schedules: GET /api/v2/reporting/schedule/{schedule_uuid} to retrieve a single schedule, DELETE /api/v2/reporting/schedule/{schedule_uuid} to delete a schedule, and PATCH /api/v2/reporting/schedule/{schedule_uuid}/toggle to activate or pause a schedule. Also added new schemas (ReportScheduleListResponse, ReportScheduleListResponseData, ReportScheduleListResponseAttributes, ReportScheduleIncludedResourceType, etc.) and updated example values for the timeframe field from "calendar_month" to "1w". All changes are additive and do not alter existing API behaviour.

  • Additive

    Add Governance Controls API endpoints and schemas

    New Governance Controls API endpoints and supporting schemas added to Datadog API v2. Includes GET /api/v2/governance/controls/{detection_type} and PATCH /api/v2/governance/controls/{detection_type} endpoints, along with GovernanceControlAttributes, GovernanceControlData, GovernanceControlResponse, and related schema definitions. These are purely additive and do not affect existing integrations.

  • Additive

    Add optional cost data parameters to Get Budget endpoint

    The GET /budgets/{budget_id} endpoint gains four new optional query parameters (actual, forecast, start, end) that allow clients to request cost data alongside budget information. Three new schema types (BudgetAttributesCosts, BudgetAttributesCostsUnit, BudgetWithEntriesDataAttributesEntriesItemsCosts) are added to support the cost data in responses, and the endpoint documentation is expanded to explain the new functionality. Two new error response codes (400, 404) are also documented. All changes are purely additive and backward-compatible.

  • Additive

    Add custom forecast endpoints for budgets

    New endpoints and schemas added to support custom budget forecasting: PUT /api/v2/cost/budget/custom-forecast to create/replace custom forecasts and DELETE /api/v2/cost/budget/{budget_id}/custom-forecast to delete them. These are additive endpoints with supporting schemas (CustomForecastEntry, CustomForecastResponse, etc.) that enable clients to define custom monthly forecast amounts scoped by tag filters.

  • Additive

    Add WebSocket source and security filter/rule exports

    The API adds a new WebSocket source type for Observability Pipelines with full support for TLS, authentication strategies (none, basic, bearer, custom), and custom decoding. Additionally, the Terraform export endpoints now support security filters and rules resource types alongside the existing suppressions and critical_assets types, with updated documentation noting that partner rules cannot be exported.

  • Additive

    Add ClickHouse destination for Observability Pipelines

    Adds new ClickHouse destination support to Observability Pipelines with schemas for configuration, authentication, batching, compression, and format options. This is purely additive and does not modify existing destination types or API behavior.

  • Additive

    Add variant management endpoints for feature flags

    Three new endpoints have been added to manage feature flag variants: POST /api/v2/feature-flags/{feature_flag_id}/variants to create variants, PUT /api/v2/feature-flags/{feature_flag_id}/variants/{variant_id} to update variants, and DELETE /api/v2/feature-flags/{feature_flag_id}/variants/{variant_id} to delete variants. A new UpdateVariantRequest schema and variant_id path parameter were also introduced. These are purely additive changes that enable new functionality without affecting existing integrations.

  • Breaking

    repository_id removed from required fields; deprecated in favor of repository_url

    repository_id has been deprecated and replaced by the new repository_url field in both BranchCoverageSummaryRequestData and CommitCoverageSummaryRequestData. Critically, repository_id has been removed from the required array in both schemas — clients that only send repository_id (without repository_url) may still work today, but the intent is to migrate to repository_url. The removal of repository_id as a required field is a schema contract change, and clients that relied on the required constraint for validation or code generation will see a difference. The new repository_url field accepts full URLs with or without a scheme.

  • Additive

    Test Optimization service settings schema expansions

    Five new optional response fields added to TestOptimizationServiceSettingsAttributes (*_is_overridden flags) and five new optional request fields added to TestOptimizationUpdateServiceSettingsRequestAttributes (*_inherit flags) to support service-level setting overrides and inheritance. Additionally, the id field example changed format, pr_comments_enabled description clarified as repository-level-only (non-overridable), and endpoint documentation updated to reflect inheritance semantics—all backward-compatible additions and clarifications.

  • Additive

    Add degradation update endpoints and status page fields

    The Datadog API adds new endpoints for managing degradation updates (PATCH and DELETE on /api/v2/statuspages/{page_id}/degradations/{degradation_id}/updates/{update_id}), a new DegradationUpdate schema family for response modeling, and several optional response fields to the status page resource (enabled, slack_app_icon, slack_subscriptions_enabled). Auth scopes are refined across multiple status page endpoints to enforce more granular permission controls. These changes are backward-compatible additions that enhance status page management capabilities.

  • Additive

    Add RUM SDK remote configuration management API

    This diff adds new endpoints and schemas for managing RUM SDK configurations via remote config. New endpoints GET /api/v2/remote_config/products/rum/configs/{config_id} and PUT /api/v2/remote_config/products/rum/configs/{config_id} enable retrieval and updating of RUM SDK configurations. Additionally, a new remote_config_id field is added to the RUM application schema, and 20+ new schema definitions support the remote configuration system.

  • Additive

    Add ticket creation rules endpoints and due date rule schemas

    Added new schemas and endpoints for managing security finding automation rules. New schemas include AutomationRuleActorType, AutomationRuleCreatedBy, AutomationRuleModifiedBy, AutomationRuleScope, and DueDateRule* types for due date automation. New endpoints for ticket creation rules (POST/GET/PUT/DELETE /api/v2/security/findings/automation/ticket_creation_rules*) and due date rules are now available. These are purely additive and fully backward compatible.

  • Additive

    Add Governance Insights API endpoint and schemas

    Added a new /api/v2/governance/insights GET endpoint and 13 supporting schema definitions for retrieving governance insights with optional value computation. This is a new capability that does not affect existing endpoints or break any current integrations.

  • Additive

    Add IoC triage state endpoints and fields

    Adds new triage-related fields (triage_state, triaged_at, triaged_by) to IoC indicator response schemas (IoCIndicator and IoCIndicatorDetailed), introduces a new POST endpoint /api/v2/security/siem/ioc-explorer/triage to create/update triage states, and adds supporting data structures and query parameters for filtering. All changes are additive with new optional response fields and a new beta endpoint.

  • Informational

    Add Go code example to GetUsageSummaryAvailableFields

    Added a Go code example to the GetUsageSummaryAvailableFields endpoint documentation showing how to iterate through usage fields across multiple layers. This improves developer guidance without changing any API behaviour or contract.

  • Additive

    Add GET /api/v2/workflows list endpoint

    New GET /api/v2/workflows endpoint added to list all workflows in an organization with support for pagination, sorting, filtering, and optional full specs. Three new response schema types (ListWorkflowsResponse, WorkflowListItem, and related metadata) are introduced to support this endpoint.

  • Additive

    Add GET /api/v2/security/asm/services endpoint

    A new GET endpoint /api/v2/security/asm/services/{service_filter} has been added to retrieve Application Security details for services matching a given name. The change introduces three new schema types (ApplicationSecurityServiceAttributes, ApplicationSecurityServiceResource, ApplicationSecurityServiceType, ApplicationSecurityServicesMetadata, ApplicationSecurityServicesResponse) and a new path parameter definition (ApplicationSecurityServiceNameParam). This is purely additive and does not affect existing functionality.

  • Breaking

    CloudWorkloadSecurityAgentRuleActionSetValue integer narrowed from int64 to int32

    The integer variant of CloudWorkloadSecurityAgentRuleActionSetValue has been changed from format: int64 to format: int32 with a maximum: 2147483647. This is a breaking change for any client that passes or receives integer values larger than 2,147,483,647 (i.e. values that fit in a 64-bit signed integer but not a 32-bit one). Existing integrations sending large int64 values in set_value actions will now violate the schema and may be rejected.

  • Informational

    Remove x-unstable preview notice from ServiceNow integration endpoints

    The x-unstable metadata indicating preview status and subject to change has been removed from both the GET and POST endpoints for the ServiceNow security findings integration. This indicates the endpoints have graduated from preview to stable status, which is good news for consumers but does not change the actual API behavior or contract.

  • Additive

    Add inline rule configuration to deployment gates evaluation

    The deployment gates evaluation endpoint now supports optional inline rule configuration via a new configuration field in DeploymentGatesEvaluationRequestAttributes. Four new schema objects define the structure: DeploymentGatesEvaluationConfiguration, DeploymentGatesEvaluationRule, DeploymentGatesMonitorRule, DeploymentGatesFDDRule, and related type/options schemas. This allows rules to be evaluated directly from the request instead of requiring preconfigured gates, while maintaining backward compatibility with the existing gate-based flow.

  • Breaking

    PATCH /api/v2/posture_management/findings endpoint removed

    The PATCH /api/v2/posture_management/findings endpoint (MuteFindings / "Mute or unmute a batch of findings") has been removed from the spec, along with all associated schemas (BulkMuteFindingsRequest, BulkMuteFindingsRequestAttributes, BulkMuteFindingsRequestData, BulkMuteFindingsRequestMeta, BulkMuteFindingsRequestMetaFindings, BulkMuteFindingsRequestProperties, BulkMuteFindingsResponse, BulkMuteFindingsResponseData). Any client calling this endpoint to bulk mute/unmute security findings will no longer have a documented contract and the operation will break. Datadog's own docs previously noted to prefer the newer search security findings endpoint, but this removal is an explicit breaking change for existing integrations that rely on the MuteFindings operation.

  • Additive

    Add Tag Policies API endpoints

    Introduces new Tag Policies API endpoints and schemas for managing tag governance rules. Adds POST /api/v2/tag-policies, GET /api/v2/tag-policies, GET /api/v2/tag-policies/{policy_id}, PATCH /api/v2/tag-policies/{policy_id}, and GET /api/v2/tag-policies/{policy_id}/score endpoints along with supporting request/response schemas. These are purely new capabilities with no breaking changes to existing APIs.

  • Additive

    Add LLM Observability patterns discovery endpoints and schemas

    The Datadog API v2 adds support for LLM Observability patterns discovery with several new endpoints, query parameters, and response schemas. This includes GET /api/v2/llm-obs/v1/topic-discovery-topics and GET /api/v2/llm-obs/v1/topic-discovery-topics/with-cluster-points for retrieving discovered topics and clustered points, plus new parameter definitions and schema objects like LLMObsPatternsClusteredPoint, LLMObsPatternsTopic, and related types. All changes are purely additive and do not modify existing functionality.

  • Breaking

    RUM hardcoded retention filter endpoints removed; new Security Monitoring and Data Observability endpoints added

    This diff contains both breaking removals and additive additions:

    • Breaking: The entire RUM Retention Filters Hardcoded API surface is removed — endpoints GET /api/v2/rum/applications/{app_id}/retention_filters/hardcoded (list), GET /api/v2/rum/applications/{app_id}/retention_filters/hardcoded/{rf_id} (get), and PATCH /api/v2/rum/applications/{app_id}/retention_filters/hardcoded/{rf_id} (update) are gone, along with all associated schemas (RumHardcodedRetentionFilterAttributes, RumHardcodedCrossProductSampling, etc.) and path parameters.
    • Additive: New POST /api/v2/security_monitoring/rules/{rule_id}/restore/{version} endpoint added (beta) to restore a security monitoring rule to a historical version, with a new SecurityMonitoringRuleVersion path parameter.
    • Additive: New Data Observability API tag and schemas (DataObservabilityMonitorRunStatus, DataObservabilityMonitorRunType, GetDataObservabilityMonitorRunStatusResponse, etc.) added for monitoring data observability monitor run status.
  • Additive

    Add optional filter[metric] query parameter

    Added optional filter[metric] query parameter to filter tag keys by Cloud Cost Management metric. This is a purely additive change that does not affect existing integrations and is backward compatible.

  • Additive

    Add max session duration update endpoint

    A new PUT /api/v2/login/org_configs/max_session_duration endpoint and supporting schema types are added to allow updating the maximum session duration for an organization. This is a purely additive change and does not affect existing integrations.

  • Additive

    Add ObservabilityPipelineGenerateMetricsV2Processor schema

    Datadog API v2 adds a new ObservabilityPipelineGenerateMetricsV2Processor schema and corresponding type definition to the OpenAPI spec. This is a new processor type for Observability Pipelines that creates custom metrics from logs with enhanced configuration options. The change is purely additive — existing integrations using ObservabilityPipelineGenerateMetricsProcessor continue to work unchanged.