Azure API Management Naming Conventions: Service, APIs, and Products

An Azure API Management service name is a globally unique DNS endpoint (<name>.azure-api.net), so it must be 1 to 50 characters, alphanumerics and hyphens, and start with a letter: apim-payments-prod-eus-001. The APIs, products, backends, and named values inside it are service-scoped, so name them by function, orders-api, premium, not with a CAF prefix.

API Management naming has two layers, like Service Bus and SQL. The service itself is a globally visible DNS endpoint with strict rules and a CAF prefix. Everything inside it, APIs, products, backends, named values, is service-scoped and named by function, not by a resource-type abbreviation. Getting that distinction right keeps your gateway readable.

The service is a global endpoint

The API Management service name becomes several public hostnames at once:

• <name>.azure-api.net (the gateway)
• <name>.developer.azure-api.net (the developer portal)
• <name>.management.azure-api.net (the management endpoint)

That is why the service name must be globally unique and DNS-safe.

Rule	Detail
Length	1 to 50 characters
Allowed characters	Alphanumerics and hyphens
Must start with	A letter
Must end with	An alphanumeric
Scope of uniqueness	Global (across all of Azure)
CAF prefix	apim

Naming the service

Use the full CAF pattern:

apim-{workload}-{environment}-{region}-{instance}

Scenario	Service name
Payments APIs, production	apim-payments-prod-eus-001
Shared platform gateway, production	apim-platform-prod-eus-001
Partner integration, dev	apim-partner-dev-eus-001

Many organizations run a single shared API Management instance in front of many teams’ APIs. In that case, name it for the platform rather than one workload: apim-platform-prod-eus-001. Because the name is globally unique, keep the region abbreviation and instance number for entropy.

Naming what is inside: APIs, products, backends

The entities inside the service are scoped to it, 1 to 80 characters, alphanumerics and hyphens. They are not given a CAF type prefix. Name them by function, because these names appear in URLs, policies, and the developer portal:

apim-payments-prod-eus-001              (service)
├── APIs:        orders-api, payments-api, catalog-api
│   └── versions: v1, v2
├── Products:    starter, premium, internal, partner
├── Backends:    payments-backend, legacy-soap
└── Named values: backend-base-url, payments-api-key

• APIs: name by domain, and add a version where you version them (orders-api, payments-v2). The API name is an identifier used in the gateway URL and in policies, so keep it stable and lowercase. Change the display name if you need a prettier label, not the name.
• Products: name by access tier or audience (starter, premium, internal, partner). Products map subscriptions to APIs.
• Backends: name for the service they point at (payments-backend).
• Named values: name for what they hold (backend-base-url), and make secrets obvious (payments-api-key).

Naming in Terraform

resource "azurerm_api_management" "main" {
  name                = "apim-${var.workload}-${var.environment}-${var.region}-001"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  publisher_name      = "Contoso Platform"
  publisher_email     = "platform@contoso.com"
  sku_name            = "Developer_1"
}

resource "azurerm_api_management_api" "orders" {
  name                = "orders-api"
  resource_group_name = azurerm_resource_group.main.name
  api_management_name = azurerm_api_management.main.name
  revision            = "1"
  display_name        = "Orders API"
  path                = "orders"
  protocols           = ["https"]
}

The service name is built from variables so every environment derives it the same way; the API name stays a stable, function-based identifier.

Common mistakes

A service name that is not globally unique. A generic apim-api-prod may already be taken by another tenant. Keep the region and instance number.

CAF-prefixing the APIs and products. They are not resources that need a type prefix. An API named api-orders-api is redundant. Call it orders-api.

Renaming an API after it is in use. The API name is part of the gateway URL and is referenced in policies. Changing it breaks callers. Change the display name instead, and keep the name stable.

Not versioning APIs. Bake a version scheme in from the start (v1, v2), so a breaking change does not force a rename.

Summary

• Service: 1 to 50 characters, alphanumerics and hyphens, globally unique, it becomes azure-api.net hostnames, prefix apim
• APIs, products, backends, named values: service-scoped, function-named, no CAF prefix
• Keep API names stable (they live in URLs and policies); version them from day one

Full rules are on the API Management naming page. AzureNamer generates the service name with the right constraints applied. See the Service Bus and SQL guides for the same globally-unique endpoint pattern, and the complete CAF guide for the fundamentals.