On the other side, can't you merge the operations into one PATCH?

I did originally use the patch with revision but still ended up with a situation where they'd both read the latest revision at the same time and then both succeed in patching but the last one seemed to win. I can try to replicate it later today with a script calling the API if that's helpful?

btw, this is what chatgpt recommended, just as a starting point for options we have:

Yes, you can achieve fine-grained Terraform support for your API even if the API itself only deals with a huge JSON blob. This is a common pattern when providers need to manage a monolithic configuration model but expose more granular resources to users. ### Key Concept: Terraform Provider as the Translation Layer Your Terraform provider acts as the abstraction layer between: • Fine-grained Terraform resources (

server_config_logging

,

server_config_auth

, etc.) • The single blob API (

PUT /config { huge_blob }

) --- ### Strategy: Local Merge of Resources 1. Split State in Terraform Resources Define several fine-grained resources in your provider, like:

hcl
   resource "myapi_logging_config" "main" {
     level = "info"
   }

   resource "myapi_auth_config" "main" {
     method = "oauth2"
   }

2. Provider Maintains a Shared State or Cache In your provider's code, for each resource's

Read

,

Create

,

Update

, and

Delete

, you: • Read the full config blob from the API • Modify just the relevant piece for that resource • Merge all resource-specific changes back into the blob • Push the updated blob back to the API 3. Synchronize Access Across Resources Since all resources operate on the same shared blob, concurrency is a problem. Solutions include: • Locking mechanisms (e.g., mutexes in Go) • Serialization of resource operations using Terraform SDK's

CustomizeDiff

or an umbrella "controller" resource --- ### Example Implementation Pattern (in Go):

go
var configMutex sync.Mutex

func resourceLoggingConfigUpdate(d *schema.ResourceData, meta interface{}) error {
    configMutex.Lock()
    defer configMutex.Unlock()

    client := meta.(*APIClient)
    fullConfig, err := client.GetConfig()
    if err != nil {
        return err
    }

    // Modify the logging section
    fullConfig.Logging.Level = d.Get("level").(string)

    // Push entire blob
    return client.UpdateConfig(fullConfig)
}

--- ### Alternative: Umbrella Resource +

terraform-provider-helper

You can also create one top-level resource (e.g.

myapi_config

) and expose helper modules or internal subresources inside it, but that tends to be less ergonomic for users. --- ### TL;DR ✅ You can merge multiple Terraform resources into one JSON blob in the provider code ✅ Use internal locking and shared reads/writes ✅ Avoid API races or overwrites by reading-modifying-writing the blob carefully ✅ This is a common and accepted practice in custom Terraform providers --- Would you like a code example or scaffold of such a provider setup?