Exposing App Service Staging slot on Azure API Management

This is something I didn’t find documented, so hopefully this article helps others in the future.

When you deploy your web app, web app on Linux, mobile back end, or API app to Azure App Service, you can use a separate deployment slot instead of the default production slot. This helps you to validate your new binaries before swapping it to production and open the changes to the world.

Usually you will manual or smoke test this slot and ensure everything is warmed up before swapping over. Normally this can be done on the dedicated new staging slot URL. However, sometimes you want to ensure that access through your staging slot goes through API Management as well. In our case we wanted secure access through APIM from Azure DevOps pipelines.

Getting the deploy slot domain

You can access the deployment slot for your App Service through ‘Deployment’ > ‘Deployment Slots’, and then click through to the staging slot. There you will see all the details, including the domain name. We will need this for the configuration below.

Note: Starting June 1, 2024, newly created App Service apps can generate a unique default host name that uses the naming convention -..azurewebsites.net. For example: myapp-ds27dh7271aah175.westus-01.azurewebsites.net. Existing app names remain unchanged. This will make configuring APIM slightly harder.

Defining the backend

First of all, we will define a backend on our Azure API Management. Since we’re using an actual Azure resource, we can pick the resource from the list. However, we do not want to target the main slot, but the staging slot. To enable this, we will have to update the Runtime URL field to the domain name of the staging slot.

Finish of by setting the other properties like checking the certificates similar to your main slot.

Adding a new API

Next step is adding a new API, either a complete API similar to your main slot, or maybe a trimmed down API surface that is just enough for your needs. You can even clone your main slot API by hitting the three dots next to the API name.

Changing the policy

Finally you will have to change the backend. To ensure you’re picking the right configuration, the easiest way is to directly modify the policy XML and set the backend-id to the name you just configured:

<policies>
    <inbound>
        <base />
        <set-backend-service id="apim-generated-policy" backend-id="Staging-Web-App" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

If everything is correctly set up, your API call should go through.

Note: If you continue to have 403 Forbidden responses even though you think it should be right, it is ‘always a DNS issue’. We’ve noticed that this was actually the case in our configuration and recreating a new backend with a different name was faster than waiting for DNS or APIM configuration to propagate.