"API resource location … is not registered on …"
Microsoft's client libraries for Azure DevOps do not call a fixed address. They first ask the server for its list of REST APIs, then look up the call by its GUID. When the GUID is not in the list, they stop before sending the call and say so: API resource location 9946fd70-0d40-406e-b686-b4744cbbcc37 is not registered on https://server/tfs/DefaultCollection.
Where the list comes from
- The client sends
OPTIONS {collection}/_apis. The answer lists the API locations:id(the GUID),area,resourceName,routeTemplate,minVersionandmaxVersion. We asked a public organization on dev.azure.com (October 27, 2026, without signing in): 740 locations in 72 areas. The GUID above isgit/pullRequests. - When the GUID is missing at the collection, Microsoft's Python client also looks one level up (the server without the collection) before it gives up, according to its client.py.
- The Python client, which the az devops CLI uses, keeps the list on disk for 12 hours, in
~/.azure-devops/python-sdk/cache(or the folder named byAZURE_DEVOPS_CACHE_DIR).
The three causes
- The API is not on your server. Each Azure DevOps Server version has the APIs of its time, and some exist only on Azure DevOps Services. Public reports:
az devops security group liston Azure DevOps Server 2020 (azure-devops-cli-extension #1126, GUID048aee0a-…, Graph descriptors; on dev.azure.com that one is not in the organization's list at all but onvssps.dev.azure.com); the Cache task on Azure DevOps Server 2020, where a Microsoft contributor answered that it is not supported on-premises (azure-pipelines-tasks #13937); the Terraform provider on Azure DevOps Server 2022, whose maintainers test against dev.azure.com only (#709). No setting adds an API: use another call or tool, or a newer server. - The address misses the collection. Team Foundation Server and Azure DevOps Server keep the APIs under a collection:
http://server:8080/tfs/DefaultCollection, nothttp://server:8080/tfs. In a report against TFS 2018, the address was missing part of its path (azure-devops-cli-extension #990). - The list never came. When sign-in fails, the client does not get the list and every GUID looks unregistered. In a report on Microsoft's own IntelliJ plugin, the message for a pull request on dev.azure.com ends with
HTTP 302 Found, a redirect where the list should be (azure-devops-intellij #397). Check the personal access token: expired, made for another organization, or missing a scope.
Telling them apart with one call
curl -u :YOUR_TOKEN -X OPTIONS -H "Accept: application/json" "http://server:8080/tfs/DefaultCollection/_apis"
- JSON with your GUID in it: the API is there; look again at the address the tool uses.
- JSON without your GUID: cause 1 on that collection.
- No JSON at all (a 401, a 302 or an HTML page): sign-in failed (cause 3), or the address is wrong (cause 2).
- After a server upgrade, the az devops CLI can keep the old list for up to 12 hours: delete the cache folder above.
In IntelliJ IDEA, Rider and the other JetBrains IDEs
Azure DevOps Pull Requests is a pull request plugin for JetBrains IDEs 2024.1 or later and Android Studio. It does not use this list: it calls the pull request REST routes directly and steps the api-version down to the version the server names (that answer). It works with Azure DevOps Services, Azure DevOps Server 2019 and later, and Team Foundation Server 2018 Update 2 or later, including /tfs/ addresses. Reading is free; voting, commenting and completing are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.
More: TF400733 (rate limits) · "The latest REST API version this server supports is…" · "is under preview" · TF400813 · TFS 2018 and Server 2019 · 日本語