Migrate Settings v1 โ Settings 2.0
Migrating Settings API Calls
Any automation using the Gen2 Settings API v1 or config API endpoints needs to be updated. Gen3 unifies everything into Settings 2.0 โ one endpoint, schema-based, consistent for all configuration.
The Unified Pattern
Gen2: 50+ separate API endpoints Gen3: ONE endpoint
/api/config/v1/autoTags /api/v2/settings/objects
/api/config/v1/alertingProfiles โ Replaced by Workflows (no schema)
/api/config/v1/notifications โ Replaced by Workflows (no schema)
/api/config/v1/managementZones schemaId = builtin:management-zones
... Every setting follows the same pattern
โ ๏ธ builtin:alerting.profile and builtin:problem.notifications do NOT exist on Gen3. Alerting profiles and problem notifications are replaced by Workflows with email/Slack/Jira actions.
๐ Try it: Ctrl+K โ "Settings" โ open "Anomaly detection" โ click any detector โ look at the URL: the schema ID is builtin:davis.anomaly-detectors. Now run in a Notebook: fetch dt.settings | filter schema_id == "builtin:davis.anomaly-detectors" | limit 5 to see the same settings as queryable data.
How Settings 2.0 Works
// Every setting follows this structure:
{
"schemaId": "builtin:tags.auto-tagging",
"scope": "environment",
"value": {
"name": "my-tag-rule",
"rules": [...]
}
}
Common Schema IDs
Schema ID What It Configures
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
builtin:davis.anomaly-detectors Anomaly detectors (alerts)
builtin:tags.auto-tagging Auto-tagging rules
builtin:cloud.kubernetes K8s cluster connections
builtin:anomaly-detection.kubernetes.* K8s anomaly detection
builtin:rum.web.injection RUM JavaScript injection
builtin:logmonitoring.log-storage-settings Log storage configuration
Discovering Schemas
# List all available schemas
curl -s "$DT_URL/api/v2/settings/schemas" -H "Authorization: Bearer $TOKEN" | jq '.items[].schemaId'
# Get schema details (see all fields and their types)
curl -s "$DT_URL/api/v2/settings/schemas/builtin:davis.anomaly-detectors" -H "Authorization: Bearer $TOKEN"
Migration: Which Settings Moved?
Gen2 Config API Gen3 Settings 2.0 Schema
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
/api/config/v1/autoTags builtin:tags.auto-tagging
/api/config/v1/managementZones builtin:management-zones (+ Segments)
/api/config/v1/anomalyDetection/* builtin:anomaly-detection.*
/api/config/v1/maintenanceWindows builtin:alerting.maintenance-window
/api/config/v1/alertingProfiles โ REMOVED โ use Workflows instead
/api/config/v1/notifications โ REMOVED โ use Workflows instead
/api/config/v1/dashboards โ REMOVED โ use Document API instead
Pagination Gotcha
โ ๏ธ Settings API pagination is different from other APIs. When using nextPageKey, you must send ONLY the key โ no other parameters (pageSize, schemaIds, scopes). The API returns 400 if you include them.
API Type Page 2+ Rule
โโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Settings API ONLY nextPageKey (rejects all other params)
Document API Always resend pageSize (not embedded in token)
Most APIs Resend filters (not embedded in token)
Migration Step: Export โ Identify โ Convert
# 1. List all settings schemas in your environment
curl -s "$DT_URL/api/v2/settings/schemas" -H "Authorization: Bearer $TOKEN" \
| jq '.items[] | .schemaId' | sort
# 2. Export all objects for a schema
curl -s "$DT_URL/api/v2/settings/objects?schemaIds=builtin:tags.auto-tagging" \
-H "Authorization: Bearer $TOKEN"
# 3. Convert to Terraform or Monaco format
# Use Monaco: monaco download --environment myenv.yaml