Terraform AzAPI Provider v2.13.0: New Features and Fixes Explained

Introduction

The azapi provider from the Azure Terraform team exposes raw ARM (Azure Resource Manager) and data-plane APIs directly in Terraform, which is useful when AzureRM lags behind a new API version or resource type. Version v2.13.0 ships a handful of enhancements and bug fixes, mostly around debugging, retry behavior, and handling of resources that need non-standard read semantics. This article summarizes what changed and how to upgrade safely.

What Is New

Debugging: LOG_SENSITIVE_DATA environment variable

GH-1245 adds a LOG_SENSITIVE_DATA environment variable that makes the provider log full request and response bodies. This is useful when troubleshooting payload issues with a resource, but it will dump sensitive values (secrets, keys, tokens) to logs, so it should only be used temporarily and never left enabled in CI or production runs.

export TF_LOG=DEBUG
export LOG_SENSITIVE_DATA=true
terraform apply

Improved retry policy for ChainedTokenCredential

GH-1243 improves the retry policy used when the provider authenticates via ChainedTokenCredential (the default credential chain). No configuration change is required; this should reduce transient authentication failures in CI/CD pipelines that use managed identity or chained credential sources.

azapi_update_resource: new read_override property

GH-1170 adds a read_override property to azapi_update_resource. Some Azure APIs require a POST call instead of the usual GET to fetch current state. read_override lets you point the provider at the correct read operation for those APIs.

resource "azapi_update_resource" "example" {
  type        = "Microsoft.Example/widgets@2026-01-01"
  resource_id = azapi_resource.widget.id
 
  body = {
    properties = {
      enabled = true
    }
  }
 
  read_override {
    method = "POST"
    body = {
      action = "query"
    }
  }
}

Check the provider documentation for the exact schema of read_override, since the release notes only confirm the property name and purpose (GH-1170).

azapi_data_plane_resource: data source and ephemeral resource support

GH-1199 extends azapi_data_plane_resource beyond the managed resource type to also support a data source and an ephemeral resource. This is relevant for data-plane APIs (e.g., Key Vault secrets, storage data-plane endpoints) where you want to read a value without managing its lifecycle, or avoid persisting it to state via an ephemeral resource.

data "azapi_data_plane_resource" "secret" {
  type        = "Microsoft.KeyVault/vaults/secrets@7.4"
  parent_id   = "https://example-vault.vault.azure.net"
  resource_id = "https://example-vault.vault.azure.net/secrets/my-secret"
}
 
ephemeral "azapi_data_plane_resource" "secret_ephemeral" {
  type        = "Microsoft.KeyVault/vaults/secrets@7.4"
  parent_id   = "https://example-vault.vault.azure.net"
  resource_id = "https://example-vault.vault.azure.net/secrets/my-secret"
}

Ephemeral resources require Terraform 1.10+ (ephemeral resource support). Confirm your Terraform CLI version before adopting the ephemeral variant.

Key Vault examples updated to RBAC and newer API version

GH-1230 updates the bundled Key Vault examples to use Azure RBAC for authorization (instead of access policies) and the 2026-02-01 API version. If you've been copying from the provider's example configurations, re-check them against the updated samples in the repository.

Bicep types updated

GH-1197 bumps the bundled Bicep type definitions to a newer azure-rest-api-specs revision (0744f52a86919d243ba2225e55bdb9c87bf521a5). This affects schema validation and autocomplete support for resource types defined via azapi_resource and related data sources — expect broader or corrected type coverage for recently added Azure resource types/API versions.

API version index changes

GH-1223 updates the provider's internal API version index: it adds Microsoft.Portal/dashboards version 2026-04-01, and removes Microsoft.Keyvault versions 2026-02-01 and 2026-03-01-preview. If any configuration pins one of the removed Key Vault API versions implicitly (via api_version omission and provider defaulting), verify the resolved version after upgrading.

Bug Fixes

• GH-1220: Resource headers are now correctly propagated to long-running operation (LRO) polling requests, which should fix issues where a required header (e.g., for correlation or data residency) was dropped mid-poll.
• GH-1229: azapi_data_plane_resource now applies retry logic to its existence check, reducing false negatives on transient data-plane errors.
• GH-1193: General fix for retries on resource existence checks (applies more broadly than just the data-plane resource).

Upgrade Steps

Pin the provider version in your Terraform configuration and run a provider upgrade:

terraform {
  required_providers {
    azapi = {
      source  = "Azure/azapi"
      version = "~> 2.13.0"
    }
  }
}

terraform init -upgrade

If you plan to use LOG_SENSITIVE_DATA for a one-off debugging session, set it in the shell for that invocation only, and unset it afterward:

unset LOG_SENSITIVE_DATA

Verify

Confirm the installed provider version and run a plan to make sure nothing unexpected changes, particularly if you rely on default API versions for Key Vault or dashboard resources:

terraform providers
terraform plan

Look for the azapi entry showing 2.13.0 in the terraform providers output, and review the plan output closely for any Key Vault resources where the API version default may have shifted due to the index changes in GH-1223.

Conclusion

v2.13.0 is an incremental release focused on reliability (retry behavior, LRO header propagation) and on filling gaps for APIs with non-standard read or data-plane semantics (read_override, ephemeral azapi_data_plane_resource). None of the changes in the release notes indicate breaking changes, but the API version index update for Key Vault and dashboards is worth a terraform plan review before rolling out broadly.