Azure API Center: The First Look

Most organisations I work with end up with the same problem once they cross a certain size. Different teams build APIs independently, nobody has a single place to look up what already exists, and new developers waste time reinventing an endpoint that already lives somewhere in another team’s repository. If your organisation has more than a handful of APIs, you have probably already asked yourself questions like: who owns this API, what environments does it run in, and is there already something similar built by another team.

Azure API Center is Microsoft’s answer to this problem. It works as a central inventory for every API in your organisation, regardless of where that API is hosted or which gateway fronts it. In this article I will walk through provisioning an API Center instance, registering and importing APIs into it, and then using the Visual Studio Code tooling around it to browse, test, and generate client code for those APIs. I tested this using the sample published by Justin Yoo on the DevKimchi blog, and I have kept the walkthrough close to his original steps since they map well to a real adoption path.

What Azure API Center actually does

It helps to be clear about what Azure API Center is not before describing what it is. It is not an API gateway. It does not sit in the request path, it does not do rate limiting, and it does not proxy traffic the way Azure API Management does. Azure API Center is a metadata and governance layer that sits alongside your existing gateways and services. You register an API definition with it (typically an OpenAPI document), and it keeps track of the API, its versions, its deployments, and the environments it runs in.

This distinction matters in practice. If your organisation already uses Azure API Management as the gateway, you do not throw that away. You keep APIM doing what it does well, traffic management, policies, and authentication, and you add API Center on top as the inventory and discovery layer. Where API Center becomes genuinely useful is in a larger organisation with APIs spread across multiple gateways, on-premises services, and even third-party APIs consumed by different teams. If you have one team and three APIs behind a single APIM instance, honestly, APIM’s own developer portal already gives you most of what you need, and adding API Center is unlikely to justify the extra moving part.

Prerequisites

Before you start, set up the following tooling. Most of the value in this walkthrough comes from the Visual Studio Code extensions rather than the Azure Portal, so do not skip these.

• Visual Studio Code with the Azure API Center extension, the REST Client extension, and the Kiota extension
• Azure CLI with the API Center extension (az extension add –name apic-extension)
• Azure Developer CLI if you want to provision the sample resources using Bicep instead of clicking through the portal

A working sample that matches everything in this article is available on Justin Yoo’s GitHub, linked in the reference section at the end. Cloning that repository first will save you a fair amount of typing.

Provisioning an API Center instance

You can provision an API Center instance in three ways: through Bicep, through the Azure CLI directly, or through the Azure Portal. I am not going to repeat the full Bicep template here since it is straightforward resource provisioning with no surprises, but if you want a one-command setup, the sample repository referenced at the end has a working template you can deploy as-is. For a quick evaluation, the portal path is honestly the fastest, since API Center provisioning does not need much configuration beyond a name, resource group, and region.

Registering APIs to API Center

Once you have an instance running, the next step is registering an API. Let us say you have designed a weather forecast API and you have an OpenAPI document for it, but the implementation is not built yet. That is a perfectly normal starting point for API Center, since it tracks the API definition itself and does not require a live, deployed service behind it.

az apic api register \
    -g "my-resource-group" \
    -s "my-api-center" \
    --api-location ./weather-forecast.json

This command reads the OpenAPI document at the given path and creates a new API entry inside the specified API Center instance. The -g flag is your resource group, -s is the API Center service name, and –api-location points to a local OpenAPI JSON or YAML file. Run this and API Center will parse the document, pull out the title, version, and operation list, and create the corresponding API entity. A common mistake here is pointing –api-location at a document that has not been validated as proper OpenAPI. API Center is fairly forgiving about minor issues, but a malformed document will fail registration with a generic error, so validate the OpenAPI spec first with a linter if registration fails unexpectedly.

If you would rather register through the Azure Portal, the official Microsoft documentation walks through the exact same registration flow with a form-based UI, which some teams prefer for one-off registrations or for people who are not comfortable with the CLI.

Importing APIs from API Management

Registering brand-new APIs one at a time is fine when you are starting out, but most organisations adopting API Center already have working APIs sitting in Azure API Management. Rather than re-registering each one by hand, you can import them in bulk directly from APIM. This needs a few extra setup steps around identity and role assignment, since API Center needs read access to your APIM instance before it can pull anything from it.

First, enable a managed identity on the API Center instance. You can use either a system-assigned or a user-assigned identity; I used the system-assigned identity here since it needs no extra resource to manage.

az apic service update \
    -g "my-resource-group" \
    -s "my-api-center" \
    --identity '{ "type": "SystemAssigned" }'

This turns on a managed identity for the API Center resource itself, which Azure AD then uses to authenticate API Center against other Azure resources without you having to manage a secret or certificate. Next, retrieve the principal ID for that identity, since you will need it for the role assignment step.

APIC_PRINCIPAL_ID=$(az apic service show \
    -g "my-resource-group" \
    -s "my-api-center" \
    --query "identity.principalId" -o tsv)

Now grant that identity the API Management Service Reader Role, scoped to your APIM instance. This is a read-only role by design, which is worth pointing out to any security reviewer asking why API Center needs access to your APIM resource. It can list and read API definitions, it cannot modify policies or products.

APIM_RESOURCE_ID=$(az apim show \
    -g "my-resource-group" \
    -s "my-api-center" \
    --query "id" -o tsv)
 
az role assignment create \
    --role "API Management Service Reader Role" \
    --assignee-object-id $APIC_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $APIM_RESOURCE_ID

With the role assignment in place, run the import command. This pulls every API matching the source resource ID pattern from APIM into API Center in one pass.

az apic service import-from-apim \
    -g "my-resource-group" \
    -s "my-api-center" \
    --source-resource-ids "$APIM_RESOURCE_ID/apis/*"

The wildcard at the end of the source resource ID imports all APIs from that APIM instance. If you only want specific APIs, replace the wildcard with the exact API name. Expect this command to take a little time if your APIM instance has a large number of APIs, since it registers each one individually behind the scenes.

At this point the APIs exist inside API Center’s inventory, but registering or importing them on its own does not do much for your day-to-day development. The real value shows up once you start using the Visual Studio Code tooling built around this inventory.

Browsing APIs in Visual Studio Code with Swagger UI

With the Azure API Center extension installed, open the extension panel in VS Code and you will see the list of APIs registered in your instance. Right-click any API and choose Open API Documentation from the context menu.

This opens a Swagger UI page rendered directly inside VS Code, showing the full API document with all its operations, parameters, and response schemas. You can expand any operation and try it against a live endpoint directly from this view, which is handy for a quick sanity check without switching to a browser or a separate tool like Postman.

Testing APIs with the REST Client extension

Swagger UI is fine for exploring an API, but for repeatable testing with saved requests, I prefer the REST Client extension. With it installed, right-click an API in the API Center panel again, this time choosing Generate HTTP File.

This produces a plain .http file with a request scaffold already matching the API’s operations. You edit the payload, headers, or query parameters directly in the file and click Send Request above each block, and REST Client shows you the response inline. Because it is a plain text file, you can commit it to your repository and version it alongside your API changes, which is something a Swagger UI session cannot give you.

Generating a client SDK with Kiota

This is the feature I found most useful in the whole extension set. Writing a client SDK by hand for every API you consume is tedious, and it goes stale the moment the API changes underneath you. The Kiota extension solves this by generating a strongly typed client SDK directly from the API definition stored in API Center.

One detail worth calling out: because Kiota generates the SDK from the OpenAPI document, this works even when the API itself has no working implementation yet. You get a compilable client with the right method signatures and models before the backend team has written a single line of code, which is a genuinely good way to unblock frontend or integration work in parallel with backend development.

Right-click an API in the extension panel and select Generate API Client.

The Kiota extension then opens its own explorer view listing every endpoint discovered from the API definition. You can select all of them or only the ones you actually need, which matters for larger APIs where generating a client for every single endpoint would produce a bloated SDK you never fully use.

After selecting the endpoints, provide a class name, a namespace, and an output folder for the generated code. Kiota then asks which language to generate the SDK in. At the time of writing there were nine languages supported, covering the common enterprise stack: C#, Java, TypeScript, Python, Go, PHP, Ruby, Swift, and CLI. I chose C# since the sample consumes it from a Blazor web application.

Kiota then writes the generated client straight into the folder you specified, ready to reference from your project.

Consuming the generated SDK in an application

The generated client depends on the Kiota abstraction libraries at runtime, so you need to add these packages to the consuming project before the generated code will compile.

dotnet add ./src/WebApp/ package Microsoft.Kiota.Http.HttpClientLibrary
dotnet add ./src/WebApp/ package Microsoft.Kiota.Serialization.Form
dotnet add ./src/WebApp/ package Microsoft.Kiota.Serialization.Json
dotnet add ./src/WebApp/ package Microsoft.Kiota.Serialization.Text
dotnet add ./src/WebApp/ package Microsoft.Kiota.Serialization.Multipart

These packages provide the HTTP transport and serialization support the generated client relies on. Miss one of the serialization packages and you will typically hit a runtime exception about a missing serialization factory rather than a compile-time error, so if the client throws unexpectedly on its first call, check that all four serialization packages are present, not just the JSON one.

After adding the packages, wire up the client as a dependency in Program.cs and call it from your Razor component the way you would call any typed HTTP client. In the sample, calling the generated client from a Blazor page renders the pet store data returned by the API.

Where this fits and where it does not

Having gone through the full workflow, my honest take is that Azure API Center earns its place once an organisation has enough APIs that discovery itself becomes a problem. If your team can already answer questions like who owns an API or what environment it runs in without checking a wiki, you probably do not need this yet. The moment a new hire has to ask around in chat to find out if an API for a given purpose already exists, that is your signal to set this up.

The Kiota integration is, in my opinion, the strongest reason to adopt this over just keeping OpenAPI documents in a shared folder. Generating a working, typed client for an API that has not even shipped yet removes a real bottleneck in parallel development. On the flip side, API Center is still evolving. At the time this was written it was in preview, so expect API surface changes, and do not build critical automation directly against its CLI commands without pinning versions and testing upgrades in a non-production subscription first.

One limitation worth flagging for production planning: API Center is a governance and inventory layer, not a runtime dependency. If it goes down or you decommission it, your actual APIs keep running unaffected, since nothing in the request path touches it. That also means it will not protect you from a genuinely undocumented or unregistered API sitting somewhere in your estate. It only knows about what someone actually registered or imported, so treat the initial import as a one-time data quality exercise, not a discovery mechanism on its own.