New Components

• teams: Add team resource for managing teams and membership as code (#133)
  New dash0_team resource declaratively manages Dash0 teams — the technical name, display
  attributes, and membership — via the TeamDefinitionV1Alpha1 CRD envelope. Members can be
  referenced by email address or internal Dash0 id; the server resolves emails during
  reconciliation, and the provider rewrites returned ids back to emails on read so state
  matches the user's YAML. Teams are organization-level resources and are not scoped to a
  dataset.

Bug Fixes

• provider: Populate id and url in state after terraform import for assets that carry no dash0.com/origin label. (#135)
  Assets originally created in the Dash0 UI have no dash0.com/origin label, so the previous
  identifier resolver — which matched only on origin — left the imported resource's id and url
  attributes empty (only a TF_LOG=INFO warning surfaced the miss). The resolver now falls back to
  matching the imported identifier against each list item's internal id, so id and url are
  populated for both CLI/API/Terraform-created assets (where the origin label is present) and
  UI-created assets (where it is absent). Applies to dashboards, views, check rules, synthetic
  checks, recording rules, spam filters, and notification channels.

Enhancements

• provider: Add AWS CloudFormation integration guide and Terraform example for IaC onboarding. (#76)
  Documents deploying the Dash0 AWS integration via the AWS provider's
  aws_cloudformation_stack resource and the hosted v2 CloudFormation template.
  TechnicalId is optional for Terraform onboarding — when omitted, the template
  derives the IAM external ID from the CloudFormation stack ID (template 2.2 / CLO-906).

Bug Fixes

notification_channels: Resolve perpetual drift on dash0_notification_channel when a check rule or synthetic check binds to the channel by id. (#128)

The Dash0 API populates spec.routing.assets on a notification channel as a back-reference whenever a check rule (via the dash0.com/notification-channel-ids annotation) or a synthetic check (via spec.notifications.channels) binds to the channel by id. The field is discarded on write, so previous releases produced a perpetual diff that attempted to wipe the back-reference on every plan.

The provider now treats spec.routing.assets as API-managed and ignores it during comparison.

If a user supplies spec.routing.assets on the channel YAML, the provider emits a warning on create and update, since the Dash0 API will discard the value. Bind a check rule or synthetic check to a channel from the check resource instead.

Enhancements

• provider: Support OAuth-enabled dash0 CLI profiles (#123)
  The provider now accepts profiles authenticated via dash0 auth login (OAuth).
  Access tokens are transparently refreshed when close to expiry.
  If the refresh token is expired, a clear error directs the user to re-authenticate.
• provider: Load Dash0 credentials from a dash0 CLI profile when they are not supplied via attributes or environment variables. (#65)
  Adds an optional profile attribute on the provider block and reads from
  the dash0 CLI configuration directory (~/.dash0 by default, overridable
  via DASH0_CONFIG_DIR). Credentials are resolved in this order:
  1. DASH0_API_URL / DASH0_AUTH_TOKEN environment variables (DASH0_URL
     remains accepted as a deprecated fallback for the URL).
  2. The url / auth_token provider attributes.
  3. The CLI profile named by the profile attribute; if profile is not
     set, the active profile in the dash0 CLI configuration directory.

Enhancements

• provider: Expose id as a computed attribute on every resource (#119)
  All provider resources — dashboards, views, check rules, synthetic checks,
  recording rules, spam filters, and notification channels — now expose a
  computed id attribute holding the server-assigned UUID. Reference it (e.g.
  as ${dash0_notification_channel.example.id}) when wiring one resource's
  identifier into another resource's YAML, where the Dash0 API expects raw
  UUIDs rather than provider-generated origins.

Enhancements

• resources: Add a computed url attribute to the dash0_dashboard, dash0_check_rule, dash0_synthetic_check, dash0_view and dash0_notification_channel resources that links to the resource in the Dash0 web app (#115). The URL is derived from the configured Dash0 API URL and the resource's server-assigned identifier. For views, the page is selected based on the view's type.

Enhancements

• provider: Add DASH0_MAX_RETRIES environment variable (#141)
  Configures the maximum number of retries for failed API requests.
  Accepted values: 0–5. Default: 3. Behavior before this change: 1 retry.

Enhancements

• provider: Document presence on the OpenTofu registry and add Terraform/OpenTofu registry badges to the README. (#101)
• spam_filters: Support the v1alpha2 spam filter shape (spec.context scalar) in addition to the existing v1alpha1 shape (spec.contexts list). (#105)
  The provider now dispatches Create/Update against the matching API endpoint based on the
  apiVersion declared in spam_filter_yaml, and decodes Read responses into either shape.

Enhancements

• dashboards, check_rules, synthetic_checks, views: dash0.com/sharing and dash0.com/folder-path metadata annotations are now preserved during drift detection (#98)
  The dash0.com/sharing annotation is supported on dashboards, check rules, synthetic checks, and views.
  The dash0.com/folder-path annotation is supported on dashboards and views.
  Changes to these annotations now trigger a Terraform plan update. All other metadata annotations remain server-managed and are ignored during drift detection.

Bug Fixes

• spam_filters: Fix spam filter FilterCriteria format in fixtures, tests, and docs to match the Dash0 AttributeFilter API schema (#96)
  The filter criteria now uses the correct flat format with operator and value fields
  instead of the incorrect nested stringValue format.