In the case of APIM, there are infrastructure changes and then there are gateway configuration changes like API specifications and policies. So, the answer depends on — SKU, AZ, “what” kind of changes

From the official documentation:

“When you change availability zone configuration, the changes can take 15 to 45 minutes or more to apply. The API Management gateway can continue to handle API requests during this time.”

Gateway configuration, such as APIs and policy definitions, regularly synchronizes between the availability zones that you select for the instance. Propagation of updates between the availability zones normally takes less than 10 seconds.

Active requests: When an availability zone is unavailable, any requests in progress that are connected to an API Management unit in the faulty availability zone are terminated and need to be retried.

Automatic: You can expect instances that use automatic availability zone support to have no downtime during an availability zone outage. Units in the unaffected zone or zones continue to work.

“You can also expect instances that use automatic availability zone support, but have a single unit, to have no downtime.” In this case, API Management distributes the unit’s underlying compute resources to two zones. The resource in the unaffected zone continues to work.

Zone-redundant: You can expect zone-redundant instances to have no downtime during an availability zone outage.

My personal view based on this is —API specifications and Policy updates won’t cause any non-recoverable failures to the consumers; provided retry strategy is in place.

Is it zero downtime? Zero downtime need not mean every request succeeds on the first attempt. If the system remains available and failures are recoverable, it meets the zero-downtime requirement. So — Yes.

Confirmation from Microsoft Question and Answer Forum To validate my understanding, I reached out to the MS Q&A forum and got a response consistent to the above understanding.

Here is the link to the question in the forum that has the official response.

Bottom line — API specification and Policy updates are zero downtime.

When using Terraform to import an OpenAPI/Swagger definition into Azure API Management (APIM), the API and its operations are created successfully. However, one subtle behavior can cause confusion when trying to manage operation-level policies declaratively.

This post explains the issue and a simple workaround.

The Scenario

I was importing my API using Terraform:

Swagger/OpenAPI definition imported into APIM
API created successfully
All operations appeared correctly in Azure

Later, I wanted to attach operation-level policies using Terraform using azurerm_api_management_api_operation_policy

At this point I ran into a problem: Terraform had no record of the operations in its state file.

Why This Happens

This behavior is expected once you understand how Terraform works. Terraform only tracks resources explicitly declared in configuration, or
resources manually imported into state

When Swagger is imported via azurerm_api_management_api the operations are created inside Azure, but they are not separate Terraform-managed resources unless you explicitly declare using azurerm_api_management_api_operation

Effectively — API is created in Azure and tracked in Terraform while
API Operations (via Swagger import) are created in Azure but NOT tracked in Terraform

This makes it unclear how to attach policies to those operations without creating the operations explicitly — a nightmare if you have hundreds of operations

The Simple Workaround

You do not need a Terraform resource reference to the operation for you to create an operation policy and attach it. Instead, you can attach the policy directly using azurerm_api_management_api_operation_policy resource and referencing the Swagger operationId.

Example:

resource “azurerm_api_management_api_operation_policy” “my_op_policy” {
provider = «provider»
api_name = “”
api_management_name = data.azurerm_api_management.apim.name
resource_group_name = data.azurerm_api_management.apim.resource_group_name
operation_id = “”
xml_content = templatefile("", {
backend_name = “”
method = “”
})
}

As long as the API exists in APIM and the operation exists and operation_id exactly matches the Swagger operationId — Terraform can apply and update the policy successfully. No explicit Terraform operation resource is required.

Notes

1. Use the Swagger operationId, not the display name. Terraform identifies the operation strictly by operationId.

2. Treat operationId as a stable contract. If you later rename the operationId or remove an endpoint or restructure the Swagger Terraform may fail because the referenced operation no longer exists.

3. Importing operations individually is possible but rarely worth it. You can define azurerm_api_management_api_operation and import each operation manually into Terraform state. However, it requires one resource per operation. Also, manual imports are tedious and scales poorly for large APIs thus defeating the benefit of Swagger-driven API definition

For most setups, referencing operationId directly in the policy resource is simpler.

Takeaway

When importing Swagger into APIM using Terraform:

Operations are created in Azure
Terraform does not automatically track them
Operation policies can still be managed declaratively by simply referencing the Swagger/OpenAPI Spec operationId

Understanding this distinction can save significant time when automating API Management deployments.

Use case — I want to import a Logic App as an API within my APIM instance.

There is no direct way to get the swagger file of a logic app using CLI (at least, I could not figure out). So, detailing the steps to extract the swagger definition of a logic app. I use the generated swagger file to import a Logic App as an API within APIM using Azure CLI

1. Provide the service principal contributor role to the logic app

• Get the resource id of the logic app —

$logicAppResourceId = (az logic workflow show –resource-group “{resourcegroup-name}” –name “{logicAppName}” –query id –output tsv)

• Provide contributor role for the service principal —

az role assignment create --assignee {sp-id} - role Contributor –scope $logicAppResourceId

2. Get the swagger file from the Logic App

• generate a JW token from https://login.microsoftonline.com/{tenantId}/oauth2/token for the service principle with resource as “https://management.core.windows.net/”

$tenantId = “11111111-1111-1111-1111-111111111111”
$clientId = “00000000-0000-0000-0000-000000000000”
$clientSecret = “your-client-secret”
$resource = “https://management.core.azure.com/"

$body = @{
grant_type = “client_credentials”
client_id = $clientId
client_secret = $clientSecret
resource = $resource
}

$response = Invoke-RestMethod -Method Post -Uri “https://login.microsoftonline.com/$tenantId/oauth2/token" -ContentType “application/x-www-form-urlencoded” -Body $body

$accessToken = $response.access_token
$accessToken

• construct the swagger URL for the logic app —

$swaggerUrl = “https://management.azure.com” + (az logic workflow show –resource-group “{resourcegroup-name}” –name “{logicapp-name}” –query id –output tsv) + “/listSwagger?api-version=2016–06–01”

• Issue a POST request to $swaggerUrl to get the swagger definition of the LogicApp using Postman (or any other option you prefer)

3. Import into APIM

• Run the below command to import the above swagger file to APIM

az apim api import –resource-group “{resourcegroup-name}” –service-name “{apim-instance-name}” –path “/v1” –api-id myapi –specification-path “.\logicapp.backend.swagger.json” –specification-format Swagger

4. Remove the contributor role for the service principal

az role assignment delete –assignee 00000000–0000–0000–0000–000000000000 –role “Contributor” –scope $logicAppResourceId

There are couple of ways to integrate an APIM with Logic App. The most common use case as far as I know is exposing the Logic App as an API on the APIM. The other scenario is calling a Logic App from APIM.

I will provide the APIM policy snippet to call a Logic App. If you are using Managed Identity to authenticate to Logic App (will cover in a separate article), you can skip sending the bearer token.

Few steps to be done in the Logic App

1. enable Authentication at the Logic App end

2. the Logic App URL should not contain the SAS token

3. make sure that the Logic App has the below in trigger section. Basically, this is the ensure that the Logic App expects the Bearer token and “IncludeAuthorizationHeadersInOutputs” ensures that the Auth token is available for further processing within the Logic App

   “triggers”: {
   “manual”: {
   “conditions”: [
   {
   “expression”: “@startsWith(triggerOutputs()?[‘headers’]?[‘Authorization’], ‘Bearer’)”
   }
   ],
   “inputs”: {
   “schema”: {}
   },
   “kind”: “Http”,
   “operationOptions”: “IncludeAuthorizationHeadersInOutputs”,
   “type”: “Request”
   }
   }

APIM Policy to call the Logic App

We issue a call to the Logic App from with the . The response from the Logic App is captured in response-variable-name=”responsela”.

<policies>
<inbound>

    <send-request mode\="new" response-variable-name\="responsela" timeout\="20" ignore-error\="false"\>  
        <set-url\>https://xxxxxxx.com:443/workflows/xxxxxxxxxxxx/triggers/manual/paths/invoke?api-version=2016-10-01</set-url\>  
        <set-method\>POST</set-method\>  
        <set-header name\="Content-Type" exists-action\="override"\>  
            <value\>application/json</value\>  
        </set-header\>  
        <set-header name\="Authorization" exists-action\="override"\>  
            <value\>Bearer \*\*\*\*</value\>  
        </set-header\>  
    </send-request\>  

    <return-response\>  
        <set-status code\="200" reason\="OK" />  
        <set-body\>@(((IResponse)context.Variables\["responsela"\]).Body.As<JObject\>(preserveContent: true).ToString())</set-body\>  
    </return-response\>  

</inbound\>  
<outbound\>  
    <base />  
</outbound\>  
<on-error\>  
    <base />  
</on-error\>  
<backend\>  
    <base />  
</backend\>  

</policies>

All the tags are quite self-explanatory and there a loads of documentation available about them. is very useful policy, it suspends further policy pipeline execution and returns to the caller.

Hope this helps.

Cheers!