[BUG] `btp_subaccount_destination_generic`: "Provider produced inconsistent result after apply" when `destination_configuration` is derived from an input variable

[vgonzcam]

Is there an existing issue for this?

• I have searched the existing issues

What version of the Terraform provider are you using?

1.21.3

What version of the Terraform CLI are you using?

v1.14.3

What type of issue are you facing

bug report

Describe the bug

Every terraform apply that creates a btp_subaccount_destination_generic resource fails with the error below when destination_configuration is assigned a value derived from a Terraform input variable — regardless of whether for_each, a child module, or a single isolated resource is used.

Error: Provider produced inconsistent result after apply

When applying changes to btp_subaccount_destination_generic.<name>,
provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
new value: .destination_configuration: inconsistent values for sensitive attribute.

This is a bug in the provider, which should be reported in the provider's own issue tracker.

The bug is confirmed to affect all of the following resource forms:

• btp_subaccount_destination_generic — single resource, variable-derived config
• btp_subaccount_destination_generic — for_each in root module, variable-derived config
• module.<name>.btp_subaccount_destination_generic — child module call, variable-derived config

Expected Behavior

terraform apply should complete successfully after creating a btp_subaccount_destination_generic resource, even when destination_configuration is derived from an input variable.

The provider should declare destination_configuration (or the credential sub-fields within it) as WriteOnly attributes — the correct semantic for fields that are write-only at the API level. WriteOnly attributes are excluded from Terraform's post-apply consistency check.

Steps To Reproduce

1. Execute terraform init

2. Execute terraform apply with the following configuration

variables.tf:

variable "subaccount_id" {
  type    = string
  default = "<your-subaccount-id>"
}

variable "test_destination_config" {
  description = "Single destination configuration for isolation testing."
  type        = map(string)
  default = {
    Name           = "httpbin-no-auth-test-config"
    Type           = "HTTP"
    URL            = "https://httpbin.org"
    ProxyType      = "Internet"
    Authentication = "NoAuthentication"
    Description    = "Isolation test — single var, no for_each"
  }
}

variable "destinations" {
  description = "Map of destinations to manage."
  type = map(object({
    name                = string
    service_instance_id = optional(string)
    configuration       = map(string)
  }))
}

destinations.tfvars.json:

{
  "destinations": {
    "httpbin-basic-auth-jkey": {
      "name": "httpbin-basic-auth-mod-jkey",
      "service_instance_id": null,
      "configuration": {
        "Name": "httpbin-basic-auth-mod-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org/basic-auth/user/passwd",
        "ProxyType": "Internet",
        "Authentication": "BasicAuthentication",
        "User": "user",
        "Password": "passwd",
        "Description": "HTTP destination managed by module — BasicAuthentication"
      }
    },
    "httpbin-no-auth-jkey": {
      "name": "httpbin-no-auth-mod-jkey",
      "service_instance_id": null,
      "configuration": {
        "Name": "httpbin-no-auth-mod-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org",
        "ProxyType": "Internet",
        "Authentication": "NoAuthentication",
        "Description": "HTTP destination managed by module — NoAuthentication"
      }
    },
    "httpbin-basic-auth-instance-jkey": {
      "name": "httpbin-basic-auth-instance-mod-jkey",
      "service_instance_id": "ac9be7e3-27ed-488d-911b-XXXXXXXXXXXX",
      "configuration": {
        "Name": "httpbin-basic-auth-instance-mod-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org/basic-auth/user/passwd",
        "ProxyType": "Internet",
        "Authentication": "BasicAuthentication",
        "User": "user",
        "Password": "passwd",
        "Description": "HTTP destination managed by module — BasicAuthentication at instance level"
      }
    }
  },
  "destinations_module": {
    "httpbin-basic-auth-jkey": {
      "name": "httpbin-basic-auth-mod-module-jkey",
      "service_instance_id": null,
      "configuration": {
        "Name": "httpbin-basic-auth-mod-module-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org/basic-auth/user/passwd",
        "ProxyType": "Internet",
        "Authentication": "BasicAuthentication",
        "User": "user",
        "Password": "passwd",
        "Description": "HTTP destination managed by module — BasicAuthentication"
      }
    },
    "httpbin-no-auth-jkey": {
      "name": "httpbin-no-auth-mod-module-jkey",
      "service_instance_id": null,
      "configuration": {
        "Name": "httpbin-no-auth-mod-module-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org",
        "ProxyType": "Internet",
        "Authentication": "NoAuthentication",
        "Description": "HTTP destination managed by module — NoAuthentication"
      }
    },
    "httpbin-basic-auth-instance-jkey": {
      "name": "httpbin-basic-auth-instance-mod-module-jkey",
      "service_instance_id": "ac9be7e3-27ed-488d-911b-XXXXXXXXXXXX",
      "configuration": {
        "Name": "httpbin-basic-auth-instance-mod-module-jkey",
        "Type": "HTTP",
        "URL": "https://httpbin.org/basic-auth/user/passwd",
        "ProxyType": "Internet",
        "Authentication": "BasicAuthentication",
        "User": "user",
        "Password": "passwd",
        "Description": "HTTP destination managed by module — BasicAuthentication at instance level"
      }
    }
  }
}

main.tf — isolation test (single resource, no for_each):

resource "btp_subaccount_destination_generic" "managed_single_test" {
  subaccount_id             = var.subaccount_id
  destination_configuration = jsonencode(var.test_destination_config)
}

main.tf — for_each in root module and child module call:

locals {
  destinations_managed = {
    for key, dest in var.destinations :
    "${var.subaccount_id},${dest.name}" => {
      subaccount_id       = var.subaccount_id
      name                = dest.name
      service_instance_id = dest.service_instance_id
      configuration       = dest.configuration
    }
  }
  destinations_managed_module = {
    for key, dest in var.destinations_module :
    "${var.subaccount_id},${dest.name}-module" => {
      subaccount_id       = var.subaccount_id
      name                = "${dest.name}-module"
      service_instance_id = dest.service_instance_id
      configuration       = dest.configuration
    }
  }
}

# Root module — for_each
resource "btp_subaccount_destination_generic" "managed_root_working" {
  for_each                  = local.destinations_managed
  subaccount_id             = each.value.subaccount_id
  service_instance_id       = each.value.service_instance_id
  destination_configuration = jsonencode(each.value.configuration)
}

# Child module — for_each
module "btp-destination-generic-module-issue" {
  source      = "./modules/btp-destination-generic"
  for_each    = local.destinations_managed_module
  destination = each.value
  providers   = { btp = btp }
}

Result: Apply fails on every CREATE with the error below. All 7 affected resources are tainted in state and will fail again on the next apply — the error recurs on every subsequent terraform apply.

╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to btp_subaccount_destination_generic.managed_single_test,
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to btp_subaccount_destination_generic.managed_root_working["b80eac86-...,httpbin-no-auth-mod-jkey"],
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to btp_subaccount_destination_generic.managed_root_working["b80eac86-...,httpbin-basic-auth-mod-jkey"],
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to btp_subaccount_destination_generic.managed_root_working["b80eac86-...,httpbin-basic-auth-instance-mod-jkey,ac9be7e3-..."],
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.btp-destination-generic-module-issue["b80eac86-...,httpbin-no-auth-mod-module-jkey-module"].btp_subaccount_destination_generic.destination_generic,
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.btp-destination-generic-module-issue["b80eac86-...,httpbin-basic-auth-mod-module-jkey-module"].btp_subaccount_destination_generic.destination_generic,
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.btp-destination-generic-module-issue["b80eac86-...,httpbin-basic-auth-instance-mod-module-jkey-module,ac9be7e3-..."].btp_subaccount_destination_generic.destination_generic,
│ provider "provider[\"registry.terraform.io/sap/btp\"]" produced an unexpected
│ new value: .destination_configuration: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

3. Replace the variable reference with a hardcoded literal

resource "btp_subaccount_destination_generic" "test" {
  subaccount_id = var.subaccount_id
  destination_configuration = jsonencode({
    Name           = "httpbin-no-auth-test"
    Type           = "HTTP"
    URL            = "https://httpbin.org"
    ProxyType      = "Internet"
    Authentication = "NoAuthentication"
  })
}

Result: Apply succeeds. No error.

---

Tested expression forms

Expression	Result
jsonencode(var.X) where X = map(string)	❌ fails
jsonencode(var.X.configuration) nested inside map(object)	❌ fails
var.X where X = string (pre-encoded JSON, no jsonencode)	❌ fails
jsonencode({ hardcoded literal })	✅ succeeds

Reproduced with Authentication = "NoAuthentication" (no credential fields), which rules out credential fields as the sole trigger. The determining factor is that the value is variable-derived.

---

Attempted workarounds (none resolved the error)

• lifecycle { ignore_changes = [destination_configuration] } — does not affect the post-apply consistency check. Only suppresses plan-time diffs. The error is raised after apply, not during planning.
• nonsensitive(jsonencode(var.X)) — no effect. The consistency check operates on the provider schema-level sensitive flag, not the Terraform expression sensitivity.
• configuration = string (pre-encoded JSON in .tfvars, no jsonencode()) — still fails. Eliminates jsonencode() as a contributing factor.
• Moving jsonencode() into a child module — still fails with the same error on every CREATE.

---

User's Role Collections

• Subaccount Administrator

Add screenshots to help explain your problem

Additional context

Provider schema definition

The destination_configuration attribute is declared in the provider schema as:

Required
destination_configuration (String, Sensitive) The configuration parameters for the destination.

Even though there's a comment that we don't know how to interpret:

"Password"                 = "YourPassword" # Property required, but do not maintain it on your IaC repository. Keep it blank!

This declaration (Sensitive) may be the direct cause of the failure.

The Password field is required by the BTP Destination Service API, but should not be stored in source control. How can we handle this in an IaC scenario?
Leave the Password field blank in the Terraform configuration and then update it manually in the BTP cockpit after creation? Or is there a recommended approach for managing this securely within Terraform?
How can we handle the imports and the passwords?

[sachinprajapat06]

Hi @vgonzcam ,

Thank you for bringing up this issue. I was able to reproduce the behavior on my end and wanted to share a few observations.
The issue appears to be related specifically to the Description field in the API request.

In your example:
"Description": "HTTP destination managed by module — NoAuthentication"
the em dash (—) does not seem to be handled correctly by the backend API.

If you replace it with a standard hyphen (-):
"Description": "HTTP destination managed by module - NoAuthentication"

the destination is created successfully via Terraform as well.

[vgonzcam]

Thanks for your response.
I was able to create the destinations.

But the next problem arises as mentioned on the Additional context section (maybe my fault for writting there)

Additional context section

Provider schema definition
The destination_configuration attribute is declared in the provider schema as:

Required
destination_configuration (String, Sensitive) The configuration parameters for the destination.
Even though there's a comment that we don't know how to interpret:

"Password" = "YourPassword" # Property required, but do not maintain it on your IaC repository. Keep it blank!
This declaration (Sensitive) may be the direct cause of the failure.

The Password field is required by the BTP Destination Service API, but should not be stored in source control. How can we handle >this in an IaC scenario?
Leave the Password field blank in the Terraform configuration and then update it manually in the BTP cockpit after creation? Or is >there a recommended approach for managing this securely within Terraform?
How can we handle the imports and the passwords?

How we can handle the password on a IaC envirioment or livecycle?

The idea is not to mantain the password on clear on files, so:

If I quit the password from the configuration:

│ Error: API Error Updating Resource Destination
│
│   with module.btp-destination-generic-module-issue["b80eac86-80f6-4f4a-8290-6cef804e4e17,httpbin-basic-auth-mod-module-jkey-module"].btp_subaccount_destination_generic.destination_generic,
│   on modules\btp-destination-generic\main.tf line 14, in resource "btp_subaccount_destination_generic" "destination_generic":
│   14: resource "btp_subaccount_destination_generic" "destination_generic" {
│
│ Internal Server Error

If i pass as blank ("Password": ""...) it changes the password of the destination...

How we can include this resource on our flows?
Use a vault? Access to the code only administrators?

Thanks in advance.

[sachinprajapat06]

Hi @vgonzcam

These are very relevant questions, especially when considering secure usage in real IaC workflows. Let me share some thoughts and observations:

1. How can this resource be included in our flows?
   This resource can be integrated into standard Terraform workflows (plan/apply) like any other managed resource. However, special care is required when dealing with sensitive attributes such as credentials, as they directly impact state management and lifecycle behavior.

2. How should passwords be handled in an IaC environment/lifecycle?
   You’re absolutely right—the goal should be to avoid storing passwords in plain text within configuration files or state.

A few important points here:

When a destination is created via the BTP UI and later read using a data source, the password is redacted, which is expected behavior
However, when Terraform creates the resource, the password is part of the configuration and therefore gets stored in the state file in plain text.

If you pass this after creation of a destination:
"Password": ""

Terraform interprets this as an update, which results in the password being overwritten. This is expected behavior from both Terraform and the API.

3. Recommended approaches for handling secrets

To manage this securely in production environments:
Use a secrets manager / vault
Integrate with a vault solution (e.g., HashiCorp Vault or any cloud-native equivalent) to dynamically fetch credentials instead of hardcoding them.

Restrict access to state files
Ensure Terraform state is:
Stored remotely (e.g., secure backend)
Encrypted at rest
Accessible only to authorized users (e.g., administrators)

Avoid unnecessary updates
This helps prevent unintended password resets during subsequent applies.

Separation of concerns
In some cases, it may be better to:
Create the destination once (manually or via a secure pipeline)
Manage non-sensitive attributes via Terraform
Avoid frequent updates to sensitive fields

4. Important Note

Since password is a mandatory field for authenticated destinations, it must be provided during creation. This makes secure handling (via vaults or environment variables) essential rather than optional.

Hope this helps clarify the behavior and possible approaches.

[vgonzcam]

Thanks for the response @sachinprajapat06 .

I still have some questions about treating destination_configuration as an entirely Sensitive block, because I am not sure it fully improves secret handling across the IaC lifecycle, and from my tests it seems to make some operational scenarios harder to manage.

From what I understand so far, for authenticated destinations:

• Password is required at creation time,
• if it is omitted, the operation fails,
• if it is passed as empty ("Password": ""), it is treated as an update and ends up overwriting the password,
• so in practice the resource seems more straightforward for initial creation than for safely managing later updates.

Because of that, I wanted to ask whether this is the expected behavior by design, or whether it is considered a current limitation of the provider.

I also wonder whether a more granular treatment of sensitive fields, or a write-only approach for values that the API does not return, might be worth considering. As things stand, using a vault seems very likely to be necessary, but it is still not entirely clear how updates, imports, or credential rotation are expected to be handled safely in a real IaC workflow.

Thanks again.

[sachinprajapat06]

Hi @vgonzcam

You have understood this correctly.

At present, destinations are implemented as a generic resource because there are multiple destination types (primarily five major categories), each with varying configurations. Managing these as separate resource types would significantly increase complexity, potentially resulting in 30+ combinations at the resource level.

To simplify this, a single destination_configuration block is used, which is marked as sensitive.

Recommended approach:

For complex configurations, it is advisable to create the destination via the BTP UI.
If you have a well-defined and exact configuration, you can create it directly using Terraform.
For simpler use cases (e.g., basic HTTP destinations), Terraform scripts work reliably.

Lifecycle consideration:

After creation, you can import the resource into Terraform and manage it effectively going forward.

This is important because:

The password is required during creation and must be provided in the Terraform configuration.
Once the destination is created, the password is not returned by the API (it is redacted).
However, during creation via Terraform, the password will be stored in the state file, as Terraform needs it to manage the resource.

This behavior is expected and aligns with how sensitive attributes are handled in Terraform and the underlying API.

[lechnerc77]

Hi @vgonzcam,

as written by @sachinprajapat06 the destinations as they are now reflect the best approach the destination APIs give us. As of today there are no well-defined interface contracts for the different destination types. Hence, we are not able to offer a specifc interface for each destination type that would allow us to use read-only attributes for passwords/credentials or to set specific attributes as sensitive and others as vsisble.

Concerning your setup, I see two options:

1. Handle the secrets via Terraform e.g. by injecting them during CI/CD execution into the variables (i.e. the JSON string) but treating them as secrets in the CI/CD environment. This would cover the consistent setting of the password. This comes at the priece that the password is stored in the state file which should be encrypted
2. You create the destination with a empty password and set the password in a second step e.g. via the btp CLI. This way you do not store the real password in the state file. There will be no drift as from the Terraform side we can not fetch the password from the platform.

Option 1 + 2 work for imports (there will be a in-place update which sets the password in both cases) and updates.

Best,
Christian