Why Does Azure DevOps REST APIs Use Multiple Hostnames (dev.azure.com, vssps, vsaex)

Question

Azure DevOps REST API uses multiple hostnames such as dev.azure.com, vssps.dev.azure.com, and vsaex.dev.azure.com. Why are there different hostnames differ, and are these names part of a standard architecture? Is there any official way to identify which hostname is responsible for which API or service? I’m trying to understand how these domains are structured and how clients are supposed to know which one to call.

Answer 1

Hi @Yash Tiwari ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The use of multiple hostnames (e.g., dev.azure.com, vssps, vsaex) in Azure DevOps REST APIs is a result of the platform's distributed microservices architecture.

Because Azure DevOps is composed of many independent services (like Build, Release, Identity, and Licensing) rather than a single monolithic application, different API sets are hosted on different subdomains to allow them to scale, update, and fail independently.

Here are the breakdown of the common hostnames and the "Resource Areas" system used to navigate them.

• Common Hostnames and Their Roles Each hostname corresponds to a specific "Service Area" or microservice.

Hostname	Service Name	Purpose
dev.azure.com	Core / TFS	Handles the primary workloads: Work Items (Boards), Repos (Git/TFVC), and Build Pipelines.
vssps.dev.azure.com	Visual Studio Shared Platform Services	Handles Identity & Security. This includes Graph APIs (Users/Groups), Permissions, and Profile management.
vsaex.dev.azure.com	Visual Studio Account Extension	Handles Licensing & Entitlements. Used for managing User Entitlements, Access Levels (Stakeholder vs. Basic), and Billing.
vsrm.dev.azure.com	Visual Studio Release Management	Dedicated specifically to Classic Release Pipelines. (Note: YAML pipelines often run on the Core dev.azure.com service).
feeds.dev.azure.com	Azure Artifacts	Handles package management (NuGet, npm, Maven, etc.) feeds.

• The Official Way to Handle This: "Resource Areas" Microsoft advises against hardcoding these URLs because they can change (especially between Azure DevOps Services and Azure DevOps Server/On-Premise). Instead, you should use the Resource Areas API to dynamically discover the correct endpoint for the service you need.
  • API Endpoint: GET https://dev.azure.com/{organization}/_apis/resourceAreas
  • How it works: You query this endpoint, and it returns a list of "Areas" (like Release, Build, git, etc.) along with the locationUrl you should use for that specific organization.

        {
          "value": [
            {
              "id": "efc2f575-36ef-48e9-b672-0c6fb4a48ac5",
              "name": "Release",
              "locationUrl": "https://vsrm.dev.azure.com/my-org/"
            },
            {
              "id": "79134c72-4a58-4b42-976c-04e7115f32bf",
              "name": "core",
              "locationUrl": "https://dev.azure.com/my-org/"
            }
          ]
        }
    

Reference:

• Azure DevOps Services REST API Reference
• Allowed Domain URLs

Answer 2

The Azure DevOps REST APIs utilize multiple hostnames to organize and route requests to different services effectively. Each hostname serves a specific purpose within the Azure DevOps ecosystem:

1. dev.azure.com: This is the primary endpoint for accessing Azure DevOps services. It handles general requests related to Azure DevOps features such as projects, repositories, and pipelines.
2. vssps.dev.azure.com: This hostname is specifically used for authentication and authorization services. It handles requests related to user sign-in and token management, ensuring secure access to Azure DevOps resources.
3. vsaex.dev.azure.com: This hostname is associated with Azure DevOps extensions and additional services that may require separate routing or handling.

These hostnames are part of a structured architecture designed to separate concerns and optimize performance. By using distinct hostnames, Azure DevOps can manage traffic more efficiently and provide targeted services.

To identify which hostname to use for specific APIs or services, developers typically refer to the official Azure DevOps REST API documentation. This documentation outlines the available endpoints and specifies which hostname corresponds to each service, ensuring that clients can make the appropriate calls based on their needs.