API Management User Creation Failure — "User registration is not supported"

Question

Environment

Field	Value
Resource Group	`toby-stg-ext--resource-group`
API Management service	`toby-stg-ext--api-management`
SKU / Tier	`Basic`, capacity 1
Region	`East US 2`

Issue summary

We are unable to create a new user on this API Management instance. Every attempt to create a user — whether via the Azure Resource Manager REST API or manually through the Azure Portal — is rejected with the same error:

400 Bad Request
{"error":{"code":"ValidationError","message":"User registration is not supported.","details":null}}

A team member was able to create a user on this exact same instance a few days before this started, with no configuration changes made in between.

Steps to reproduce

Via Azure CLI (az rest, calling the ARM management API directly):

PUT https://management.azure.com/subscriptions//resourceGroups/toby-stg-ext--resource-group/providers/Microsoft.ApiManagement/service/toby-stg-ext--api-management/users/{userId}?api-version=2024-05-01

Body:
{
  "properties": {
    "firstName": "something",
    "lastName": "something",
    "email": "something",
    "password": "something",
    "state": "active"
  }
}

Result: 400 Bad Request — ValidationError: "User registration is not supported." — every time, with no exceptions.

Via the Azure Portal (manual UI attempt):

Also attempted directly in the Azure Portal (API Management instance → Developer portal → Users → + Add), entering the same user details manually. No progress — the same failure occurs there as well, confirming this isn't specific to how we call the API.

Variations tried (all fail identically)

Password + state: "active" set directly on creation
confirmation: "invite" instead of setting a password directly
An older API version (api-version=2022-08-01) instead of 2024-05-01
Manual attempt through the Azure Portal UI (see above)

What we've already validated (ruled out as the cause)

Check	Result
`portalsettings/delegation`	`enabled: false`, `userRegistration.enabled: false` — not delegating registration anywhere
Service SKU / tier	`Basic` — this tier fully supports native user management (not Consumption or a v2 tier)
`identityProviders`	Empty list — expected, since username/password (Basic) sign-up doesn't require an identity provider entry
`portalsettings/signup`	`enabled: true`
Developer portal provisioning	Reachable `developerPortalUrl`, `provisioningState: Succeeded`

Every documented prerequisite for user creation is correctly configured on our end.

Additional context

This looks identical to a thread reported here a couple months ago — same error code (ValidationError), same message text word-for-word ("User registration is not supported."), on the same tiers (Developer/Basic), reported by multiple unrelated customers starting 2026-05-04:

https://learn.microsoft.com/en-in/answers/questions/5880233/apim-develop-portal-400-user-registration-not-supp

This is not a similar or related error — it is character-for-character identical to what we are receiving. In that thread, a Microsoft engineer attributed the issue to a backend platform update; it self-resolved for those customers around 2026-05-20 without any customer-side configuration change. We believe we may be hitting a recurrence of that same underlying platform issue.

As of this post, our issue has been ongoing for over 14 hours with no signs of resolving on its own, and no related incident is currently listed in Azure Service Health / Azure status history.

Request IDs for reference

A recent failed attempt (2026-07-07) returned the following request IDs, in case a Microsoft engineer can use them to look up the exact failed call on their end:

x-ms-request-id: 7fb16b04-67da-4664-95ba-ef82b76c0f82
x-ms-correlation-request-id: 7fb16b04-67da-4664-95ba-ef82b76c0f82

Question

Is this a recurrence of the platform issue from thread #5880233? Is there anything we can check or do on our side, or is this purely a backend issue that needs a Microsoft-side fix like last time?

Answer

Hi @Julián Guerrero ,

Welcome to Microsoft Q&A portal. Thank you for posting your question here.

The issue you are facing is a known issue in API Management services. And Product team is working on the fix.

Mitigation Steps:

Go to identities -> settings -> and disable the redirect anonymous users to sign in page option and issue should be resolved then.

Please let me know if this resolves the issue and need any further help.Please accept User's image the answer if you found the answer to be helpful as it may help other community members.

Answer

Hello Julián,

Greetings! Thanks for raising this question in the Q&A forum.

Based on what you have already ruled out, this does look like a strong match to the prior platform issue in thread #5880233. The error text is identical character for character, it is occurring on the same tiers (Developer/Basic), it is failing consistently through both the ARM REST API and the Portal UI (which rules out anything specific to your calling code), and you have already eliminated every documented customer side cause: delegation disabled, signup enabled, tier correct, and no identity provider misconfiguration since Basic tier username and password signup does not depend on one. When every documented prerequisite is satisfied and the failure is still 100 percent reproducible across both entry points, the remaining explanation is almost always on the service backend rather than your configuration.

Do a quick final check on portalsettings/signup terms and identity requirements Even though you confirmed enabled: true, pull the full object once more since a subtle nested flag can still block user creation silently:

az rest --method GET \
  --url "https://management.azure.com/subscriptions//resourceGroups/toby-stg-ext--resource-group/providers/Microsoft.ApiManagement/service/toby-stg-ext--api-management/portalsettings/signup?api-version=2024-05-01"

Look specifically at termsOfService.enabled and termsOfService.consentRequired. If consent is required but no terms text is set, some backend versions have been observed returning this exact validation error instead of a terms specific one.

Confirm this is not scoped to a single region or a specific control plane node Since the prior incident's resolution was described as a backend platform update rather than anything customer configurable, try the same PUT call against a brand new, throwaway APIM instance in a different region if you have quota available. If user creation also fails there with the identical error, that strongly confirms a platform wide issue rather than something specific to toby-stg-ext--api-management.

Open a support ticket now rather than waiting for self resolution Given this has already been running for over 14 hours with no Service Health incident posted, do not wait on the previous thread's pattern of a 2 to 3 week self resolution. Open a new support request under Azure API Management, reference thread #5880233 directly as precedent, and include your request IDs so the engineer can pull the exact failed call:

x-ms-request-id: 7fb16b04-67da-4664-95ba-ef82b76c0f82
x-ms-correlation-request-id: 7fb16b04-67da-4664-95ba-ef82b76c0f82

https://azure.microsoft.com/en-us/support/create-ticket/

Set the severity based on business impact since user provisioning being fully blocked on a production adjacent instance typically qualifies for a higher severity tier than default.

Set up a Service Health alert for API Management going forward Since the prior occurrence was never listed as an incident on the public Azure status page either, a personalized Service Health alert scoped to your subscription and API Management is the only reliable way to get proactive notice if Microsoft posts an internal advisory before you notice through user reports:

Azure portal > Service Health > Health alerts > Create service health alert

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.