Enabling vnet integration and private endpoint does not remove the public/global dns entry. it only puts up a FW (causing the 403) for that name/IP address. This means that without additional things, your references to the app will use the public IP and be blocked.
You will need to make a private dns zone for the endpoint for your web app with the private IP address (the endpoint). You should name the zone "privatelink.azurewebsites.net", and add your apps and their private ips. You will also need to make sure that private dns zone is linked to the vnet that is calling your app and overrides the public dns entry for your web app.
what is in front of your web apps? we have a similar setup, but have an Azure AppGW in front , with a listener for of our web apps, and our webapps are 100% private, i.e. the Azure AppGW has a front end public IP, and also sits tis backend in our private vnet space. It accepts traffic off the internet via the public IP, matches it via listeners, and request routing rules, and then forwards on the traffic to the appropriate backend pools using the private Ip addresses.
These backend pools are our web apps, using private endpoints.
We have a private DNSZone that is linked to the appgw Vnet, where our App services are listed, with their private ip addresses.
Anywhere we want to reference the web apps, because they are 100% private we either need to use the public listener name and public IP with no private dns link (and go through the appgw), or have a link to that private dns zone which allows us to reference the apps privately.
We try to encourage only using the front end public IP, as that gives us a single place to manage configuration/monitor etc. but your needs might be different.