Ignore/circumvent Self-referential block


I am trying to use this provider, Terraform Registry
Which is a spin off of,
Terraform Registry

These providers let you automate APIs that follow REST standards to GET/POST/PUT and DELETE resources.

Now, the resource restapi_object allows you to specify, “data” that’ll be used during a POST and “update_data” will be used during a PUT.

resource "restapi_object" "app_scripted_demo_client" {
  provider = restapi.restapi_oauth
  path     = "/Applications"
  data = jsonencode({
    "Uuid": random_uuid.app_scripted_demo_client_uuid.id,
    "Name": "Scripted Demo Client"

  update_data = jsonencode({
    "Uuid": random_uuid.app_scripted_demo_client_uuid.id,
    "Name": "Scripted Demo Client 1",
    "ApiKey": try(restapi_object.app_scripted_demo_client.api_data.ApiKey, "dummykey"),
    "KeySecret": try(restapi_object.app_scripted_demo_client.api_data.KeySecret, "dummysecret")

update_data takes two vars called, ApiKey and KeySecret, that’s created during a POST.
When I refer to them using the same resource I get errors like these,

│ Error: Self-referential block
│   on apps.tf line 49, in resource "restapi_object" "app_scripted_demo_client":
│   49:     "ApiKey": try(restapi_object.app_scripted_demo_client.api_data.ApiKey, "dummykey"),
│ Configuration for restapi_object.app_scripted_demo_client may not refer to itself.

I understand terraform doesn’t know that “update_data” is only used after the resource is created.
Is there a way to circumvent the error?

I tried using local vars like this,

locals {
  app_scripted_demo_client_key = try(restapi_object.app_scripted_demo_client.api_data.ApiKey, "dummykey")
  app_scripted_demo_client_secret = try(restapi_object.app_scripted_demo_client.api_data.KeySecret, "dummysecret")

They throw a similar error like this,

│ Error: Cycle: local.app_scripted_demo_client_secret (expand), restapi_object.app_scripted_demo_client, local.app_scripted_demo_client_key (expand)

No, it’s not possible for a resource’s inputs to refer to its own outputs. That would be a circular dependency in the general case.

In this specific case the provider itself would have to implement a different way to express merging supplied values with values from a GET request.