Create new operation in Azure APIM api with terraform - azure

Question

I already created an API in Azure with folowing code.
resource "azurerm_api_management_api" "api-foo" {
name = "Example"
resource_group_name = data.azurerm_resource_group.rg.name
api_management_name = data.azurerm_api_management.apim_service.name
revision = "1"
display_name = "example-foo"
path = "apifoo"
protocols = ["https", "http"]
description = "some text here"
import {
content_format = "openapi-link"
content_value = "https://publicapi.azurewebsites.net/swagger/v1/swagger.json"
}
}
Also a root level policy.
resource "azurerm_api_management_api_policy" "api-foo" {
api_name = azurerm_api_management_api.api-foo.name
api_management_name = data.azurerm_api_management.apim_service.name
resource_group_name = data.azurerm_resource_group.rg.name
#operation_id = azurerm_api_management_api_operation.api-foo.operation_id
xml_content = <<XML
<policies>
<inbound>
<set-backend-service base-url="https://publicapi.azurewebsites.net" />
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
XML
}
Now I have more swager definitions with new enpoints and I want to add them in same Api but I don´t know how to achieve this with terraform. Also don´t want to remove the one I already have. If I replace content_value with new swager file I will remove the one I already have.
Is there a way to achieve this? Also, how can I get the Operation Id in the output after it gets created? I would want that The ID of new operation get asociated to some policy but not as a root level. Just operation policy level (a new module will have to be created for this new policy)

Answer 1

You cannot add a different swagger/openapi definition to the same api in an Azure api management instance. By importing an api definition, the api operations are automatically generated by the Azure api management service below the api that you selected as the target.
You can either create a new api in the same Azure api management instance (with a different api suffix than the first one) and import your new definition there, or you can manually combine the api definitions into one file (assuming the apis share the same base api URLs) and replace your existing api with it.
A third but ugly option would be to add the operations from your 2nd api definition manually below the first api in your Azure api management instance, but this will be cumbersome as you also have to manually adjust the policy for each operation to point its backend to the 2nd api definition base URL.