In the invite email I use the variable "$ConfirmUrl" but in the received email it generates a url like https://myservice.portal.azure-api.net and it doesn't work

Question

Hello,

In the template email to invite user I use the parameter :

$ConfirmUrl

Then, the new user receives the email with the following url :

https://myservice.portal.azure-api.net/confirm-v2/identities/basic/invite?userid=myUser&identity=myUserEmail&ticketid=...&ticket=...

When the user clicks on the link :

1. there is a security alert from the brower and if I by-passe the alert
2. it returns an error page "Service Unavailable"

To me there are 2 problems :

1. it should work
2. the url should use the custom domain name instead of the technical one

Do you know how I can fix this?

Best regards.

Answer 1

Hello Julien !

Thank you for posting on Microsoft Learn.

What’s happening?

$ConfirmUrl always builds the link from the first host name that APIM considers to be the “developer-portal” endpoint.

On a new portal that’s the built-in host <service>.developer.azure-api.net.

On an old/legacy portal it’s …portal.azure-api.net – that host was retired in October 2023, so it now serves a wild-card certificate that modern browsers flag as “unsafe” and then returns 503 / Service Unavailable. ([github.com](https://github.com/Azure/api-management-developer-portal/issues/1157"Guest user verification failed · Issue #1157 · Azure/api-management-developer-portal · GitHub"), [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/api-management/developer-portal-self-host"Self-host the API Management developer portal - Azure API Management | Microsoft Learn"))

Because the host is wrong, the link both triggers a certificate warning and cannot resolve to a running site exactly what your users see.

How to fix it ?

Move the developer portal to the right host name (either the modern built-in one or your own custom domain).

Azure portal → your APIM → Custom domains → “Developer portal”.

Add portal.mycompany.com (or whatever you want) and upload/assign a TLS cert.

Make sure a CNAME in DNS points that name to the APIM gateway host.

Save – the APIM infrastructure update can take 15-30 min. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/api-management/configure-custom-domain"Configure custom domain name for Azure API Management instance - Azure API Management | Microsoft Learn"))

Republish the portal (Developer portal → “Publish”) so that APIM marks the new host as the active one.

Send a new invitation – $ConfirmUrl will now come back as

https://portal.mycompany.com/confirm-v2/identities/basic/invite?... 

with a valid cert and will open the sign-up page without errors.

If you can’t wait for the infrastructure change (or you’re self-hosting the portal), edit the Invite user email template:

<!-- old -->
<a href="$ConfirmUrl">$ConfirmUrl</a>
<!-- updated -->
<a href="https://portal.mycompany.com/confirm-v2/identities/basic/invite?$ConfirmQuery">
  https://portal.mycompany.com/confirm-v2/identities/basic/invite?$ConfirmQuery
</a>

$ConfirmQuery is just the long query-string; you prepend the correct base URL and it is the same pattern is recommended by Microsoft for self-hosted portals – see the official docs snippet below. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/api-management/developer-portal-self-host"Self-host the API Management developer portal - Azure API Management | Microsoft Learn"))

Why not just keep using $ConfirmUrl?

Because APIM currently has no setting that lets you rename the built-in host; the macro will always fall back to the obsolete portal.azure-api.net if that host is still registered internally. Overriding the link or assigning a proper custom domain are therefore the only reliable options. The APIM team have an open item about this behaviour (see GitHub issue #1157). ([github.com](https://github.com/Azure/api-management-developer-portal/issues/1157"Guest user verification failed · Issue #1157 · Azure/api-management-developer-portal · GitHub"))

Answer 2

I've just tested again right now and the bug has apparently been fixed.