[Docs] Remove anchors from API links

src/content/docs/load-balancing/private-network/magic-wan.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 Consider the following steps to learn how to configure Private Network Load Balancing solution, using [Magic WAN](/magic-wan/) as the on-ramp and off-ramp to securely connect to your private or internal services. This is currently an API only feature.
 
-## 1. Configure a virtual network for Magic Wan
+## 1. Configure a virtual network for Magic WAN
 
 1. Create and [configure virtual networks](/cloudflare-one/connections/connect-networks/private-net/cloudflared/tunnel-virtual-networks/#create-a-virtual-network) using either the Cloudflare UI or the Cloudflare API.
 
@@ -26,10 +26,10 @@ The VNET ID value will be used to ensure that your load balancer is properly int
 
 1. Once you have your [VNets configured](/load-balancing/private-network/magic-wan/#1-configure-a-virtual-network-for-magic-wan), you need to make sure that the [pools](/load-balancing/pools/create-pool/) you will be using with your load balancer are configured with the default VNet value in the **Virtual Network** field.
 
-2. Next, create an Account Load Balancer by sending a `POST` request to the following API endpoint. The request body should be structured similarly to a Zone Load Balancer. Refer to the [Cloudflare API documentation](/api/resources/load_balancers/methods/create/#request-body) for details on the required fields and their formats. Make sure that the pools you are using in your load balancer have the default VNET configured (previous step).
+2. Next, create an Account Load Balancer by sending a `POST` request to the following API endpoint. The request body should be structured similarly to a Zone Load Balancer. Refer to the [Cloudflare API documentation](/api/resources/load_balancers/methods/create/) for details on the required fields and their formats. Make sure that the pools you are using in your load balancer have the default VNET configured (previous step).
 
 ```txt
-https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/load_balancers/
+https://api.cloudflare.com/client/v4/accounts/{account_id}/load_balancers
 ```
 
 To retrieve a list of all created Account Load Balancers, send a `GET` request to the same endpoint.

src/content/docs/workers/configuration/compatibility-dates.mdx

@@ -44,6 +44,6 @@ The compatibility date can be updated in the Workers settings on the [Cloudflare
 
 #### Via the Cloudflare API
 
-The compatibility date can be set when uploading a Worker using the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/#request-body) in the request body's `metadata` field.
+The compatibility date can be set when uploading a Worker using the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/) in the request body's `metadata` field.
 
 If a compatibility date is not specified on upload via the API, it defaults to the oldest compatibility date, before any flags took effect (2021-11-02). When creating new Workers, it is highly recommended to set the compatibility date to the current date when uploading via the API.

src/content/docs/workers/configuration/compatibility-flags.mdx

@@ -41,7 +41,7 @@ Compatibility flags can be updated in the Workers settings on the [Cloudflare da
 
 #### Via the Cloudflare API
 
-Compatibility flags can be set when uploading a Worker using the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/#request-body) in the request body's `metadata` field.
+Compatibility flags can be set when uploading a Worker using the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/) in the request body's `metadata` field.
 
 ## Node.js compatibility flag
 

src/content/docs/workers/platform/limits.mdx

@@ -266,7 +266,7 @@ Note that larger Worker bundles can impact the start-up time of the Worker, as t
 
 A Worker must be able to be parsed and execute its global scope (top-level code outside of any handlers) within 400 ms. Worker size can impact startup because there is more code to parse and evaluate. Avoiding expensive code in the global scope can keep startup efficient as well.
 
-You can measure your Worker's startup time by deploying it to Cloudflare using [Wrangler](/workers/wrangler/). When you run `npx wrangler@latest deploy` or `npx wrangler@latest versions upload`, Wrangler will output the startup time of your Worker in the command-line output, using the `startup_time_ms` field in the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/#request-body).
+You can measure your Worker's startup time by deploying it to Cloudflare using [Wrangler](/workers/wrangler/). When you run `npx wrangler@latest deploy` or `npx wrangler@latest versions upload`, Wrangler will output the startup time of your Worker in the command-line output, using the `startup_time_ms` field in the [Workers Script API](/api/resources/workers/subresources/scripts/methods/update/) or [Workers Versions API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/).
 
 If you are having trouble staying under this limit, consider [profiling using DevTools](/workers/observability/dev-tools/) locally to learn how to optimize your code.