API Version 2019-XX-XX Was Not Found For Microsoft.Foo | Fix

You’ll see “api version 2019-xx-xx was not found for microsoft.foo” when a deployment tool sends a management request with an api-version value Azure won’t accept for that provider or resource type.

It pops up in ARM templates, Bicep, Terraform, Pulumi, Azure SDKs, and custom scripts that call the Azure Resource Manager endpoint. The fix is usually quick once you find where the api-version is coming from.

What The Error Usually Means

Azure Resource Manager routes your request to a resource provider, then checks whether the provider is registered for your subscription and whether the resource type allows the api-version you sent.

If either check fails, the message can look odd. “2019-XX-XX” is not a real date. It’s often a placeholder that shows up when a tool didn’t pick a real version, or when a module hard-coded a value that doesn’t exist for the target resource.

• Invalid api-version value — The template or SDK sends a version that never existed for that resource type.
• Provider not registered — The namespace (Microsoft.Foo) isn’t registered in the subscription, so calls for its resource types fail.
• Region mismatch — The provider is registered, but the specific resource type or version isn’t available in the region you’re deploying to.

Most of the time you’ll fix this by registering the provider and switching to an allowed api-version for the exact resource type you’re creating.

API Version 2019-XX-XX Was Not Found For Microsoft.Foo

This line carries three clues: the provider namespace, the api-version you sent, and the fact that Azure rejected it.

Microsoft.Foo is the provider namespace. The resource type is usually shown in the full error text, often right after “for type”. If you only see the namespace, scroll up in your logs to find the resource type string.

Next, look for where api-version is set. In ARM or Bicep it’s the apiVersion field. In raw REST calls it’s the api-version query string. In Terraform it’s often chosen by the provider plugin or by an azapi resource block.

If you’re using Terraform, look for the first failing resource in the plan output, then map it to a provider namespace and type. If you’re using ARM or Bicep, the type is on each resource as type. The type string looks like Microsoft.Foo/widgets or Microsoft.Foo/widgets/subwidgets.

Match the type string exactly when you search provider metadata. A missing plural, a wrong casing segment, or a swapped child name can make you pick a version list for the wrong thing.

Check Whether Microsoft.Foo Is Registered

Provider registration is per subscription. One subscription can be registered while another is not, even inside the same tenant. If your deploy runs under a service principal, it still uses the subscription’s provider state.

Azure CLI Check

• Show the provider state — Run az provider show --namespace Microsoft.Foo --query "registrationState" -o tsv and confirm it says Registered.
• Register the provider — Run az provider register --namespace Microsoft.Foo, then check again after a minute.
• List registered providers — Run az provider list --query "[?registrationState=='Registered'].namespace" -o table to confirm your subscription is in a sane state.

PowerShell Check

• Register the provider — Run Register-AzResourceProvider -ProviderNamespace Microsoft.Foo.
• Verify registration — Run Get-AzResourceProvider -ProviderNamespace Microsoft.Foo and check the registration state.

If registration fails, the error text often changes to something like “MissingSubscriptionRegistration” or “NoRegisteredProviderFound”. That’s a strong hint you’re still stuck on the provider step.

Registration can take a bit, and some providers register in stages. If you register and rerun right away, you may still see the same failure until the state settles.

• Wait and recheck — After you register, rerun az provider show until the state reads Registered.
• Confirm the right subscription — In Azure CLI, run az account show and confirm the subscription ID matches your deployment target.

Find A Valid api-version For The Exact Resource Type

Azure validates api-version per resource type, not just per provider namespace. “Microsoft.Foo” may publish several resource types, each with its own list of allowed versions.

Start with the simplest path: many Azure errors include a list of allowed versions right in the message. If you see that list, pick the newest stable-looking date and try it.

CLI Method That Pinpoints One Resource Type

If you already know the resource type name, query it directly from provider metadata.

• Print api versions for one type — Run az provider show --namespace Microsoft.Foo --query "resourceTypes[?resourceType==''].apiVersions" -o tsv and replace with the resource type string.
• Pick a stable version — Prefer a non-suffix version unless your resource feature needs an early access version.

If you don’t know the resource type, dump the provider’s resourceTypes and search for the type you’re creating. This also helps when you copied a template from another service and the type name is off by one segment.

When you switch versions, expect small schema drift. A field that worked in one api-version can be renamed, moved, or blocked in another. That’s normal. Fix the version first, then fix the payload shape that version expects.

Fix The Place Where api-version Is Coming From

Once you’ve got an allowed version, the remaining work is making sure your tool uses it. Where you edit depends on how you deploy.

If you’re unsure what set the version, search your repo for apiVersion or api-version, then check the rendered template or plan output for the final value.

ARM Template Or Bicep

• Update apiVersion on the resource — Set apiVersion (ARM JSON) or rely on a recent Bicep compiler that emits a valid version for the resource.
• Check nested resources — Child resources often have their own version list. Don’t copy the parent’s version and assume it fits.
• Validate locally — Run a template validation step in your pipeline so the error shows before a full deployment.

Terraform Azurerm Provider

Also check your provider pinning. A lock file or version constraint can keep you on an older plugin even after you edit the version range.

• Remove provider registration skips — If you set skip_provider_registration, unset it unless you have a strong reason, since unregistered providers can yield confusing api-version errors.
• Upgrade the provider plugin — Newer provider releases tend to track newer Azure API versions.
• Refresh provider downloads — Run terraform init -upgrade so your run uses the plugin you expect.
• Check the resource block type — A wrong resource type can push Terraform to a path that uses a version list you didn’t expect.

AzApi Or Custom REST Calls

• Set api_version explicitly — For azapi resources, specify the version that matches the resource type you found in provider metadata.
• Confirm the path — Make sure your resource ID path uses the correct provider namespace and resource type segments.
• Keep versions close to current — If a version is many years old, swap to a newer stable date unless your service docs say otherwise.

After you change the version, rerun the deploy. If the error moves from “api-version not found” to a schema or property error, that’s progress. It means Azure now recognizes the version and is validating your resource body.

Cases That Still Fail After Registration And A Valid Version

Sometimes you pick a valid version and still get blocked. When that happens, the next clues are location, feature flags, and permissions.

Region And SKU Limits

A resource type can be available in one region and blocked in another. A version can also be listed but restricted to certain regions or clouds.

• Try a known-good region — Test the same template in a region where that service is known to run in your tenant.
• Match region strings — Use the exact Azure region name your deployment tool passes, since typos can send you to a default that doesn’t host the service.

Early Access Features And Subscription Flags

Early access versions can require a feature registration or a gated enablement on the subscription. If you choose an early access api-version, check whether the feature is enabled for your subscription.

• Switch to a non-suffix version — If the resource works with a stable api-version, prefer that path.
• Check feature registrations — Look for a feature gate tied to the service, then wait for it to reach a ready state.

Policy And Role Blocks

Azure Policy and RBAC can block provider registration and deployments. If you can’t register Microsoft.Foo, check whether your role allows it and whether policy denies provider changes.

• Run registration as an Owner — Provider registration often needs higher subscription rights.
• Read the policy deny message — If the error includes a policy assignment name, fix that first, then retry.

If you’re on Azure Stack Hub or another constrained cloud, the available api-version set can differ from public Azure. In that case, use the versions documented for your cloud profile.

A Fast Troubleshooting Flow You Can Reuse

If you want a repeatable path that works across tools, follow this flow from top to bottom and stop when the error changes.

1. Capture the full error — Copy the whole message, including the resource type and location lines.
2. Confirm provider registration — Check Microsoft.Foo registration state in the subscription you’re deploying to.
3. Identify the resource type — Find the providers/Microsoft.Foo/ segment for the resource that failed.
4. Get the allowed versions — Use the error’s version list or provider metadata to get valid api-version dates for that type.
5. Update the source of api-version — Edit ARM/Bicep, azapi, or your SDK call so it sends the chosen version.
6. Rerun in the same region — Keep the region fixed to remove one variable, then change region only if the error points to location.
7. Watch for the next error — A new message about properties, SKU, or permissions usually means you cleared the api-version hurdle.

If you see the lowercase string “api version 2019-xx-xx was not found for microsoft.foo” in logs from multiple tools, treat it as a clue that something upstream is defaulting to a placeholder value. That points back to your tool version, plugin version, or a template snippet that got copied from a sample and never filled in.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback