datadog
Datadog API v2
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_registrationsto retrieve Azure App Registrations and Entra ID integration status - New POST endpoints for
/api/v2/security_monitoring/configuration/integration_config/{integration_type}/activateand/deactivateto manage entity context sync integrations - Added schema definitions:
SecurityMonitoringAzureAppRegistration,SecurityMonitoringEntraIdAzureAppRegistrations*models, andSecurityMonitoringIntegrationActivate*request models - Made
secretsfield optional inSecurityMonitoringIntegrationConfigCreateAttributesandSecurityMonitoringIntegrationConfigUpdateAttributesto 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_registrationsto retrieve Azure App Registrations and Entra ID integration status - New POST endpoints for
/api/v2/security_monitoring/configuration/integration_config/{integration_type}/activateand/deactivateto manage entity context sync integrations - Added schema definitions:
SecurityMonitoringAzureAppRegistration,SecurityMonitoringEntraIdAzureAppRegistrations*models, andSecurityMonitoringIntegrationActivate*request models - Made
secretsfield optional inSecurityMonitoringIntegrationConfigCreateAttributesandSecurityMonitoringIntegrationConfigUpdateAttributesto support source types like Entra ID that don't require secrets
All changes are additive and do not break existing integrations.
- New GET endpoint
- Breaking
Remove attached_to, prerequisite, table_id fields from IncidentUserDefinedFieldAttributesResponse
Three fields —
attached_to,prerequisite, andtable_id— have been removed from theIncidentUserDefinedFieldAttributesResponseschema, including from itsrequiredarray. 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 madefinished_atoptional, 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_issuesenable bidirectional sync between Datadog security findings and Linear issues; new request/response schema types (AttachLinearIssueRequest,CreateLinearIssueRequestArray, etc.) andlinear_issuefield added toFindingCaseresponse. 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_activityhas 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
IncidentTypeConfigurationschema with incident-type-scoped behavior settings, and added a read-onlyconfigurationfield toIncidentTypeAttributesandIncidentTypeUpdateAttributes. Also added a newIncidentTypeSlugSourceenum 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_encryptionandssekms_key_idadded to the Amazon S3 destination configuration for Observability Pipelines, along with a new enum typeObservabilityPipelineAmazonS3DestinationServerSideEncryption. 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
idfield in flaky test schemas to clarify that it represents the@test.fingerprint_fqnfacet value and can be used with the newfingerprint_fqnsearch 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
includedarray toBatchRowsQueryResponsecontaining full row resources, and ametaobject toListRowsResponsewith pagination details includingnext_continuation_token. It also expands the list of supported Datadog sites to includeuk1.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
fieldparameter (defaults to "message") and introduces a newObservabilityPipelineParseGrokProcessorRuleItemtype that supports either source-based or include-based Grok rules viaoneOf. Existing integrations using the originalObservabilityPipelineParseGrokProcessorRulewill 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_idfield, makingoperator,attribute, andvalueconditionally required rather than always required. Additionally, S3 archive integrations now support both access-key-based and IAM-role-based authentication approaches. A new optionaldescriptionfield 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-unstablepreview notice from two security findings endpoints (POSTandPUTon 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_byquery 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
tlsfield to theObservabilityPipelineCloudPremDestinationschema to support TLS encryption configuration. Additionally, all Tag Indexing Rules endpoints are now marked withx-unstablemetadata indicating the feature is in preview. Both changes are additive and backwards-compatible. - Breaking
Remove tls field from ObservabilityPipelineCloudPremDestination
The
tlsfield (referencingObservabilityPipelineTls) has been removed from theObservabilityPipelineCloudPremDestinationschema. Any client code that sets or readstlson this destination object will break. Additionally,uk1.datadoghq.comhas 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
tlsfield 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_viewendpoint 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:
CIAppPipelineEventJobwas previously a concrete object schema; it is now aoneOfunion ofCIAppPipelineEventFinishedJobandCIAppPipelineEventInProgressJob. Clients that previously used the flat schema will need to handle both variants.CIAppPipelineEventFinishedPipelinegains a new required fieldend, which was previously already present but not listed as required — clients sending pipeline-finished events that omitendwill now be rejected.CIAppPipelineEventFinishedJob(new schema, extracted from the oldCIAppPipelineEventJob) changes required fields:unique_id→id, and addspipeline_unique_idandpipeline_nameas required; removespartial_retryas required.CIAppPipelineEventInProgressJob(new schema, extracted from the oldCIAppPipelineEventJob) changes itsstatusreference fromCIAppPipelineEventJobStatusto the newCIAppPipelineEventJobInProgressStatus(enum["running"]), and dropsendfrom required fields.- New schema
CIAppPipelineEventJobInProgressStatusadded with enum valuerunning.
- 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
CycloneDXBomobjects 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, andsortenable 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
bufferfield has been added to the ObservabilityPipelineClickhouseDestination schema, referencingObservabilityPipelineBufferOptions. 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}/toggleto activate or pause a schedule. Also added new schemas (ReportScheduleListResponse,ReportScheduleListResponseData,ReportScheduleListResponseAttributes,ReportScheduleIncludedResourceType, etc.) and updated example values for thetimeframefield 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 withGovernanceControlAttributes,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-forecastto create/replace custom forecasts andDELETE /api/v2/cost/budget/{budget_id}/custom-forecastto 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}/variantsto create variants,PUT /api/v2/feature-flags/{feature_flag_id}/variants/{variant_id}to update variants, andDELETE /api/v2/feature-flags/{feature_flag_id}/variants/{variant_id}to delete variants. A newUpdateVariantRequestschema andvariant_idpath 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_idhas been deprecated and replaced by the newrepository_urlfield in bothBranchCoverageSummaryRequestDataandCommitCoverageSummaryRequestData. Critically,repository_idhas been removed from therequiredarray in both schemas — clients that only sendrepository_id(withoutrepository_url) may still work today, but the intent is to migrate torepository_url. The removal ofrepository_idas 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 newrepository_urlfield accepts full URLs with or without a scheme. - Additive
Test Optimization service settings schema expansions
Five new optional response fields added to
TestOptimizationServiceSettingsAttributes(*_is_overriddenflags) and five new optional request fields added toTestOptimizationUpdateServiceSettingsRequestAttributes(*_inheritflags) to support service-level setting overrides and inheritance. Additionally, theidfield example changed format,pr_comments_enableddescription 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 (
PATCHandDELETEon/api/v2/statuspages/{page_id}/degradations/{degradation_id}/updates/{update_id}), a newDegradationUpdateschema 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}andPUT /api/v2/remote_config/products/rum/configs/{config_id}enable retrieval and updating of RUM SDK configurations. Additionally, a newremote_config_idfield 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, andDueDateRule*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/insightsGET 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 (IoCIndicatorandIoCIndicatorDetailed), introduces a new POST endpoint/api/v2/security/siem/ioc-explorer/triageto 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
GetUsageSummaryAvailableFieldsendpoint 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/workflowsendpoint 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
CloudWorkloadSecurityAgentRuleActionSetValuehas been changed fromformat: int64toformat: int32with amaximum: 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 inset_valueactions will now violate the schema and may be rejected. - Informational
Remove x-unstable preview notice from ServiceNow integration endpoints
The
x-unstablemetadata 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
configurationfield inDeploymentGatesEvaluationRequestAttributes. 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/findingsendpoint (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 theMuteFindingsoperation. - 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}, andGET /api/v2/tag-policies/{policy_id}/scoreendpoints 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-topicsandGET /api/v2/llm-obs/v1/topic-discovery-topics/with-cluster-pointsfor retrieving discovered topics and clustered points, plus new parameter definitions and schema objects likeLLMObsPatternsClusteredPoint,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 HardcodedAPI surface is removed — endpointsGET /api/v2/rum/applications/{app_id}/retention_filters/hardcoded(list),GET /api/v2/rum/applications/{app_id}/retention_filters/hardcoded/{rf_id}(get), andPATCH /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 newSecurityMonitoringRuleVersionpath parameter. - Additive: New
Data ObservabilityAPI tag and schemas (DataObservabilityMonitorRunStatus,DataObservabilityMonitorRunType,GetDataObservabilityMonitorRunStatusResponse, etc.) added for monitoring data observability monitor run status.
- Breaking: The entire
- 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_durationendpoint 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
ObservabilityPipelineGenerateMetricsV2Processorschema 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 usingObservabilityPipelineGenerateMetricsProcessorcontinue to work unchanged.