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

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.

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.

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:

1. The manual release process or eligibility (e.g., does it require verification/consent from both tenant admins?)
2. The expected wait time compared to a same-tenant scenario
3. 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:

1. The manual release process or eligibility (e.g., does it require verification/consent from both tenant admins?)
2. The expected wait time compared to a same-tenant scenario
3. 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.