Share via

Inconsistent Casing in Azure API Responses for Specific Subnets

Revital Blum 60 Reputation points
2025-08-21T13:06:07.8466667+00:00

I am observing inconsistent casing in Azure API responses for two specific subnets.
Here are the details:

API Call:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/networkSecurityGroups?api-version=2024-05-01

Response (partial):

"subnets": [

{

"id": "/subscriptions/xxxxxxxxxxxxxxxxxx/resourceGroups/ANALYTICS-RISKS_BASE/providers/Microsoft.Network/virtualNetworks/PORTLANDVNET/subnets/PORTLAND-SUB-1"

},

{

"id": "/subscriptions/xxxxxxxxxxxxxxxxxx/resourceGroups/ANALYTICS-RISKS_BASE/providers/Microsoft.Network/virtualNetworks/PORTLANDVNET/subnets/PORTLAND-SUB-2"

}

]

Observation:

The subnet names and resourceGroup name appear in uppercase in the API response.

However, in the Azure Portal and in the response from: GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Network/virtualNetworks?api-version=2024-05-01
the same subnet names and resourceGroup name appear in lowercase.

Additional Context:

This issue is specific to two subnets. Other subnets in the same subscription do not exhibit this behavior.

I would like to know what could be causing this inconsistency in casing for these specific subnets and resource groups and how can it be fixed.

Thanks,
Revital

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
0 comments
Accepted answer
  1. Thanmayi Godithi 555 Reputation points Microsoft External Staff Moderator
    2025-08-21T18:48:02.68+00:00

    Hi @Revital Blum,

    Thanks for reaching out on Microsoft Q&A.

    I understand your concern about seeing inconsistent casing in the Azure API responses for some subnets. Let me clarify how this works.

    Resource and resource group names in Azure are case-insensitive, so whether you see /subnets/PORTLAND-SUB-1 or /subnets/portland-sub-1, both resolve to the same subnet. This is documented in Azure Resource Naming Rules:

    When using various APIs to retrieve the name for a resource or resource group, the returned value may have different casing than what you originally specified for the name. The returned value may even display different case values than what is listed in the valid characters table. Always perform a case-insensitive comparison of names.

    The reason you’re seeing uppercase only for certain subnets is likely because of how they were first created or referenced. Different Azure resource providers serialize names slightly differently—for example, the NetworkSecurityGroups API may return the casing that was originally used when the subnet–NSG association was created, while the VirtualNetworks API shows the casing persisted in the VNet definition.

    There’s no functional impact here, but if you need consistency for automation, the recommended approach is to normalize casing in your code.

    Always perform a case-insensitive comparison of names.

    As suggested, you can either make the entire resource ID lower case or upper case and further pass the new value to subsequent functions/application within your code.

    Reference: Sensitivity Issue with Resource ID in Azure SDK API Calls

    Kindly let us know if the above helps or you need further assistance on this issue.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.