docs: update links for local evaluation and edge proxy docs

docs/docs/administration-and-security/billing-api-usage.md

@@ -117,11 +117,11 @@ application. For example, when a user visits a certain part of your application
 a mobile application is brought to the foreground.
 * Consider using an Edge Proxy as your source of flags instead of calling the Flagsmith API directly.
 * If you have a suitable backend, consider evaluating flags server-side instead. This enables other usage patterns that
-result in fewer API calls, such as [Local Evaluation](/integrating-with-flagsmith/integration-overview#local-evaluation-mode) and custom cache implementations.
+result in fewer API calls, such as [Local Evaluation](/integrating-with-flagsmith/sdks/#local-evaluation) and custom cache implementations.
 
 For server-side applications:
 
-* Consider using [Local Evaluation](/integrating-with-flagsmith/integration-overview#local-evaluation-mode), or deploying [Edge Proxies](/performance/edge-proxy).
+* Consider using [Local Evaluation](/integrating-with-flagsmith/sdks/#local-evaluation), or deploying [Edge Proxies](/performance/edge-proxy).
 * Reduce the polling rate for Edge Proxies and any SDKs using Local Evaluation.
 * If your use case allows for it, use the Flagsmith SDK in Offline Mode.
 

docs/docs/administration-and-security/governance-and-compliance/api-usage.md

@@ -7,7 +7,7 @@ Flagsmith will track API calls made by the SDKS and store them in its data-store
 1. Get Flags
 2. Get Identity Flags
 3. Set Identity Traits
-4. Get [Environment Document](/integrating-with-flagsmith/integration-overview) (for local evaluation SDKs)
+4. Get [Environment Document](/integrating-with-flagsmith/sdks/#the-environment-document) (for local evaluation SDKs)
 
 ![API Usage](/img/api-usage.png)
 

docs/docs/best-practices/defensive-coding.md

@@ -27,7 +27,7 @@ So with that in mind, here are some rules you can follow to avoid any issues ste
 
 The solution here really depends on which of our SDKs you are using. By default our Client SDKs will not block your main application thread, and are designed to work around an asynchronous callback model.
 
-Where our Server Side SDKs are being used, it really depends on if you are using them in [local or remote evaluation mode](/integrating-with-flagsmith/integration-overview). When running in local evaluation mode, once the SDKs have received a response from the API with the Environment related data, they will keep that data in memory. In the event of the SDKs then not receiving an update, they will continue to function.
+Where our Server Side SDKs are being used, it really depends on if you are using them in [local or remote evaluation mode](/integrating-with-flagsmith/sdks/#server-side-sdks). When running in local evaluation mode, once the SDKs have received a response from the API with the Environment related data, they will keep that data in memory. In the event of the SDKs then not receiving an update, they will continue to function.
 
 In the event that the SDKs aren't able to contact the API at all, they will time out and resort to [Default flags](#progressively-enhance-your-application-with-default-flags). When running in remote evaluation mode, you will need to decide what the best approach is based on your particular application. Again, [Default flags](#progressively-enhance-your-application-with-default-flags) can help here.
 
@@ -57,7 +57,7 @@ In addition to this, by default our client-sde SDKs will only make a network cal
 
 ### Server side SDKs and local evaluation mode
 
-If you need sub-millisecond latency for end-to-end flag evaluation, for example in the event that you are running a multi-variate test on a landing page of your website, you can employ one of our Server Side SDKs running in [local evaluation mode](/integrating-with-flagsmith/integration-overview) mode. This will provide sub-millisecond latency of the entire flag evaluation rules engine, running locally within your server infrastructure, allowing you to run multivariate tests with zero latency impact.
+If you need sub-millisecond latency for end-to-end flag evaluation, for example in the event that you are running a multi-variate test on a landing page of your website, you can employ one of our Server Side SDKs running in [local evaluation mode](/integrating-with-flagsmith/sdks/#local-evaluation). This will provide sub-millisecond latency of the entire flag evaluation rules engine, running locally within your server infrastructure, allowing you to run multivariate tests with zero latency impact.
 
 ### No proxy-server required
 

docs/docs/best-practices/efficient-api-usage.md

@@ -39,14 +39,14 @@ That being said, there are use-cases for real time flags. Using our [real-time f
 
 ### Local Evaluation Mode
 
-The most efficient way of evaluating feature flags on the server is using [local evaluation mode](/integrating-with-flagsmith/integration-overview). There are [some caveats](/integrating-with-flagsmith/integration-overview), so please be aware of them!
+The most efficient way of evaluating feature flags on the server is using [local evaluation mode](/integrating-with-flagsmith/sdks/#local-evaluation). There are [some caveats](/integrating-with-flagsmith/sdks/#for-local-evaluation), so please be aware of them!
 
 ### CDN Usage
 
 There are 3 main API calls the Flagsmith SDK can make:
 
-1. Get the [Environment Document](/integrating-with-flagsmith/integration-overview) for
-   [Local Evaluation mode](/integrating-with-flagsmith/integration-overview).
+1. Get the [Environment Document](/integrating-with-flagsmith/sdks/#the-environment-document) for
+   [Local Evaluation mode](/integrating-with-flagsmith/sdks/#local-evaluation).
 2. Get the Flags for an Environment.
 3. Get the Flags for an Identity.
 

docs/docs/deployment-self-hosting/edge-proxy.md

@@ -101,6 +101,8 @@ corresponding client-side key.
 
 #### `api_url`
 
+The URL that edge proxy uses to retrieve the environment document, and poll the Flagsmith API for changes. Defaults to `https://edge.api.flagsmith.com/api/v1`.
+
 If you are self-hosting Flagsmith, set this to your API URL:
 
 ```json
@@ -332,7 +334,7 @@ later, or use `:latest`, to pick up override deletions.
 
 When a **request** matches both an identity override and a segment override, the identity override takes precedence —
 this matches the behaviour of
-[Local Evaluation Mode](/integrating-with-flagsmith/integration-overview#local-evaluation-mode).
+[Local Evaluation Mode](/integrating-with-flagsmith/sdks/#for-local-evaluation).
 
 ## Troubleshooting
 
@@ -401,6 +403,7 @@ If your client is hitting the proxy and the result differs from a direct API cal
   between calls — see [Managing Traits](/performance/edge-proxy#managing-traits).
 - If the result was correct before and is now stale after deleting an identity override, upgrade to Edge Proxy v2.21.1
   or newer (see [Identity overrides](#identity-overrides)).
+- If the evaluation comes from an identity override and your edge proxy fetches updates from the Edge API, ensure the [default](#api_url) `api_url` is used.
 - Disable [endpoint caches](#endpoint_caches) temporarily to rule out a cached response.
 
 ## Production deployment

docs/docs/getting-started/glossary.md

@@ -16,15 +16,15 @@ This glossary provides concise definitions for some of the key concepts within F
 
 - [**Environment**](/flagsmith-concepts/data-model#environments): Environments are a way to separate the configuration of your features. A project can have any number of environments.
 
-- [**Environment Document**](/integrating-with-flagsmith/integration-overview): A JSON document containing all configuration for feature flags in an environment.
+- [**Environment Document**](/integrating-with-flagsmith/sdks/#the-environment-document): A JSON document containing all configuration for feature flags in an environment.
 
 - [**Feature**](/flagsmith-concepts/data-model#features): A configuration that can be enabled, disabled, or set to a specific value. Features are shared across all Environments in a project, but their values/states can be modified between Environments.
 
 - [**Feature Flag**](/getting-started/feature-flags): A boolean or multivariate switch to enable/disable features or set their values dynamically without deploying code.
 
 - [**Identity**](/flagsmith-concepts/data-model#identities): An entity within a particular environment, against which you can manage and override feature settings.
 
-- [**Local Evaluation Mode**](/integrating-with-flagsmith/integration-overview): A mode where the SDK evaluates feature flags locally using a downloaded environment document, reducing latency and API calls.
+- [**Local Evaluation Mode**](/integrating-with-flagsmith/sdks/#local-evaluation): A mode where the SDK evaluates feature flags locally using a downloaded environment document, reducing latency and API calls.
 
 - [**Multivariate Flag**](/managing-flags/core-management): A feature flag that can take on multiple values (not just on/off), useful for A/B testing.
 

docs/docs/integrating-with-flagsmith/sdks/index.md

@@ -288,7 +288,7 @@ These keys are not secret and can be considered public.
 
 ### Server-Side SDK
 
-Server-side SDK Keys give server-side SDKs access to [Local Evaluation](#remote-evaluation) mode.
+Server-side SDK Keys give server-side SDKs access to [Local Evaluation](#local-evaluation) mode.
 
 These keys are secret and should not be shared.
 

docs/docs/performance/edge-proxy.md

@@ -7,21 +7,21 @@ sidebar_position: 10
 The Flagsmith Edge Proxy is a service that you host yourself, that allows you to run an instance of the Flagsmith Engine close to your servers. If you are running Flagsmith within a server-side environment and you want to have very low latency flags, you have two options:
 
 1. Run the Edge Proxy within in your own infrastructure and connect to it from your server-side SDKs
-2. Run your server-side SDKs in [Local Evaluation Mode](/integrating-with-flagsmith/integration-overview).
+2. Run your server-side SDKs in [Local Evaluation Mode](/integrating-with-flagsmith/sdks/#local-evaluation).
 
 The main benefit to running the Edge Proxy is that you reduce your polling requests against the Flagsmith API itself.
 
-The main benefit to running server side SDKs in [Local Evaluation Mode](/integrating-with-flagsmith/integration-overview) is that you get the lowest possible latency.
+The main benefit to running server side SDKs in [Local Evaluation Mode](/integrating-with-flagsmith/sdks/#local-evaluation) is that you get the lowest possible latency.
 
 ## How does it work
 
 :::info
 
-The Edge Proxy has the same [caveats as running our SDK in Local Evaluation mode.](/integrating-with-flagsmith/integration-overview).
+The Edge Proxy has the same [caveats as running our SDK in Local Evaluation mode](/integrating-with-flagsmith/sdks/#for-local-evaluation).
 
 :::
 
-You can think of the Edge Proxy as a copy of our Python Server Side SDK, running in [Local Evaluation Mode](/integrating-with-flagsmith/integration-overview), with an API interface that is compatible with the Flagsmith SDK API.
+You can think of the Edge Proxy as a copy of our Python Server Side SDK, running in [Local Evaluation Mode](/integrating-with-flagsmith/sdks/#local-evaluation), with an API interface that is compatible with the Flagsmith SDK API.
 
 The Edge Proxy runs as a lightweight Docker container. It connects to the Flagsmith API (either powered by us at `edge.api.flagsmith.com` or self hosted by you) to get environment flags and segment rules. You can then point the Flagsmith SDKs to your Edge Proxy; it implements all the current SDK endpoints. This means you can serve a very large number of requests close to your infrastructure and users, at very low latency. Check out the [architecture below](#architecture).
 

docs/docs/sdk-api/flagsmith-api.info.mdx

@@ -27,4 +27,5 @@ Please note that the SDK API is specifically to be used with our [SDKs](/integra
 Flagsmith programmatically, you need to use our private [Core API](/integrating-with-flagsmith/flagsmith-api-overview/admin-api).
 
 You can find the full spec to our Core API [here](https://api.flagsmith.com/api/v1/docs/).
+