Purged API Management name still blocked from reuse in a different subscription (same tenant)

Question

Purged API Management name still blocked from reuse in a different subscription (same tenant)

Suzuki, Tetsuya 35

I have an API Management instance that was created, soft-deleted, and successfully purged

in one subscription within our tenant:

Original subscription: (Subscription A)
Service name: tgsmp-apim-dapi01-c-jpe
Purge operation completed: 2026-08-05 04:46:24 UTC (confirmed via Activity Log, operation "Purge API Management Service", status Succeeded)

I can confirm the name is reusable within the same subscription (Subscription A).

However, I now need to deploy a new API Management instance with the exact same name

in a different subscription within the same Microsoft Entra tenant (Subscription B),

for a customer engagement. When attempting this, I get a name-already-in-use error.

Based on the official documentation (https://learn.microsoft.com/en-us/azure/api-management/soft-delete),

I understand this is expected due to the hostname reservation used to prevent dangling DNS /

subdomain takeover, and that this reservation can take anywhere from several days up to

180 days to release depending on subscription type.

Since this is time-sensitive for a customer deployment, I'd like to ask:

Is there any way to manually release this hostname reservation sooner (both subscriptions belong to the same tenant/organization)?
Is a support ticket the only route, or can this be handled via a request like this one?
Roughly how long should I expect to wait if no manual release is possible?

Any guidance would be greatly appreciated.

0 comments

4 answers

Your answer

Answer 1

Suzuki, Tetsuya 35

Correction (please read before answering):

I need to correct my original question. The target subscription is not in the same Microsoft Entra tenant as the original one — it belongs to a completely different tenant/organization.

To clarify:

Original subscription (where the instance was purged): Tenant A
Target subscription (where I need to reuse the name): Tenant B (different organization)

I understand from the documentation that the restriction applies regardless of whether the new subscription is in the same or a different tenant, but I wanted to confirm whether the cross-tenant scenario changes:

The manual release process or eligibility (e.g., does it require verification/consent from both tenant admins?)
The expected wait time compared to a same-tenant scenario
Whether a support ticket needs to be raised from a specific tenant (the original one, or the target one)

Apologies for the earlier inaccuracy, and thank you for your patience.Correction (please read before answering):

I need to correct my original question. The target subscription is not in the same Microsoft Entra tenant as the original one — it belongs to a completely different tenant/organization.

To clarify:

Original subscription (where the instance was purged): Tenant A
Target subscription (where I need to reuse the name): Tenant B (different organization)

I understand from the documentation that the restriction applies regardless of whether the new subscription is in the same or a different tenant, but I wanted to confirm whether the cross-tenant scenario changes:

The manual release process or eligibility (e.g., does it require verification/consent from both tenant admins?)
The expected wait time compared to a same-tenant scenario
Whether a support ticket needs to be raised from a specific tenant (the original one, or the target one)

Apologies for the earlier inaccuracy, and thank you for your patience.

Suzuki, Tetsuya 35 Reputation points

2026-08-08T01:06:59.89+00:00

Thank you so much for this — it's genuinely the clearest and most useful

answer I've received on this so far, and I really appreciate you taking

the time to lay it all out so carefully.

You're right that the hostname itself won't be customer-facing, since a

custom domain and certificate will sit in front of the instance. So

technically I could deploy under an alternate name and it would work fine

functionally.

The reason I've been stuck on the exact name isn't a technical dependency

though — it's that our internal naming convention requires a specific,

consistent identifier across all resources in this environment, and

deviating from it (even just for this one instance) would put us out of

compliance with that standard. So while functionally an alternate name

would work, I'd still need to resolve the naming conflict properly rather

than work around it.

That said, this gives me a much clearer picture of what's actually going

on and what my realistic options are. I'll raise a ticket from Tenant A

as you suggested to get a proper answer on timeline. Thanks again for the

thorough explanation — really helpful.
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-08-08T01:39:23.0933333+00:00

Glad it helped. Post back what support says on the timeline if you get one. nothing documents that duration, so it will make the thread useful to the next person.
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-08-12T14:53:08.3833333+00:00

@Suzuki, Tetsuya Any word back from support on the timeline? And if the thread got you where you needed, marking it helpful makes it easier to find for others.
Suzuki, Tetsuya 35 Reputation points

2026-08-12T21:11:07.2033333+00:00

I reached to MS support directly. They released soft-booked DNS.
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-08-13T02:20:04.6366667+00:00

Good result and useful to know, since the docs didn't provide the hint that support can release it early.
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-08-27T00:11:38.39+00:00

Hello @Suzuki, Tetsuya - Trust you are doing well. If this answer resolved your issue, please accept it or leave an upvote.

Answer 2

Hi @Suzuki, Tetsuya , you've already got the rule right so I won't rehash it. On your three questions, honestly none of them are documented for the cross-tenant case specifically. But here's what I can say.

On the consent question, there's no published process for releasing the reservation early at all, so there's certainly no cross-tenant version of one with a consent step. The only thing the soft-delete doc gives you is that Azure "reserves the service host name to a customer's tenant for a reservation period." So Tenant A is holding it, and anything that releases it has to go through them. Whether Tenant B needs to verify something too, I genuinely don't know, and I don't think it's written down.

This exists to stop subdomain takeover from dangling DNS. It's a security control, not a quota. I wouldn't expect consent from both sides to be the thing that unlocks it.

On wait time, the doc pins the duration to subscription type rather than tenancy: "several days or longer after deletion, depending on the subscription type." Tenancy doesn't appear in that sentence at all, so I see no reason cross-tenant would run slower. Two things about your dates though. That clock starts at deletion, not your purge date, so you might be counting from the wrong day. And the 180 days, I couldn't find that anywhere on that page so I wouldn't plan around it.

On which tenant raises the ticket, same story, nothing documented. But by that same "reserved to a customer's tenant" logic, Tenant A has it, so that's where I'd go from. Tenant B can't hand back something it never had. Worth confirming with support though.

Also since you are on a customer deadline do you actually need the name? What's locked is the service hostname, the <name>.azure-api.net bit. If what really matters is the URL your customer hits, spin it up in Subscription B under any old name and put a custom domain in front of it. Then the public hostname has nothing to do with the service name. Just check custom domains are supported on your tier.

If it has to be that exact string because it's hardcoded somewhere, then yeah, waiting is probably it.

Suzuki, Tetsuya 35 Reputation points

2026-08-08T01:06:06.17+00:00

Thank you so much for this — it's genuinely the clearest and most useful

answer I've received on this so far, and I really appreciate you taking

the time to lay it all out so carefully.

You're right that the hostname itself won't be customer-facing, since a

custom domain and certificate will sit in front of the instance. So

technically I could deploy under an alternate name and it would work fine

functionally.

The reason I've been stuck on the exact name isn't a technical dependency

though — it's that our internal naming convention requires a specific,

consistent identifier across all resources in this environment, and

deviating from it (even just for this one instance) would put us out of

compliance with that standard. So while functionally an alternate name

would work, I'd still need to resolve the naming conflict properly rather

than work around it.

That said, this gives me a much clearer picture of what's actually going

on and what my realistic options are. I'll raise a ticket from Tenant A

as you suggested to get a proper answer on timeline. Thanks again for the

thorough explanation — really helpful.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 3

Hi @Suzuki, Tetsuya , you've already got the rule right so I won't rehash it. On your three questions, honestly none of them are documented for the cross-tenant case specifically. But here's what I can say.

On the consent question, there's no published process for releasing the reservation early at all, so there's certainly no cross-tenant version of one with a consent step. The only thing the soft-delete doc gives you is that Azure "reserves the service host name to a customer's tenant for a reservation period." So Tenant A is holding it, and anything that releases it has to go through them. Whether Tenant B needs to verify something too, I genuinely don't know, and I don't think it's written down.

This exists to stop subdomain takeover from dangling DNS. It's a security control, not a quota. I wouldn't expect consent from both sides to be the thing that unlocks it.

On wait time, the doc pins the duration to subscription type rather than tenancy: "several days or longer after deletion, depending on the subscription type." Tenancy doesn't appear in that sentence at all, so I see no reason cross-tenant would run slower. Two things about your dates though. That clock starts at deletion, not your purge date, so you might be counting from the wrong day. And the 180 days, I couldn't find that anywhere on that page so I wouldn't plan around it.

On which tenant raises the ticket, same story, nothing documented. But by that same "reserved to a customer's tenant" logic, Tenant A has it, so that's where I'd go from. Tenant B can't hand back something it never had. Worth confirming with support though.

Also since you are on a customer deadline do you actually need the name? What's locked is the service hostname, the <name>.azure-api.net bit. If what really matters is the URL your customer hits, spin it up in Subscription B under any old name and put a custom domain in front of it. Then the public hostname has nothing to do with the service name. Just check custom domains are supported on your tier.

If it has to be that exact string because it's hardcoded somewhere, then yeah, waiting is probably it.

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-18T11:06:24.9666667+00:00

Hi @Suzuki, Tetsuya ,
Following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Answer 4

Suzuki, Tetsuya 35

Thank you very much for your support and the helpful guidance throughout this issue. Your answer resolved my problem, and I've now accepted it.

I especially appreciated learning that support can release it early — that wasn't mentioned in the documentation, so it was a valuable insight.

Thanks again for your time and assistance. I'm marking this as resolved.

Best regards,

SHOUMIK CHAKRAVARTY 575 Reputation points

2026-08-27T02:34:19.95+00:00

Thank you @Suzuki, Tetsuya for your valuable feedback. Good to know that things resolved for you. Just on the side note i don't see the Answer has been Accepted. It will be greatly appreciated if you can do so.