Managing Azure AI Services Accounts With the REST API

There is a moment in most Azure AI projects where clicking around the portal stops being cute. You have three environments, a handful of resources per environment, and someone just asked whether the production Azure OpenAI resource in Australia East is configured the same way as the one in dev. If your answer involves opening two browser tabs and squinting, you have outgrown the portal, and it is time to talk to the management API instead.

The Azure AI Services account management REST API is the plumbing underneath all of that. Every time you create an Azure AI resource in the portal, or run a Bicep deployment, or type an az cognitiveservices command, something is ultimately calling these Accounts endpoints. Microsoft documents them in the Azure AI Services REST API reference. This post is about when it is worth going to that layer directly, what it genuinely gives you, and the sharp edges we have hit using it across client environments.

Control plane, not the fun part

First, a distinction that saves a lot of confusion. There are two completely different sets of APIs in Azure AI, and people mix them up constantly.

The data plane is the one everybody thinks of. It is where you send a prompt to Azure OpenAI and get a completion back, or post an image and get objects detected. That is the AI doing AI things.

The account management API is the control plane. It does not run any inference. It creates, reads, updates and deletes the resource itself: the account that hosts the models, its pricing tier, its region, its network rules, its keys. Think of it as the difference between renting the building and doing the work inside it. The account API rents and configures the building. The data plane is the work.

Almost nobody's first Azure AI project touches the control plane API directly, and that is fine. You make a resource in the portal and get on with the interesting part. The control plane becomes worth knowing when you stop having one resource and start having a fleet, or when "who changed this and when" becomes a question someone actually needs answered.

What the Accounts endpoints give you

The Accounts group of the API covers the lifecycle of an Azure AI Services resource. You can create or update an account, read its properties, list every account in a resource group or across a subscription, delete one, and pull its keys and endpoints. There are related operations for regenerating keys, listing the models and SKUs available in a region, and checking whether a resource name is available before you try to use it.

That last one sounds trivial and is quietly useful. Azure AI resource names have to be globally unique in some contexts, and the availability check lets your automation fail politely up front rather than halfway through a deployment with a half-built environment and a confusing error.

The list operations are the ones I reach for most in real work. Being able to enumerate every Azure AI account across a subscription, programmatically, and read back its region, tier and configuration, is how you answer governance questions honestly instead of hoping. "Do we have any AI resources running in a region we are not meant to use" is a five-second query against the API and a genuinely awkward afternoon if you are checking by hand. For any organisation with data residency obligations, and in Australia that is most of them, that visibility is not a nice-to-have.

This kind of estate-wide visibility is a big part of what our Azure AI consulting team sets up early in an engagement, because you cannot govern what you cannot see, and the portal was never designed to give you a birds-eye view across dozens of resources.

When to use the API directly versus Bicep

Here is the honest guidance, because reaching for raw REST calls when a template would do is a common mistake.

For provisioning, for standing up resources and keeping them configured, use infrastructure as code. Bicep or Terraform. You describe the resource you want, the tooling calls this same account management API for you, and you get a declarative, version-controlled, repeatable definition. That is almost always the right answer for creating and maintaining resources, and it is what I would push nearly every client towards. A resource that exists only because someone ran a command once is a resource nobody can reliably recreate.

So when do you call the API directly? When you are doing something Bicep is not built for, which is mostly reading and reacting rather than declaring. Auditing an estate you did not build. Wiring a check into a pipeline that confirms production matches an expected shape before a deploy proceeds. Building a small internal tool that lists resources and flags the ones missing a required tag. Pulling live configuration into a governance dashboard. These are dynamic, query-shaped jobs, and a declarative template is the wrong tool for them.

The rule of thumb I use: if you are describing a desired end state, use Bicep. If you are asking a question about what currently exists, or taking an action in response to it, use the API. Getting that split right keeps your provisioning clean and your automation sane, and it is exactly the sort of foundation our Azure AI Foundry consultants put in place so teams are not managing a sprawl of hand-clicked resources six months in.

The traps worth knowing about

A few things bite people, and none of them are obvious from the reference docs alone.

Keys come back through this API, and that is a double-edged thing. The convenience of pulling a key programmatically is also a security exposure if you are careless. Any script or pipeline that reads keys needs to be treated as sensitive, because it holds the keys to your AI resources for as long as it runs. Honestly, the better move is to design so you barely need to read keys at all. Disable key-based access where you can and authenticate with managed identity instead, so there is no static secret for the API to hand out and nothing to leak. That shift removes a whole category of risk rather than managing it.

Soft delete is the second trap, and it catches people at the worst time. When you delete an Azure AI resource, in many cases it is not gone. It sits in a soft-deleted state for a period, and the name stays reserved. So you delete a resource, immediately try to recreate one with the same name in your redeploy, and it fails in a way that makes no sense until you learn that the old one is still lurking. If your automation tears down and rebuilds environments, you need to handle purge explicitly or your pipeline will trip over its own ghosts. This one has cost more than one team a confused hour.

Region and model availability is the third. The models and SKUs available through the account API are not uniform across regions. What you can provision in one Australian region may differ from another, and capacity for popular models genuinely runs out. Do not assume that because a deployment worked in one region last month, the same call will succeed in another region today. Check availability as part of your process rather than discovering the gap in the middle of a go-live.

And a smaller one: API versions matter. These endpoints are versioned by date, and behaviour shifts between versions. Pin a version you have tested against rather than drifting onto whatever is newest, or you will eventually get a surprise from a change you did not make.

Where this fits in a real project

For most businesses the account management API is not something you sit down and "use" as a project in itself. It is the layer your provisioning and governance tooling stands on. You will spend the bulk of your day-to-day in Bicep for standing things up and in the data plane for the actual AI work. The account API earns its place in the middle: the audits, the guardrails, the pipeline checks, the tooling that keeps a growing estate honest.

The teams that get real value from it are the ones who stopped treating Azure AI resources as things you create once and forget, and started treating them as an estate that needs the same discipline as any other piece of production infrastructure. Naming, tagging, region control, key hygiene, drift detection. The account API is how you enforce that discipline in code rather than in a wiki page nobody reads.

If you are past the single-resource stage and starting to feel the sprawl, or you need to prove to an auditor exactly what AI resources you are running and where, that governance layer is bread-and-butter work for our team. Have a look at how we approach business AI more broadly, or get in touch and we will help you get your Azure AI estate under proper control before it gets away from you.