Fix incorrect md file extensions in docs (#8462)

website/docs/how-to/how-to-add-sso-azure-saml.mdx

@@ -1,6 +1,5 @@
 ---
 title: How to add SSO with SAML 2.0 and Microsoft Entra ID
-slug: 'how-to/how-to-add-sso-azure-saml'
 description: 'Configure Microsoft Entra ID SSO with SAML 2.0 for your Unleash instance.'
 ---
 

website/docs/how-to/how-to-add-strategy-constraints.md

@@ -8,7 +8,7 @@ title: How to add strategy constraints
 
 :::
 
-This guide shows you how to add [strategy constraints](../reference/strategy-constraints.md) to your feature flags using the Admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks/index.md), visit the specific SDK's documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints.md#sdks 'strategy constraints documentation, section on interacting with constraints from client SDKs').
+This guide shows you how to add [strategy constraints](../reference/strategy-constraints) to your feature flags using the Admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks), visit the specific SDK's documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints#sdks).
 
 ## Prerequisites
 
@@ -26,9 +26,9 @@ On the "edit strategy" screen, select the "add constraint" button to open the co
 
 ## Step 2: Add and configure the constraint {#step-2}
 
-Refer to [the _constraint structure_ section of the strategy constraints reference](../reference/strategy-constraints.md#constraint-structure) for a thorough explanation of the constraint fields.
+Refer to [the _constraint structure_ section of the strategy constraints reference](../reference/strategy-constraints#constraint-structure) for a thorough explanation of the constraint fields.
 
-1. From the "Context Field" dropdown, **select the context field** you would like to constrain the strategy on and **choose the [constraint operator](../reference/strategy-constraints.md#strategy-constraint-operators)** you want.
+1. From the "Context Field" dropdown, **select the context field** you would like to constrain the strategy on and **choose the [constraint operator](../reference/strategy-constraints#strategy-constraint-operators)** you want.
 2. **Define the values** to use for this constraint. The operator you selected decides whether you can define one or multiple values and what format they can have.
 3. **Save the constraint** first.
 

website/docs/how-to/how-to-capture-impression-data.mdx

@@ -9,7 +9,7 @@ import VideoContent from "@site/src/components/VideoContent.jsx";
 Placeholders in the code samples below are delimited by angle brackets (i.e. `<placeholder-name>`). You will need to replace them with the values that are correct in _your_ situation for the code samples to run properly.
 :::
 
-Unleash allows you to gather [**impression data**](../reference/impression-data.md) from your feature flags, giving you complete visibility into who checked what flags and when. What you do with this data is entirely up to you, but a common use case is to send it off to an aggregation and analytics service such as [Posthog](https://posthog.com/) or [Google Analytics](https://analytics.google.com/), either just for monitoring purposes or to facilitate [A/B testing](../feature-flag-tutorials/use-cases/a-b-testing.md).
+Unleash allows you to gather [**impression data**](../reference/impression-data) from your feature flags, giving you complete visibility into who checked what flags and when. What you do with this data is entirely up to you, but a common use case is to send it off to an aggregation and analytics service such as [Posthog](https://posthog.com/) or [Google Analytics](https://analytics.google.com/), either just for monitoring purposes or to facilitate [A/B testing](../feature-flag-tutorials/use-cases/a-b-testing).
 
 This guide will take you through everything you need to do in Unleash to facilitate such a workflow. It will show you how to send data to Posthog as an example sink, but the exact same principles will apply to any other service of the same kind.
 
@@ -22,7 +22,7 @@ We will assume that you have the necessary details for your third-party service:
 -   **where to send the data to**. We'll refer to this in the code samples below as **`<sink-url>`**.
 -   **what format the data needs to be in**. This will determine how you transform the event data before you send it.
 
-In addition, you'll need to have a flag to record impression data for and an [Unleash client SDK](../reference/sdks/index.md) that supports impression data. This guide will use the [JavaScript proxy SDK](/docs/generated/sdks/client-side/javascript-browser.md).
+In addition, you'll need to have a flag to record impression data for and an [Unleash client SDK](../reference/sdks) that supports impression data. This guide will use the [JavaScript proxy SDK](/reference/sdks/javascript-browser).
 
 When you have those things sorted, follow the below steps.
 
@@ -36,7 +36,7 @@ When you create a new feature flag via the UI, there's an option at the end of t
 
 ![The create feature flag form. There's a flag at the end of the form that enables or disables impression data. It's labeled "impression data".](/img/enable-impression-data.png)
 
-To create a feature flag with impression data enabled, set the `impressionData` option to `true` in the request payload, as seen below. For more options, check the [reference docs on creating features](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle).
+To create a feature flag with impression data enabled, set the `impressionData` option to `true` in the request payload, as seen below. For more options, check the [reference docs on creating features](/reference/api/legacy/unleash/admin/features-v2#create-toggle).
 
 <ApiRequest
     verb="post"
@@ -51,7 +51,7 @@ To enable impression data for an existing flag, go to the "Settings" tab of that
 
 ![The create feature flag form. There's a flag at the end of the form that enables or disables impression data. It's labeled "impression data".](/img/enable-impression-data-existing-toggle.png)
 
-To enable impression data for an existing flag, use the [API's flag patching functionality](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle):
+To enable impression data for an existing flag, use the [API's flag patching functionality](/reference/api/legacy/unleash/admin/features-v2#patch-toggle):
 
 <ApiRequest
     verb="patch"

website/docs/how-to/how-to-create-feature-toggles.md

@@ -2,7 +2,7 @@
 title: How to create a feature flag
 ---
 
-[Feature flags](../reference/feature-toggles.mdx) are the foundation of Unleash. They are at the core of everything we do and are a fundamental building block in any feature management system. This guide shows you how to create feature flags in Unleash and how to add any optional constraints, segments, variants, and more. Links to learn more about these concepts will be scattered throughout the text.
+[Feature flags](../reference/feature-toggles) are the foundation of Unleash. They are at the core of everything we do and are a fundamental building block in any feature management system. This guide shows you how to create feature flags in Unleash and how to add any optional constraints, segments, variants, and more. Links to learn more about these concepts will be scattered throughout the text.
 
 You can perform every action both via the UI and the admin API. This guide includes screenshots to highlight the relevant UI controls and links to the relevant API methods for each step.
 
@@ -19,9 +19,9 @@ To perform all the steps in this guide, you will need:
 - A running Unleash instance
 - A project to hold the flag
 - A user with an **editor** or **admin** role OR a user with the following permissions inside the target project:
-  - **[project-level permissions](../reference/rbac.md#project-permissions)**
+  - **[project-level permissions](../reference/rbac#project-permissions)**
     - create feature flags
-  - **[environment-level permissions](../reference/rbac.md#environment-permissions)**
+  - **[environment-level permissions](../reference/rbac#environment-permissions)**
     - create/edit variants[^1]
     - create activation strategies
     - update activation strategies
@@ -29,7 +29,7 @@ To perform all the steps in this guide, you will need:
 
 :::info roles
 
-Refer to [the documentation on role-based access control](../reference/rbac.md) for more information about the available roles and their permissions.
+Refer to [the documentation on role-based access control](../reference/rbac) for more information about the available roles and their permissions.
 
 :::
 
@@ -41,11 +41,11 @@ This section takes you through the required steps to create and activate a featu
 
 :::tip API: create a flag
 
-Use the [Admin API endpoint for creating a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). The payload accepts all the same fields as the Admin UI form. The Admin UI also displays the corresponding cURL command when you use the form.
+Use the [Admin API endpoint for creating a feature flag](/reference/api/legacy/unleash/admin/features-v2#create-toggle). The payload accepts all the same fields as the Admin UI form. The Admin UI also displays the corresponding cURL command when you use the form.
 
 :::
 
-In the project that you want to create the flag in, use the "new feature flag" button and fill the form out with your desired configuration. Refer to the [feature flag reference documentation](../reference/feature-toggles.mdx) for the full list of configuration options and explanations.
+In the project that you want to create the flag in, use the "new feature flag" button and fill the form out with your desired configuration. Refer to the [feature flag reference documentation](../reference/feature-toggles) for the full list of configuration options and explanations.
 
 ![](/img/create-toggle-new-toggle.png)
 
@@ -53,11 +53,11 @@ In the project that you want to create the flag in, use the "new feature flag" b
 
 :::tip API: Add a strategy
 
-Use the [API for adding a strategy to a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy). You can find the configuration options for each strategy in the [activation strategy reference documentation](../reference/activation-strategies.md).
+Use the [API for adding a strategy to a feature flag](/reference/api/legacy/unleash/admin/features-v2#add-strategy). You can find the configuration options for each strategy in the [activation strategy reference documentation](../reference/activation-strategies).
 
 :::
 
-Decide which environment you want to enable the flag in. Select that environment and add an activation strategy. Different activation strategies will act differently as described in the [activation strategy documentation](../reference/activation-strategies.md). The configuration for each strategy differs accordingly. After selecting a strategy, complete the steps to configure it.
+Decide which environment you want to enable the flag in. Select that environment and add an activation strategy. Different activation strategies will act differently as described in the [activation strategy documentation](../reference/activation-strategies). The configuration for each strategy differs accordingly. After selecting a strategy, complete the steps to configure it.
 
 ![](/img/create-toggle-add-strategy.png)
 
@@ -65,7 +65,7 @@ Decide which environment you want to enable the flag in. Select that environment
 
 :::tip API: Enable a flag
 
-Use the [API for enabling an environment for a flag](/reference/api/legacy/unleash/admin/features-v2.md#enable-env) and specify the environment you'd like to enable.
+Use the [API for enabling an environment for a flag](/reference/api/legacy/unleash/admin/features-v2#enable-env) and specify the environment you'd like to enable.
 
 :::
 
@@ -79,7 +79,7 @@ These optional steps allow you to further configure your feature flags to add op
 
 ### Add constraints and segmentation
 
-Constraints and segmentation allow you to set filters on your strategies, so that they will only be evaluated for users and applications that match the specified preconditions. Refer to the [strategy constraints](../reference/strategy-constraints.md 'strategy constraints reference documentation') and [segments reference documentation](../reference/segments.mdx) for more information.
+Constraints and segmentation allow you to set filters on your strategies, so that they will only be evaluated for users and applications that match the specified preconditions. Refer to the [strategy constraints](../reference/strategy-constraints) and [segments reference documentation](../reference/segments) for more information.
 
 To add constraints and segmentation, use the "edit strategy" button for the desired strategy.
 
@@ -95,7 +95,7 @@ Constraints aren't fixed and can be changed later to further narrow your audienc
 
 :::tip API: Add constraints
 
-You can either [add constraints when you add the strategy](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy) or [PUT](/reference/api/legacy/unleash/admin/features-v2.md#update-strategy 'PUT an activation strategy') or [PATCH the strategy afterwards](/reference/api/legacy/unleash/admin/features-v2.md#put-strategy)
+You can either [add constraints when you add the strategy](/reference/api/legacy/unleash/admin/features-v2#add-strategy) or [PUT](/reference/api/legacy/unleash/admin/features-v2#update-strategy 'PUT an activation strategy') or [PATCH the strategy afterwards](/reference/api/legacy/unleash/admin/features-v2#put-strategy)
 
 :::
 
@@ -113,7 +113,7 @@ This can be done after you have created a strategy.
 
 :::tip API: add segments
 
-Use the [API for adding segments to a strategy](/reference/api/legacy/unleash/admin/segments.mdx#replace-activation-strategy-segments) to add segments to your strategy.
+Use the [API for adding segments to a strategy](/reference/api/legacy/unleash/admin/segments#replace-activation-strategy-segments) to add segments to your strategy.
 
 :::
 
@@ -131,11 +131,11 @@ This can be done at any point after you've created your flag.
 
 :::tip API: add variants
 
-Use the [update variants endpoint](/reference/api/legacy/unleash/admin/features-v2.md#update-variants). The payload should be your desired variant configuration.
+Use the [update variants endpoint](/reference/api/legacy/unleash/admin/features-v2#update-variants). The payload should be your desired variant configuration.
 
 :::
 
-[Variants](../reference/feature-toggle-variants.md) give you the ability to further target your users and split them into groups of your choosing, such as for A/B testing. On the flag overview page, select the variants tab. Use the "new variant" button to add the variants that you want.
+[Variants](../reference/feature-toggle-variants) give you the ability to further target your users and split them into groups of your choosing, such as for A/B testing. On the flag overview page, select the variants tab. Use the "new variant" button to add the variants that you want.
 
 ![](/img/create-toggle-add-variants.png)
 

website/docs/how-to/how-to-define-custom-context-fields.md

@@ -8,7 +8,7 @@ title: How to define custom context fields
 
 :::
 
-This guide shows you how to create [custom context field for the Unleash Context](../reference/unleash-context.md#custom-context-fields). You can use custom context fields for [strategy constraints](../reference/strategy-constraints.md) and for [custom stickiness calculations](../reference/stickiness.md#custom-stickiness). If there are [standard Unleash Context fields](../reference/unleash-context.md#structure) missing from the context fields page, you can use the same steps to add them too.
+This guide shows you how to create [custom context field for the Unleash Context](../reference/unleash-context#custom-context-fields). You can use custom context fields for [strategy constraints](../reference/strategy-constraints) and for [custom stickiness calculations](../reference/stickiness#custom-stickiness). If there are [standard Unleash Context fields](../reference/unleash-context#structure) missing from the context fields page, you can use the same steps to add them too.
 
 ## Step 1: Navigate to the context field creation form {#step-1-navigate-to-context-fields}
 
@@ -24,7 +24,7 @@ In the Unleash Admin UI, navigate to the _context fields_  page:
 
 ## Step 2: Define the new context field {#step-2-define-new-context-field}
 
-Define the custom context field by filling out the form. You must at least give the field a unique _name_. Everything else is optional. Refer to the [custom context field reference guide](../reference/unleash-context.md#custom-context-fields) for a full overview of the parameters and their functions and requirements.
+Define the custom context field by filling out the form. You must at least give the field a unique _name_. Everything else is optional. Refer to the [custom context field reference guide](../reference/unleash-context#custom-context-fields) for a full overview of the parameters and their functions and requirements.
 
 When you are satisfied with the context field's values, use the "create" button to submit the form and save the context field.
 

website/docs/how-to/how-to-environment-import-export.mdx

@@ -24,21 +24,21 @@ When you export features, the export will contain both feature-specific configur
 
 On the project-level these items are exported:
 
-* [the feature itself](/reference/feature-toggles.mdx)
+* [the feature itself](/reference/feature-toggles)
-* [feature tags](/reference/tags.md)
+* [feature tags](/reference/tags)
 * [feature dependencies](/reference/feature-toggles#feature-flag-dependencies)
 
 On the environment-level, these items are exported for the chosen environment:
 
-* [activation strategies](/reference/activation-strategies.md) including [constraints](/reference/strategy-constraints.md) and references to [segments](/reference/segments.mdx)
+* [activation strategies](/reference/activation-strategies) including [constraints](/reference/strategy-constraints) and references to [segments](/reference/segments)
-* [variants](/reference/feature-toggle-variants.md)
+* [variants](/reference/feature-toggle-variants)
 * enabled/disabled
 
 Additionally, these global configuration items are exported:
-* [custom context fields](/reference/unleash-context.md#custom-context-fields)
+* [custom context fields](/reference/unleash-context#custom-context-fields)
-* [feature tag types](/reference/tags.md#tag-types)
+* [feature tag types](/reference/tags#tag-types)
 
-Importantly, while references to [segments](/reference/segments.mdx) are exported, the segments themselves are **not** exported. Consult the [import requirements](#import-requirements) section for more information.
+Importantly, while references to [segments](/reference/segments) are exported, the segments themselves are **not** exported. Consult the [import requirements](#import-requirements) section for more information.
 
 ## Export
 
@@ -54,7 +54,7 @@ Import is a 3 stage process designed to be efficient and error-resistant.
 
 * **upload** - you can upload previously exported JSON file or copy-paste export data from the exported JSON file into the code editor
 * **validation** - you will get feedback on any errors or warnings before you do the actual import. This ensures your feature flags configurations are correct. You will not be able to finish the import if you have errors. Warnings don't stop you from importing.
-* **import** - the actual import that creates a new configuration in the target environment or creates a [change request]/reference/change-requests.md) when the environment has change requests enabled
+* **import** - the actual import that creates a new configuration in the target environment or creates a [change request](/reference/change-requests) when the environment has change requests enabled
 
 ![The import UI. It has three stages: import, file, validate configuration, finish import.](/img/import.png)
 
@@ -92,7 +92,7 @@ If any of the features you import already exist in the target Unleash instance,
 
 #### Pending change requests
 
-The project and environment you are importing into must **not have any pending [change requests](/reference/change-requests.md)**.
+The project and environment you are importing into must **not have any pending [change requests](/reference/change-requests)**.
 
 ### Import warnings
 
@@ -128,9 +128,9 @@ If change requests are enabled for the target project and environment, the impor
 
 If change requests are enabled, any permissions for **Create activation strategies**, **Delete activation strategies** and **Update variants** are not required.
 
-## Environment import/export vs the [instance import/export API](how-to-import-export.md)
+## Environment import/export vs the instance import/export API
 
-Environment import/export has some similarities to the [instance import/export API](how-to-import-export.md), but they serve different purposes.
+Environment import/export has some similarities to the [instance import/export API](./how-to-import-export), but they serve different purposes.
 
 The instance import/export API was designed to export all feature flags (optionally with strategies and projects) from one Unleash instance to another. When it was developed, Unleash had much fewer features than it does now. As such, the API lacks support for some of the more recent features in Unleash.
 

website/docs/how-to/how-to-run-the-unleash-proxy.mdx

@@ -10,7 +10,7 @@ Placeholders in the code samples below are delimited by angle brackets (i.e. `<p
 
 :::
 
-The [Unleash Proxy](../generated/unleash-proxy.md) provides a way for you to consume feature flags in [front-end clients](../reference/sdks/index.md#front-end-sdks), such as the [JavaScript Proxy client](/docs/generated/sdks/client-side/javascript-browser.md) and [React Proxy client](/docs/generated/sdks/client-side/react.md).
+The [Unleash Proxy](../reference/unleash-proxy) provides a way for you to consume feature flags in [front-end clients](../reference/sdks#front-end-sdks), such as the [JavaScript Proxy client](../reference/sdks/javascript-browser) and [React Proxy client](../reference/sdks/react).
 
 Depending on your setup, the Proxy is most easily run in one of two ways, depending on your situation:
 
@@ -43,7 +43,7 @@ docker pull unleashorg/unleash-proxy
 
 ### 2. Start the Proxy
 
-When running the Proxy, you'll need to provide it with at least the configuration options listed below. Check the reference docs for the [full list of configuration options](../generated/unleash-proxy.md#configuration-options).
+When running the Proxy, you'll need to provide it with at least the configuration options listed below. Check the reference docs for the [full list of configuration options](../reference/unleash-proxy#configuration-options).
 
 ```bash title="Run the Unleash Proxy via Docker"
 docker run \
@@ -82,7 +82,7 @@ npm install @unleash/proxy
 
 ### 3. Configure and start the proxy
 
-Import the `createApp` function from `@unleash/proxy` and configure the proxy. You'll need to provide at least the configuration options highlighted below. Check the reference docs for the [full list of configuration options](../generated/unleash-proxy.md#configuration-options).
+Import the `createApp` function from `@unleash/proxy` and configure the proxy. You'll need to provide at least the configuration options highlighted below. Check the reference docs for the [full list of configuration options](../reference/unleash-proxy#configuration-options).
 
 Here is an example of what running the Proxy as a Node.js app might look like:
 

website/docs/how-to/how-to-schedule-feature-releases.mdx

@@ -27,7 +27,7 @@ This guide assumes that you've got the following:
 
 ## Schedule feature releases with strategy constraints {#strategy-constraints}
 
-[Strategy constraints](../reference/strategy-constraints.md#date-and-time-operators) are the easiest way to schedule feature releases ([as long as your SDKs are up to date](../reference/strategy-constraints.md#incompatibilities)). You can use this approach with _any_ strategy you want. The strategies will work just as they normally do, they just won't become active until the specified time. For example: with the standard strategy, the feature would become available to all your users at the specified time; with a gradual rollout, the rollout would start at the specified time.
+[Strategy constraints](../reference/strategy-constraints#date-and-time-operators) are the easiest way to schedule feature releases ([as long as your SDKs are up to date](../reference/strategy-constraints#incompatibilities)). You can use this approach with _any_ strategy you want. The strategies will work just as they normally do, they just won't become active until the specified time. For example: with the standard strategy, the feature would become available to all your users at the specified time; with a gradual rollout, the rollout would start at the specified time.
 
 ### Step 1: Add an activation strategy with a date-based constraint
 
@@ -41,9 +41,9 @@ To schedule a feature release via the UI:
 
 #### Scheduling a release via the API
 
-To add an activation strategy via the Admin API, use the feature's `strategies` endpoint to add a new strategy (see the [API documentation for adding strategies to feature flags](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy) for more details).
+To add an activation strategy via the Admin API, use the feature's `strategies` endpoint to add a new strategy (see the [API documentation for adding strategies to feature flags](/reference/api/legacy/unleash/admin/features-v2#add-strategy) for more details).
 
-The payload's `"name"` property should contain the name of the strategy to apply (see [activation strategies reference documentation](../reference/activation-strategies.md) for all built-in strategies' _modeling names_).
+The payload's `"name"` property should contain the name of the strategy to apply (see [activation strategies reference documentation](../reference/activation-strategies) for all built-in strategies' _modeling names_).
 
 The `"constraint"` object should have the same format as described in the code sample below. The activation date must be in an [RFC 3339-compatible format](https://datatracker.ietf.org/doc/html/rfc3339#section-5.8), e.g. `"1990-12-31T23:59:60Z"`.
 
@@ -58,27 +58,27 @@ The `"constraint"` object should have the same format as described in the code s
       ]
   }} url="api/admin/projects/<project-id>/features/environments/<environment>/strategies" title="Add a feature activation strategy with a scheduled activation time."/>
 
-The `"operator"` property in the code sample can be replaced with [any of the other date and time-based operators](../reference/strategy-constraints.md#date-and-time-operators) according to your needs.
+The `"operator"` property in the code sample can be replaced with [any of the other date and time-based operators](../reference/strategy-constraints#date-and-time-operators) according to your needs.
 
 ## Schedule feature releases with custom activation strategies {#custom-activation-strategies}
 
 To schedule feature releases without using strategy constraints, you can use custom activation strategies. This requires defining a custom strategy and then implementing that strategy in your SDKs. For detailed instructions on how to do either of these things, refer to their respective how-to guides:
-- [How to _define_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-1)
+- [How to _define_ custom strategies](../how-to/how-to-use-custom-strategies#step-1)
-- [How to _implement_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-3)
+- [How to _implement_ custom strategies](../how-to/how-to-use-custom-strategies#step-3)
 
 ### Step 1: Define and apply a custom activation strategy
 
-**Define a strategy** that takes a parameter that tells it when to activate (visit [the custom activation strategy reference documentation](../reference/custom-activation-strategies.md#definition) for full details on definitions):
+**Define a strategy** that takes a parameter that tells it when to activate (visit [the custom activation strategy reference documentation](../reference/custom-activation-strategies#definition) for full details on definitions):
 
 1. Give the strategy a name. We'll use `enableAfter`.
 2. Give the strategy a required string parameter where the user can enter the time at which the feature should activate. Be sure to describe the format that the user must adhere to.
 3. Save the strategy
 
-[**Apply the strategy** to the feature flag](../how-to/how-to-use-custom-strategies.md#step-2) you want to schedule.
+[**Apply the strategy** to the feature flag](../how-to/how-to-use-custom-strategies#step-2) you want to schedule.
 
 
 ![A custom activation strategy definition for a strategy called `enableAfter`. It takes a required parameter called `start time`: a string in a date format.](/img/custom-strategy-enable-after.png)
 
 ### Step 2: Implement the custom activation strategy in your clients
 
-In each of the client SDKs that will interact with your feature, implement the strategy ([the implementation how-to guide](../how-to/how-to-use-custom-strategies.md#step-3) has steps for all SDK types).
+In each of the client SDKs that will interact with your feature, implement the strategy ([the implementation how-to guide](../how-to/how-to-use-custom-strategies#step-3) has steps for all SDK types).

website/docs/how-to/how-to-setup-provisioning-with-entra.md

@@ -28,7 +28,7 @@ Enable SCIM by turning on the toggle and keep the token Unleash provides you for
 
 :::info Note
 
-This guide assumes you already have an SSO application setup for Unleash. If you don't already have an application configured, please see our [guide](./how-to-add-sso-azure-saml.md) on setting up SSO.
+This guide assumes you already have an SSO application setup for Unleash. If you don't already have an application configured, please see our [guide](./how-to-add-sso-azure-saml) on setting up SSO.
 
 :::
 

website/docs/how-to/how-to-use-custom-strategies.md

@@ -10,7 +10,7 @@ The downside of using a custom activation strategy instead of constraints is tha
 :::
 
 
-This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies.md) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a flag, and how you'd implement it in a [client SDK](../reference/sdks/index.md).
+This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a flag, and how you'd implement it in a [client SDK](../reference/sdks).
 
 In this example we want to define an activation strategy offers a scheduled release of a feature flag. This means that we want the feature flag to be activated after a given date and time.
 
@@ -20,7 +20,7 @@ In this example we want to define an activation strategy offers a scheduled rele
 
    ![A visual guide for how to navigate to the strategies page in the Unleash admin UI. It shows the steps described in the preceding paragraph.](/img/custom-strategy-navigation.png)
 
-2. **Define your strategy**. Use the "Add new strategy" button to open the strategy creation form. Fill in the form to define your strategy. Refer to [the custom strategy reference documentation](../reference/custom-activation-strategies.md#definition) for a full list of options.
+2. **Define your strategy**. Use the "Add new strategy" button to open the strategy creation form. Fill in the form to define your strategy. Refer to [the custom strategy reference documentation](../reference/custom-activation-strategies#definition) for a full list of options.
 
    ![A strategy creation form. It has fields labeled "strategy name" — "TimeStamp" — and "description" — "activate flag after a given timestamp". It also has fields for a parameter named "enableAfter". The parameter is of type "string" and the parameter description is "Expected format: YYYY-MM-DD HH:MM". The parameter is required.](/img/timestamp_create_strategy.png)
 
@@ -35,11 +35,11 @@ In this example we want to define an activation strategy offers a scheduled rele
 The steps to implement a custom strategy for your client depend on the kind of client SDK you're using:
 
 - if you're using a server-side client SDK, follow the steps in [option A](#step-3-a 'Step 3 option A: implement the strategy for a server-side client SDK').
-- if you're using a front-end client SDK ([Android](/docs/generated/sdks/client-side/android-proxy.md), [JavaScript](/docs/generated/sdks/client-side/javascript-browser.md), [React](/docs/generated/sdks/client-side/react.md), [iOS](/docs/generated/sdks/client-side/ios-proxy.md)), follow the steps in [option B](#step-3-b 'Step 3 option B: implementing the strategy for a front-end client SDK')
+- if you're using a front-end client SDK ([Android](../reference/sdks/android-proxy), [JavaScript](../reference/sdks/javascript-browser)), [React](../reference/sdks/react), [iOS](../reference/sdks/ios-proxy)), follow the steps in [option B](#step-3-b 'Step 3 option B: implementing the strategy for a front-end client SDK')
 
 ### Option A: Implement the strategy for a server-side client SDK {#step-3-a}
 
-1. **Implement the custom strategy** in your [client SDK](../reference/sdks/index.md). The exact way to do this will vary depending on the specific SDK you're using, so refer to the SDK's documentation. The example below shows an example of how you'd implement a custom strategy called "TimeStamp" for the [Node.js client SDK](/docs/generated/sdks/server-side/node.md).
+1. **Implement the custom strategy** in your [client SDK](../reference/sdks). The exact way to do this will vary depending on the specific SDK you're using, so refer to the SDK's documentation. The example below shows an example of how you'd implement a custom strategy called "TimeStamp" for the [Node.js client SDK](../reference/sdks/node).
 
    ```js
    const { Strategy } = require('unleash-client');
@@ -89,14 +89,14 @@ The steps to implement a custom strategy for your client depend on the kind of c
 
 ### Option B: Implement the strategy for a front-end client SDK {#step-3-b}
 
-Front-end client SDKs don't evaluate strategies directly, so you need to implement the **custom strategy in the [Unleash Proxy](../generated/unleash-proxy.md)**. Depending on how you run the Unleash Proxy, follow one of the below series of steps:
+Front-end client SDKs don't evaluate strategies directly, so you need to implement the **custom strategy in the [Unleash Proxy](../reference/unleash-proxy)**. Depending on how you run the Unleash Proxy, follow one of the below series of steps:
 
 - If you're running the Unleash Proxy as a Docker container, refer to the [steps for using a containerized Proxy](#step-3-b-docker).
 - If you're using the Unleash Proxy via Node.js, refer to the [steps for using custom strategies via Node.js](#step-3-b-node).
 
 #### With a containerized proxy {#step-3-b-docker}
 
-Strategies are stored in separate JavaScript files and loaded into the container at startup. Refer to [the Unleash Proxy documentation](../generated/unleash-proxy.md) for a full overview of all the options.
+Strategies are stored in separate JavaScript files and loaded into the container at startup. Refer to [the Unleash Proxy documentation](../reference/unleash-proxy) for a full overview of all the options.
 
 1. **Create a strategies directory.** Create a directory that Docker has access to where you can store your strategies. The next steps assume you called it `strategies`
 2. **Initialize a Node.js project** and **install the Unleash Client**:

website/docs/quickstart.md

@@ -29,15 +29,15 @@ password: unleash4all
 2. Click 'New feature flag'
 3. Give it a unique name, and click 'Create feature flag'
 
-For a detailed guide on how to create a flag through the UI, [you can follow this guide](/how-to/how-to-create-feature-toggles.md).
+For a detailed guide on how to create a flag through the UI, [you can follow this guide](/how-to/how-to-create-feature-toggles).
 
 ## 4a. Connect a client-side SDK {#connect-a-client-side-sdk}
 
-To try Unleash with a client-side technology, create a [front-end token](/reference/api-tokens-and-client-keys.mdx#front-end-tokens) and use `<your-unleash-instance>/api/frontend` as the API URL.
+To try Unleash with a client-side technology, create a [front-end token](/reference/api-tokens-and-client-keys#front-end-tokens) and use `<your-unleash-instance>/api/frontend` as the API URL.
 
 Now you can open your application code and connect through one of the [client-side SDKs](/reference/sdks#client-side-sdks).
 
-The following example shows you how you could use the [JavaScript SDK](/generated/sdks/client-side/javascript-browser.md) to connect to the Unleash demo frontend API:
+The following example shows you how you could use the [JavaScript SDK](/reference/sdks/javascript-browser) to connect to the Unleash demo frontend API:
 
 ```javascript
 import { UnleashClient } from "unleash-proxy-client";
@@ -62,7 +62,7 @@ unleash.on("synchronized", () => {
 
 To try Unleash with a server-side technology, create a [client token](/reference/api-tokens-and-client-keys#client-tokens) and use `<your-unleash-instance>/api` as the API URL.
 
-Now you can open up your application code and create a connection to Unleash using one of our [SDKs](/reference/sdks/index.md). Here's an example using the [NodeJS SDK](/reference/sdks/node) to connect to the Unleash demo instance:
+Now you can open up your application code and create a connection to Unleash using one of our [SDKs](/reference/sdks). Here's an example using the [NodeJS SDK](/reference/sdks/node) to connect to the Unleash demo instance:
 
 ```javascript
 const { initialize } = require("unleash-client");
@@ -116,4 +116,4 @@ You can run Unleash in the cloud by using our hosted offerings. Please see the [
 
 ### Other Local Setup Options
 
-There are several [more options to get started locally.](using-unleash/deploy/getting-started.md)
+There are several [more options to get started locally.](using-unleash/deploy/getting-started)

website/docs/reference/actions.md

@@ -34,11 +34,11 @@ When creating a new action you first need to specify a name and a description. T
 
 ### Source and filters
 
-Then you need to select a source. If you haven't created a signal endpoint yet, you can do so by using the **Create new signal endpoint** link (more information on this in the [Signals](./signals.md) section).
+Then you need to select a source. If you haven't created a signal endpoint yet, you can do so by using the **Create new signal endpoint** link (more information on this in the [Signals](./signals) section).
 
 If the source you selected already received at least one signal, you'll be able to see a preview of the latest signal received. This can help you define the different filters that need to match for the action to be executed.
 
-Filters work similarly to [feature flag strategy constraints](./strategy-constraints.md), where the signal payload acts as the context for the constraint evaluation.
+Filters work similarly to [feature flag strategy constraints](./strategy-constraints), where the signal payload acts as the context for the constraint evaluation.
 
 Filters are completely optional, so if you don't configure any filter your action will always be executed whenever you receive a new signal on the selected source.
 
@@ -46,7 +46,7 @@ Filters are completely optional, so if you don't configure any filter your actio
 
 ### Actions
 
-When these actions are triggered, they execute using the identity of a [service account](./service-accounts.md). As a result, when you later view events in [Event Log](./events#event-log), you’ll see this service account listed as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions.
+When these actions are triggered, they execute using the identity of a [service account](./service-accounts). As a result, when you later view events in [Event Log](./events#event-log), you’ll see this service account listed as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions.
 
 The actions are executed in the same order that they are defined. If a previous action fails, the following actions will not be started. You can add multiple actions to an action set and you can add multiple action sets to a project. Depending on the action you want to execute you will have to provide different parameters.
 
@@ -80,4 +80,4 @@ The limits are as follows:
 Ref: [Unleash Config](https://github.com/Unleash/unleash/blob/859fe098fedc261d646833012d9d408039491075/src/lib/create-config.ts#L577-L604)
 
 ## Sending signals to Unleash
-See [Signals](./signals.md)
+See [Signals](./signals)

website/docs/reference/activation-strategies.md

@@ -4,11 +4,11 @@ title: Activation Strategies
 
 It is powerful to be able to turn a feature on and off instantaneously, without redeploying the application. Activation strategies let you enable a feature only for a specified audience. Different strategies use different parameters. Predefined strategies are bundled with Unleash. The recommended strategy is the gradual rollout strategy with 100% rollout, which basically means that the feature should be enabled to everyone.
 
-Unleash comes with a number of built-in strategies (described below) that can be enhanced with [constraints](https://docs.getunleash.io/reference/strategy-constraints) for fine-grained control. For more advanced use cases, where constraints do not fulfill your needs, you can add your own [custom activation strategies](../reference/custom-activation-strategies.md). However, while activation strategies are _defined_ on the server, the server does not _implement_ the strategies. Instead, activation strategy implementation is done client-side. This means that it is _the client_ that decides whether a feature should be enabled or not.
+Unleash comes with a number of built-in strategies (described below) that can be enhanced with [constraints](https://docs.getunleash.io/reference/strategy-constraints) for fine-grained control. For more advanced use cases, where constraints do not fulfill your needs, you can add your own [custom activation strategies](../reference/custom-activation-strategies). However, while activation strategies are _defined_ on the server, the server does not _implement_ the strategies. Instead, activation strategy implementation is done client-side. This means that it is _the client_ that decides whether a feature should be enabled or not.
 
-All [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) and the [Unleash Proxy](../generated/unleash-proxy.md) implement the default strategies (and allow you to add your own [custom strategy implementations](../reference/custom-activation-strategies.md#implementation)). The [front-end client SDKs](../reference/sdks/index.md#front-end-sdks) do not do the evaluation themselves, instead relying on the [Unleash Proxy](../generated/unleash-proxy.md) to take care of the implementation and evaluation.
+All [server-side client SDKs](../reference/sdks#server-side-sdks) and the [Unleash Proxy](../reference/unleash-proxy) implement the default strategies (and allow you to add your own [custom strategy implementations](../reference/custom-activation-strategies#implementation)). The [front-end client SDKs](../reference/sdks#front-end-sdks) do not do the evaluation themselves, instead relying on the [Unleash Proxy](../reference/unleash-proxy) to take care of the implementation and evaluation.
 
-Some activation strategies require the client to provide the current [Unleash context](unleash-context.md) to the flag evaluation function for the evaluation to be done correctly.
+Some activation strategies require the client to provide the current [Unleash context](unleash-context) to the flag evaluation function for the evaluation to be done correctly.
 
 The following activation strategies are bundled with Unleash and always available:
 
@@ -60,7 +60,7 @@ This strategy has the following modelling name in the code:
 
 :::note SDK compatibility
 
-Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks/index.md#server-side-sdk-compatibility-table) for the full overview.
+Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks#server-side-sdk-compatibility-table) for the full overview.
 
 :::
 

website/docs/reference/api-tokens-and-client-keys.mdx

@@ -2,7 +2,7 @@
 title: API Tokens and Client Keys
 ---
 
-For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks/index.md). More advanced use cases may call for multiple clients, automated feature flag updates, the [Unleash proxy](../generated/unleash-proxy.md) and [Unleash proxy clients](../reference/sdks/index.md#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind.
+For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks). More advanced use cases may call for multiple clients, automated feature flag updates, the [Unleash proxy](../reference/unleash-proxy) and [Unleash proxy clients](../reference/sdks#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind.
 
 This document details the three kinds of tokens and keys that you will need to fully connect any Unleash system:
 
@@ -14,7 +14,7 @@ This document details the three kinds of tokens and keys that you will need to f
 
 :::tip
 
-This section describes what API tokens are. For information on how to create them, refer to the [how-to guide for creating API tokens](../how-to/how-to-create-api-tokens.mdx).
+This section describes what API tokens are. For information on how to create them, refer to the [how-to guide for creating API tokens](../how-to/how-to-create-api-tokens).
 
 :::
 
@@ -54,10 +54,10 @@ By default, only admin users can create API tokens, and only admins can see thei
 
 However, any [client](#client-tokens client tokens) and [front-end tokens](#front-end-tokens) that are applicable to a project, will also be visible to any members of that project that have the `READ_PROJECT_API_TOKEN` permission (all project members by default).
 
-Similarly, any project members with the `CREATE_PROJECT_API_TOKEN` permission can also create client and front-end tokens for that specific project ([how to create project API tokens](../how-to/how-to-create-project-api-tokens.mdx)).
+Similarly, any project members with the `CREATE_PROJECT_API_TOKEN` permission can also create client and front-end tokens for that specific project ([how to create project API tokens](../how-to/how-to-create-project-api-tokens)).
 ### Admin tokens
 
-**Admin tokens** grant _full read and write access_ to all resources in the Unleash server API. Admin tokens have access to all projects, all environments, and all root resources (find out more about [resources in the RBAC document](../reference/rbac.md#core-principles)).
+**Admin tokens** grant _full read and write access_ to all resources in the Unleash server API. Admin tokens have access to all projects, all environments, and all root resources (find out more about [resources in the RBAC document](../reference/rbac#core-principles)).
 
 Use admin tokens to:
 
@@ -65,7 +65,7 @@ Use admin tokens to:
 -   Write custom Unleash UIs to replace the default Unleash admin UI.
 Do **not** use admin tokens for:
 
--   [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
+-   [Client SDKs](../reference/sdks): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
 
 Support for scoped admin tokens with more fine-grained permissions is currently in the planning stage.
 
@@ -99,12 +99,12 @@ It is possible to set a token's expiration date to **never**. However, a token t
 
 Do **not** use personal access tokens for:
 
--   [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
+-   [Client SDKs](../reference/sdks): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
 -   Write custom Unleash UIs: Personal access tokens may expire and their permissions may change. It's better to use [admin tokens](#admin-tokens) tokens instead.
 
 ### Client tokens
 
-**Client tokens** are intended for use in [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) (including the Unleash Proxy) and grant the user permissions to:
+**Client tokens** are intended for use in [server-side client SDKs](../reference/sdks#server-side-sdks) (including the Unleash Proxy) and grant the user permissions to:
 
 -   Read feature flag information
 -   Register applications with the Unleash server
@@ -116,18 +116,18 @@ Each client token is only **valid for a single environment**.
 
 Use client tokens:
 
--   In [server-side client SDKs](../reference/sdks/index.md#server-side-sdks)
+-   In [server-side client SDKs](../reference/sdks#server-side-sdks)
--   To connect [the Unleash Proxy](../generated/unleash-proxy.md) to the Unleash API
+-   To connect [the Unleash Proxy](../reference/unleash-proxy) to the Unleash API
 
 Do **not** use client tokens in:
 
--   [Front-end SDKs](../reference/sdks/index.md#front-end-sdks). You will _not_ be able to connect to the Unleash server due to CORS restrictions. To connect front-end SDKs, choose one of the following options:
+-   [Front-end SDKs](../reference/sdks#front-end-sdks). You will _not_ be able to connect to the Unleash server due to CORS restrictions. To connect front-end SDKs, choose one of the following options:
--   Enable the [Unleash front-end API](./front-end-api.md) and create a [front-end token](#front-end-tokens).
+-   Enable the [Unleash front-end API](./front-end-api) and create a [front-end token](#front-end-tokens).
--   Configure an [Unleash Proxy](../generated/unleash-proxy.md) and use [Proxy client keys](#proxy-client-keys).
+-   Configure an [Unleash Proxy](../reference/unleash-proxy) and use [Proxy client keys](#proxy-client-keys).
 
 ### Front-end tokens
 
-**Front-end tokens** are used with [front-end SDKs](../reference/sdks/index.md#front-end-sdks) when used with the [Unleash front-end API](./front-end-api.md). They grant the user permission to:
+**Front-end tokens** are used with [front-end SDKs](../reference/sdks#front-end-sdks) when used with the [Unleash front-end API](./front-end-api). They grant the user permission to:
 
 -   Read the enabled flags for a given context
 -   Register applications with the Unleash server
@@ -139,15 +139,15 @@ Each front-end token is only **valid for a single environment**.
 
 Use front-end tokens in:
 
--   [Front-end SDKs (also known as _proxy clients_)](../reference/sdks/index.md#front-end-sdks).
+-   [Front-end SDKs (also known as _proxy clients_)](../reference/sdks#front-end-sdks).
 
 Do **not** use front-end tokens in:
 
--   [Server-side SDKs](../reference/sdks/index.md#server-side-sdks). The format is different, so they won't work correctly.
+-   [Server-side SDKs](../reference/sdks#server-side-sdks). The format is different, so they won't work correctly.
 
 ### Format
 
-API tokens come in one of two formats. When we introduced [environments](./environments.md) in Unleash 4.3, we updated the format of the tokens to provide more human-readable information to the user. Both formats are still valid (you don't need to update a working token of the old format) and are described below.
+API tokens come in one of two formats. When we introduced [environments](./environments) in Unleash 4.3, we updated the format of the tokens to provide more human-readable information to the user. Both formats are still valid (you don't need to update a working token of the old format) and are described below.
 
 #### Version 1
 
@@ -200,13 +200,13 @@ Some example client tokens are:
 
 ## Proxy client keys {#proxy-client-keys}
 
-Use proxy client keys to connect [Proxy client SDKs (front-end SDKs)](../reference/sdks/index.md#front-end-sdks) to the [Unleash Proxy](../generated/unleash-proxy.md). As opposed to the [API tokens](#api-tokens), Proxy client keys are _not_ considered secret and are safe to use on any clients (refer to the [the proxy documentation for more about privacy](../generated/unleash-proxy.md#we-care-about-privacy)). They do _not_ let you connect to the Unleash server API.
+Use proxy client keys to connect [Proxy client SDKs (front-end SDKs)](../reference/sdks#front-end-sdks) to the [Unleash Proxy](../reference/unleash-proxy). As opposed to the [API tokens](#api-tokens), Proxy client keys are _not_ considered secret and are safe to use on any clients (refer to the [the proxy documentation for more about privacy](../reference/unleash-proxy#we-care-about-privacy)). They do _not_ let you connect to the Unleash server API.
 
 Proxy client keys are arbitrary strings that you _must_ provide the Unleash proxy with on startup. They can be whatever you want and you **create them yourself**.
 
 :::info Creating proxy client keys
 
-To designate a string as a proxy client key, add it to the `clientKeys` list when starting the proxy, as mentioned in the [_configuration_ section of the Unleash proxy documentation](../generated/unleash-proxy.md#configuration). Connecting clients should then specify the same string as their client key.
+To designate a string as a proxy client key, add it to the `clientKeys` list when starting the proxy, as mentioned in the [_configuration_ section of the Unleash proxy documentation](../reference/unleash-proxy#configuration). Connecting clients should then specify the same string as their client key.
 
 :::
 
@@ -214,7 +214,7 @@ Unleash does not generate proxy client keys for you. Because of this, they have
 
 Use Proxy client keys to:
 
--   Connect [Proxy client SDKs](../reference/sdks/index.md#front-end-sdks) to the [Unleash Proxy](../generated/unleash-proxy.md)
+-   Connect [Proxy client SDKs](../reference/sdks#front-end-sdks) to the [Unleash Proxy](../reference/unleash-proxy)
 -   Connect your own custom Proxy clients (or pure HTTP requests) to the Unleash Proxy
 
 Do **not** use Proxy client keys to:

website/docs/reference/api/legacy/unleash/admin/features.md

@@ -4,7 +4,7 @@ title: /api/admin/features
 
 :::caution Deprecation notice
 
-Most of this API was removed in Unleash v5 (after being deprecated since Unleash v4.3). You should use [the project-based API (/api/admin/projects/:projectId)](/reference/api/legacy/unleash/admin/features-v2.md) instead.
+Most of this API was removed in Unleash v5 (after being deprecated since Unleash v4.3). You should use [the project-based API (/api/admin/projects/:projectId)](/reference/api/legacy/unleash/admin/features-v2.mdx) instead.
 
 :::
 
@@ -18,7 +18,7 @@ In order to access the admin API endpoints you need to identify yourself. Unless
 
 :::caution Deprecation notice
 
-This endpoint was removed in Unleash v5. Please use the [project-based endpoint to fetch all flags](/reference/api/legacy/unleash/admin/features-v2.md#fetching-toggles) instead.
+This endpoint was removed in Unleash v5. Please use the [project-based endpoint to fetch all flags](/reference/api/legacy/unleash/admin/features-v2.mdx#fetching-toggles) instead.
 
 :::
 
@@ -112,7 +112,7 @@ Response format is the same as `api/admin/features`
 
 :::caution Removal notice
 
-This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to fetch specific flags](/reference/api/legacy/unleash/admin/features-v2.md#get-toggle) instead.
+This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to fetch specific flags](/reference/api/legacy/unleash/admin/features-v2.mdx#get-toggle) instead.
 
 :::
 
@@ -142,7 +142,7 @@ Used to fetch details about a specific featureToggle. This is mostly provded to
 
 :::caution Removal notice
 
-This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to create feature flags](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle) instead.
+This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to create feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#create-toggle) instead.
 
 :::
 
@@ -180,7 +180,7 @@ Returns 200-response if the feature flag was created successfully.
 ## Update a Feature Flag {#update-a-feature-toggle}
 
 :::caution Removal notice
-This endpoint was removed in Unleash v5. Please use the [project-based endpoint to update a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#update-toggle) instead.
+This endpoint was removed in Unleash v5. Please use the [project-based endpoint to update a feature flag](/reference/api/legacy/unleash/admin/features-v2.mdx#update-toggle) instead.
 :::
 
 
@@ -253,7 +253,7 @@ Removes the specified tag from the `(type, value)` tuple from the Feature Flag's
 ## Archive a Feature Flag {#archive-a-feature-toggle}
 
 :::caution Removal notice
-This endpoint was removed in v5. Please use the [project-based endpoint to archive flags](/reference/api/legacy/unleash/admin/features-v2.md#archive-toggle) instead.
+This endpoint was removed in v5. Please use the [project-based endpoint to archive flags](/reference/api/legacy/unleash/admin/features-v2.mdx#archive-toggle) instead.
 :::
 
 
@@ -264,7 +264,7 @@ Used to archive a feature flag. A feature flag can never be totally be deleted,
 ## Enable a Feature Flag {#enable-a-feature-toggle}
 
 :::caution Removal notice
-This endpoint was removed in v5. Please use the [project-based endpoint to enable feature flags](/reference/api/legacy/unleash/admin/features-v2.md#enable-env) instead.
+This endpoint was removed in v5. Please use the [project-based endpoint to enable feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#enable-env) instead.
 :::
 
 
@@ -298,7 +298,7 @@ None
 ## Disable a Feature Flag {#disable-a-feature-toggle}
 
 :::caution Removal notice
-This endpoint was removed in v5. Please use the [project-based endpoint to disable feature flags](/reference/api/legacy/unleash/admin/features-v2.md#disable-env) instead.
+This endpoint was removed in v5. Please use the [project-based endpoint to disable feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#disable-env) instead.
 :::
 
 `POST: http://unleash.host.com/api/admin/features/:featureName/toggle/off`
@@ -332,7 +332,7 @@ None
 ## Mark a Feature Flag as "stale" {#mark-a-feature-toggle-as-stale}
 
 :::caution Removal notice
-This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as stale](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle) instead.
+This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as stale](/reference/api/legacy/unleash/admin/features-v2.mdx#patch-toggle) instead.
 :::
 
 
@@ -367,7 +367,7 @@ None
 ## Mark a Feature Flag as "active" {#mark-a-feature-toggle-as-active}
 
 :::caution Removal notice
-This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as not stale](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle) instead.
+This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as not stale](/reference/api/legacy/unleash/admin/features-v2.mdx#patch-toggle) instead.
 :::
 
 `POST: http://unleash.host.com/api/admin/features/:featureName/stale/off`

website/docs/reference/api/legacy/unleash/admin/segments.mdx

@@ -12,11 +12,11 @@ import ApiRequest from '@site/src/components/ApiRequest'; export const basePath
 
 :::note
 
-To use the admin API, you'll need to [create and use an admin API token](/how-to/how-to-create-api-tokens.mdx).
+To use the admin API, you'll need to [create and use an admin API token](/how-to/how-to-create-api-tokens).
 
 :::
 
-The segments API lets you create, read, update, and delete [segments](/reference/segments.mdx).
+The segments API lets you create, read, update, and delete [segments](/reference/segments).
 
 ## Get all segments
 
@@ -330,18 +330,18 @@ This section describes the data objects returned by the endpoints in the segment
 
 :::note `values` and `value`
 
-Some constraint operators only support single values. If a constraint uses one of these operators, the payload will contain a `value` property with the correct value. However, for backwards compatibility reasons, the payload will *also* contain a `values` property. If the operator accepts multiple values, the `value` property will not be present. Visit the [strategy constraints documentation](/reference/strategy-constraints.md) for more information on what operators support what number of values.
+Some constraint operators only support single values. If a constraint uses one of these operators, the payload will contain a `value` property with the correct value. However, for backwards compatibility reasons, the payload will *also* contain a `values` property. If the operator accepts multiple values, the `value` property will not be present. Visit the [strategy constraints documentation](/reference/strategy-constraints) for more information on what operators support what number of values.
 
 :::
 
 | Property          | Type                                                                                          | Required | Description                                                                                                                                                       | Example value            |
 |-------------------|-----------------------------------------------------------------------------------------------|----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------|
 | `contextName`     | string                                                                                        | Yes      | The name of the context field targeted by the constraint.                                                                                                         | `"myContextField"`       |
-| `operator`        | string, the name of one of the [constraint operators](/reference/strategy-constraints.md) | Yes      | The operator to apply to the context field.                                                                                                                       | `"DATE_BEFORE"`          |
+| `operator`        | string, the name of one of the [constraint operators](/reference/strategy-constraints) | Yes      | The operator to apply to the context field.                                                                                                                       | `"DATE_BEFORE"`          |
 | `values`          | a list of strings                                                                             | Yes      | The list of values to apply the constraint operator to.                                                                                                           | `["value a", "value b"]` |
 | `value`           | string                                                                                        | No       | The value to apply the constraint operator to.                                                                                                                    | `"15"`                   |
-| `inverted`        | boolean                                                                                       | No       | Whether the result of [the constraint will be negated or not](/reference/strategy-constraints.md#constraint-negation).                                        | `false`                  |
+| `inverted`        | boolean                                                                                       | No       | Whether the result of [the constraint will be negated or not](/reference/strategy-constraints#constraint-negation).                                        | `false`                  |
-| `caseInsensitive` | boolean string                                                                                | No       | Whether the constraint operator is case sensitive or not. Only [applies to some string-based operators](/reference/strategy-constraints.md#string-operators). | `false`                  |
+| `caseInsensitive` | boolean string                                                                                | No       | Whether the constraint operator is case sensitive or not. Only [applies to some string-based operators](/reference/strategy-constraints#string-operators). | `false`                  |
 
 
 ### Activation strategy {#activation-strategy-type-description}

website/docs/reference/api/legacy/unleash/index.md

@@ -27,7 +27,7 @@ The internal API used by the Admin UI (unleash-frontend). Since v4.0.0 all opera
 
 With versions earlier than v4.0.0 and `insecure` authentication Basic Auth (with curl `-u myemail@test.com:`) is enough.
 
-- [Events API](./admin/events.md)
+- [Events API](./admin/events.mdx)
 - [Feature Flags API](./admin/features.md)
 - [Metrics API](./admin/metrics.md)
 - [Project API](./admin/projects.md)

website/docs/reference/applications.mdx

@@ -10,7 +10,7 @@ import Figure from '@site/src/components/Figure/Figure.tsx'
 
 :::
 
-An **application** is any service that sends requests to the [Unleash Client API](/reference/api/unleash/client), the [Unleash Frontend API](front-end-api.md), the Unleash Admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks/index.md), [Unleash Edge](/docs/generated/unleash-edge.md), the [Unleash proxy](/docs/generated/unleash-proxy.md), and even the Admin UI.
+An **application** is any service that sends requests to the [Unleash Client API](./api/unleash/client), the [Unleash Frontend API](./front-end-api), the Unleash Admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks), [Unleash Edge](./unleash-edge), the [Unleash proxy](./unleash-proxy), and even the Admin UI.
 
 In the Admin UI, you can access Applications in **Configure > Applications**.
 

website/docs/reference/change-requests.mdx

@@ -82,7 +82,7 @@ When a scheduled change request is applied, the person who scheduled it and the
 
 If a change request contains changes that affect a flag that has been archived or a strategy that has been deleted, the change request can not be applied. Unleash will warn you ahead of time if you make changes that conflict with a scheduled change request.
 
-Further, if a strategy, project segment, or [environment-level variant](feature-toggle-variants.md) configuration that is updated in a scheduled change request is updated before the scheduled application time (for instance by a different change request being applied or by updates that circumvent the change request flow), Unleash will suspend the scheduled change request.
+Further, if a strategy, project segment, or [environment-level variant](feature-toggle-variants) configuration that is updated in a scheduled change request is updated before the scheduled application time (for instance by a different change request being applied or by updates that circumvent the change request flow), Unleash will suspend the scheduled change request.
 
 The reason for this is that the scheduled change request would overwrite the recent changes made to the strategy, segment, or environment variants. This could cause unwanted changes to occur, so we require you to take manual action.
 
@@ -111,13 +111,13 @@ Unleash currently offers two distinct ways to schedule changes. Each method has
 
 The first method is through scheduled change requests, as we have explained in the preceding sections. Scheduled change requests make it easy to see all the changes across multiple flags and strategies in one view and makes it easy to reschedule or reject them. However, because scheduled changes rely on flags and strategy configurations, conflicts can arise causing the schedule to fail.
 
-The second method uses Unleash's [constraints](strategy-constraints.md) and the [DATE_AFTER operator](strategy-constraints.md#date-and-time-operators) to encode when changes should take effect. The pros of this method is that because these changes can be applied immediately, you won't run into any conflicts when they happen. The cons are that you'll need to apply the same constraints to all the parts that you want to change and that there is no easy way to see all the changes in one view. You also can not scheduled changes to a segment in this way. When using this option, we recommend that you use [segments](segments.mdx) if you want to schedule multiple changes, so that their application time stays in sync.
+The second method uses Unleash's [constraints](strategy-constraints) and the [DATE_AFTER operator](strategy-constraints#date-and-time-operators) to encode when changes should take effect. The pros of this method is that because these changes can be applied immediately, you won't run into any conflicts when they happen. The cons are that you'll need to apply the same constraints to all the parts that you want to change and that there is no easy way to see all the changes in one view. You also can not scheduled changes to a segment in this way. When using this option, we recommend that you use [segments](segments) if you want to schedule multiple changes, so that their application time stays in sync.
 
 Another important distinction is how these changes affect your connected SDKs. If you use constraints (or segments), then any connected SDK will be aware of the schedule ahead of time. That means that even if the SDK can not connect to Unleash at the scheduled time, it will still activate the changes because it's encoded in its constraints. On the other hand, if you use change requests to schedule changes, SDKs **must** update their configuration after the scheduled time to be aware of the changes.
 
 ## Change request permissions
 
-Change requests have their own set of environment-specific permissions that can be applied to [custom project roles](rbac.md#custom-project-roles). These permissions let users
+Change requests have their own set of environment-specific permissions that can be applied to [custom project roles](rbac#custom-project-roles). These permissions let users
 
 - approve/reject change requests
 - apply change requests
@@ -125,9 +125,9 @@ Change requests have their own set of environment-specific permissions that can
 
 None of the predefined roles have any change request permissions, so you must create your own project roles to take advantage of change requests. In other words, even a user with the project "owner" role can not approve or apply change requests.
 
-There is no permission to create change requests: **Anyone can create change requests**, even Unleash users with the [root viewer role](rbac.md#predefined-roles). Change requests don't cause any changes until approved and applied by someone with the correct permissions.
+There is no permission to create change requests: **Anyone can create change requests**, even Unleash users with the [root viewer role](rbac#predefined-roles). Change requests don't cause any changes until approved and applied by someone with the correct permissions.
 
-You can prevent non-project members from submitting change requests by setting a [protected project collaboration mode](project-collaboration-mode.md).
+You can prevent non-project members from submitting change requests by setting a [protected project collaboration mode](project-collaboration-mode).
 
 ### Circumventing change requests
 
@@ -149,24 +149,24 @@ Admin users will always see the change request UI so that they can test the chan
 
 :::
 
-Changes to project [segments](segments.mdx) (as opposed to global segments) also go through the change request process. This is to prevent a backdoor in the change request process.
+Changes to project [segments](segments) (as opposed to global segments) also go through the change request process. This is to prevent a backdoor in the change request process.
 
 Since projects segments are not environment specific and change requests are always environment specific we allow to attach segment change to any environment with change requests enabled.
-When you make changes though the Change Request UI it will automatically select first environment with change requests enabled, giving priority to [production](environments.md#environment-types) environments.
+When you make changes though the Change Request UI it will automatically select first environment with change requests enabled, giving priority to [production](environments#environment-types) environments.
 
 Changes to segments can be only circumvented by admin users through the API calls.
 
 ## Change Request Preview Playground
 
-To verify that a change request is correct, you can preview the result of change request's application in a change request  [playground](playground.mdx). 
+To verify that a change request is correct, you can preview the result of change request's application in a change request  [playground](playground). 
 
 ![Change request preview](/img/change-request-preview.png)
 
-From the change request overview page, go to the corresponding [playground](playground.mdx) and evaluate all your flags in the project and environment that your change request applies too.
+From the change request overview page, go to the corresponding [playground](playground) and evaluate all your flags in the project and environment that your change request applies too.
 
 ![Change request playground evaluation](/img/change-request-playground-evaluation.png)
 
-[Unleash context](playground.mdx#the-unleash-context) can be adjusted in the same way as in a regular playground, but the project and environment cannot be changed as they are derived from the change request itself.
+[Unleash context](playground#the-unleash-context) can be adjusted in the same way as in a regular playground, but the project and environment cannot be changed as they are derived from the change request itself.
 Once the evaluation results confirm the changes in your change request are correct, go back to the change request overview and proceed with the approval or rejection.
 
 

website/docs/reference/environments.md

@@ -35,7 +35,7 @@ The other environment types do not currently have any functionality associated w
 
 ## Global and project-level environments
 
-Environments exist on a global level, so they are available to all projects within Unleash. However, every [project](./projects.md) might not need to use every environment. That's why you can also choose which of the global environments should be available within a project.
+Environments exist on a global level, so they are available to all projects within Unleash. However, every [project](./projects) might not need to use every environment. That's why you can also choose which of the global environments should be available within a project.
 
 ## How to start using environments
 

website/docs/reference/feature-toggle-variants.md

@@ -3,7 +3,7 @@ title: Feature Flag Variants (deprecated)
 ---
 :::warning
 
-Feature Flag Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants.md). 
+Feature Flag Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants). 
 Only features that have existing feature environment variants will keep them. 
 If you'd like to keep the old variants in your hosted instance [contact us](https://slack.unleash.run) for further assistance.
 
@@ -39,7 +39,7 @@ A variant has four components that define it:
 
 - an optional **override**
 
-    Overrides let you specify that certain users (as identified either by their user ID or by another [custom stickiness](./stickiness.md) value) will always get this variant, regardless of the variant's weight.
+    Overrides let you specify that certain users (as identified either by their user ID or by another [custom stickiness](./stickiness) value) will always get this variant, regardless of the variant's weight.
 
 ![A form for adding new variants. It has fields for name, weight, payload, and overrides.](/img/variant-creation-form.png 'Creating a new flag variant')
 
@@ -100,7 +100,7 @@ The variant payload type provides hints to your application about how to parse t
 
 ### Variant stickiness
 
-Variant stickiness is calculated on the received user and context, as described in [the stickiness chapter](./stickiness.md). This ensures that the same user will consistently see the same variant barring overrides and weight changes. If no context data is provided, the traffic will be spread randomly for each request.
+Variant stickiness is calculated on the received user and context, as described in [the stickiness chapter](./stickiness). This ensures that the same user will consistently see the same variant barring overrides and weight changes. If no context data is provided, the traffic will be spread randomly for each request.
 
 
 ## How do I configure variants

website/docs/reference/feature-toggles.mdx

@@ -26,7 +26,7 @@ Activation strategies determine whether a feature flag activates for a specific
 
 ### Strategy variants
 
-You can enhance your feature flags with [strategy variants](./strategy-variants.md). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see.
+You can enhance your feature flags with [strategy variants](./strategy-variants). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see.
 For example, you might use variants to run an A/B testing experiment.
 
 Variants are defined by a name and weight, which determines the likelihood of each variant being shown. [Stickiness](./stickiness) ensures that users consistently see the same variant based on predefined parameters.
@@ -61,7 +61,7 @@ To learn more, visit [Types of feature flags](../what-is-a-feature-flag#types-of
 
 A feature flag can have one of the following states: _active_, _potentially stale_, or _stale_. Unleash marks all flags as _potentially stale_ automatically once they pass their [expected lifetime](#expected-lifetime).
 
-State gives you an indication of when to [clean up a feature flag in code](./technical-debt.md).
+State gives you an indication of when to [clean up a feature flag in code](./technical-debt).
 
 You can also manually change the state on a feature flag's page by going to **Overview** and clicking **Toggle stale state**.
 
@@ -127,7 +127,7 @@ If an archived feature is revived, it starts a new lifecycle with a new [initial
 
 **Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing)
 
-**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) for variants.
+**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table) for variants.
 :::
 
 Feature flag dependencies define a relationship between feature flags. Each feature flag can have one parent, but multiple child flags can share the same parent.

website/docs/reference/impression-data.md

@@ -4,7 +4,7 @@ title: Impression Data
 
 :::note Availability
 
-**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table).
+**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table).
 
 :::
 
@@ -12,7 +12,7 @@ Unleash can provide you with **impression data** about the flags in your applica
 
 :::caution Front-end SDKs and disabled flags
 
-Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](../generated/unleash-proxy.md) or the [Unleash front-end API](../reference/front-end-api.md) would **not** emit impression events when a flag is disabled.
+Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](./unleash-proxy) or the [Unleash front-end API](./front-end-api) would **not** emit impression events when a flag is disabled.
 
 This is because impression data is a **per-flag** setting and the Proxy and front-end API only transmit information about flags that are enabled. As such, the SDK will never know that it should emit an impression event if a flag is disabled.
 
@@ -20,7 +20,7 @@ Some of the front-end SDKs now include a include a configuration property that l
 
 :::
 
-Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature flag and the related [Unleash Context](../reference/unleash-context.md).
+Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature flag and the related [Unleash Context](./unleash-context).
 
 Impression data is **opt-in on a per-flag basis**. Unleash will not emit impression events for flags not marked as such. Once you've turned impression data on for a flag, you can start listening for impression events in your client SDK.
 
@@ -39,7 +39,7 @@ This table describes all the properties on the impression events:
 | --- | --- | --- |
 | `eventType` | The type of the event: `isEnabled` or `getVariant` | All |
 | `eventId` | A globally unique id (GUID) assigned to this event. | All |
-| `context` | A representation of the current [Unleash Context](../reference/unleash-context.md). | All |
+| `context` | A representation of the current [Unleash Context](./unleash-context). | All |
 | `enabled` | Whether the flag was enabled or not at when the client made the request. | All |
 | `featureName` | The name of the feature flag. | All |
 | `variant` | The name of the active variant | `getVariant` events only |
@@ -81,13 +81,13 @@ This table describes all the properties on the impression events:
 
 Impression data is strictly an **opt-in** feature and must be enabled on a **per-flag basis**. You can enable and disable it both when you create a flag and when you edit a flag.
 
-You can enable impression data via the impression data flag in the admin UI's flag creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data.mdx#step-1).
+You can enable impression data via the impression data flag in the admin UI's flag creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data#step-1).
 
 ![A feature flag creation form. At the end of the form is a heading that says "Impression data", a short paragraph that describes the feature, and a flag to opt in or out of it.](/img/create_feat_impression.png)
 
 ## Example setup
 
-The exact setup will vary depending on your [client SDK](../reference/sdks/index.md). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-flag" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready.
+The exact setup will vary depending on your [client SDK](./sdks). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-flag" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready.
 
 ```js
 const unleash = new UnleashClient({

website/docs/reference/integrations/integrations.mdx

@@ -18,12 +18,12 @@ Unleash has two types of integrations: Integrations that allow you to listen to
 
 Unleash currently supports the following integrations out of the box:
 
-- [Datadog](datadog.md) - Allows Unleash to post Updates to Datadog when a feature flag is updated.
+- [Datadog](./integrations/datadog) - Allows Unleash to post Updates to Datadog when a feature flag is updated.
-- [Jira Cloud](jira-cloud-plugin-usage.md) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue
+- [Jira Cloud](./integrations/jira-cloud-plugin-usage) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue
-- [Jira Server](jira-server-plugin-usage.md) - Allows you to create and link Unleash feature flags directly from a Jira Server issue
+- [Jira Server](./integrations/jira-server-plugin-usage) - Allows you to create and link Unleash feature flags directly from a Jira Server issue
-- [Microsoft Teams](teams.md) - Allows Unleash to post updates to Microsoft Teams.
+- [Microsoft Teams](./integrations/teams) - Allows Unleash to post updates to Microsoft Teams.
-- [Slack App](slack-app.md) - The Unleash Slack App posts messages to the selected channels in your Slack workspace.
+- [Slack App](./integrations/slack-app) - The Unleash Slack App posts messages to the selected channels in your Slack workspace.
-- [Webhook](webhook.md) - A generic way to post messages from Unleash to third party services.
+- [Webhook](./integrations/webhook) - A generic way to post messages from Unleash to third party services.
 
 :::tip Missing an integration? Request it!
 
@@ -35,7 +35,7 @@ If you're looking for an integration that Unleash doesn't have at the moment, yo
 
 These integrations are deprecated and will be removed in a future release:
 
-- [Slack](slack.md) - Allows Unleash to post updates to Slack. Please try the new [Slack App](slack-app.md) integration instead.
+- [Slack](./integrations/slack) - Allows Unleash to post updates to Slack. Please try the new [Slack App](./integrations/slack-app) integration instead.
 
 ## Community integrations
 
@@ -57,12 +57,12 @@ Integration events in Unleash provide a streamlined way to debug integrations by
 
 Integration events are logged for all outgoing integrations configured in Unleash. This includes integrations that send information from Unleash to other systems. Currently supported integrations include:
 
- - [Datadog](./datadog.md)
+ - [Datadog](./integrations/datadog)
- - [Microsoft Teams](./teams.md)
+ - [Microsoft Teams](./integrations/teams)
  - New Relic
- - [Slack (deprecated)](./slack.md)
+ - [Slack (deprecated)](./integrations/slack)
- - [Slack App](./slack-app.md)
+ - [Slack App](./integrations/slack-app)
- - [Webhook](./webhook.md)
+ - [Webhook](./integrations/webhook)
 
 ### Viewing integration events
 

website/docs/reference/integrations/jira-cloud-plugin-installation.mdx

@@ -26,7 +26,7 @@ You will need an Unleash admin user to configure the access tokens needed to con
 
 This plugin requires an Unleash Pro or an Unleash Enterprise instance.
 
-We recommend using a [service account](../service-accounts.md) token for communicating with Unleash. Service accounts are also required to integrate with [Change Requests](../change-requests.md)
+We recommend using a [service account](../service-accounts.md) token for communicating with Unleash. Service accounts are also required to integrate with [change requests](../change-requests)
 
 ### Jira
 

website/docs/reference/integrations/jira-cloud-plugin-usage.mdx

@@ -2,6 +2,8 @@
 title: Jira Cloud Integration - Usage
 ---
 
+import Figure from '@site/src/components/Figure/Figure.tsx'
+
 With the Unleash Jira Cloud Plugin you can create, view and manage Unleash feature flags directly from a Jira issue.
 
 The plugin also shows you current status of connected flags.
@@ -42,7 +44,7 @@ from Jira.
 
 ### Change Requests
 
-The plugin respects Unleash's [change requests](../change-requests.md). If change requests are turned on in the connected project and the selected environment, the plugin will ask whether you want to create a change request or not. 
+The plugin respects Unleash's [change requests](../change-requests). If change requests are turned on in the connected project and the selected environment, the plugin will ask whether you want to create a change request or not. 
 
 If you already have an active change request for that project and that environment, the changes will be added to your existing change request.
 

website/docs/reference/integrations/slack.md

@@ -5,7 +5,7 @@ title: Slack (deprecated)
 
 :::caution Deprecation notice
 
-This Slack integration is deprecated and will be removed in a future release. We recommend using the new [Slack App](./slack-app.md) integration instead.
+This Slack integration is deprecated and will be removed in a future release. We recommend using the new [Slack App](./slack-app) integration instead.
 
 :::
 

website/docs/reference/network-view.mdx

@@ -20,7 +20,7 @@ The network view is intended to provide a simple and Unleash-centric overview th
 
 ## Applications
 
-Both the network overview and the network traffic diagrams show you **applications** that have made requests to the Unleash instance. An **application** is defined as anything that sends requests to the [Unleash client API](/reference/api/unleash/client), the [Unleash front-end API](front-end-api.md),  the Unleash admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks/index.md), [Unleash Edge](/docs/generated/unleash-edge.md), the [Unleash proxy](/docs/generated/unleash-proxy.md), and even the admin UI.
+Both the network overview and the network traffic diagrams show you **applications** that have made requests to the Unleash instance. An **application** is defined as anything that sends requests to the [Unleash client API](./api/unleash/client), the [Unleash front-end API](front-end-api),  the Unleash admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks), [Unleash Edge](./unleash-edge), the [Unleash proxy](./unleash-proxy), and even the admin UI.
 
 ### "unknown" applications
 
@@ -66,7 +66,7 @@ This section will refer to the external source as Prometheus for simplicity.
 
 The network view uses an external Prometheus-like API to create diagrams. Because of this, Unleash will not enable the network view feature unless you set the `PROMETHEUS_API` environment variable.
 
-The `PROMETHEUS_API` environment variable should point to the base path of the Prometheus installation, and Prometheus should be configured to get its data from Unleash's [internal backstage API](api/legacy/unleash/internal/prometheus.md). This can for example be done via a scraping job[^2]:
+The `PROMETHEUS_API` environment variable should point to the base path of the Prometheus installation, and Prometheus should be configured to get its data from Unleash's [internal backstage API](api/legacy/unleash/internal/prometheus). This can for example be done via a scraping job[^2]:
 
 ```yaml title="Scraping job for Unleash metrics"
   - job_name: unleash_internal_metrics

website/docs/reference/playground.mdx

@@ -37,7 +37,7 @@ The playground will only evaluate features belonging to the projects you specify
 
 ### The Unleash context
 
-The [Unleash context](../reference/unleash-context.md) represents a client SDK's configuration and used for evaluating your features. You can construct your own context or use a JSON version of a context from a client.
+The [Unleash context](../reference/unleash-context) represents a client SDK's configuration and used for evaluating your features. You can construct your own context or use a JSON version of a context from a client.
 
 #### Multiple values for a single context field
 
@@ -56,7 +56,7 @@ When you specify multiple values for context field, each value will be used to p
 You can add any fields you want to the context used for the evaluation, and you can also leave out any fields you want. However, there are some fields that will be set for you if don't provide them:
 
 -   **`appName`**: Unleash clients all require an `appName` to start up. If you do not provide an `appName`, the playground will assign a default value to this property instead.
--   **`currentTime`**: The `currentTime` property of the [Unleash context](../reference/unleash-context.md) gets auto-populated with the current time. You can override this manually by providing a value of your own.
+-   **`currentTime`**: The `currentTime` property of the [Unleash context](../reference/unleash-context) gets auto-populated with the current time. You can override this manually by providing a value of your own.
 
 ## The response
 
@@ -68,11 +68,11 @@ In the UI, the playground displays the features in a table. Each row of the tabl
 
 <Figure caption='Each row contains a feature and columns for the selected environments. In this screenshot, the "development" and "production" environments have been selected.' img="/img/playground-results-row.png"/>
 
-Because you can add multiple values for each context field, each feature-environment cell contains the number of combinations that evaluated to `true` and `false` for the feature in the given environment. This can be expanded into a more detailed overview over what combinations of context fields evaluated to `true` and `false` along with any [variants](../reference/feature-toggle-variants.md).
+Because you can add multiple values for each context field, each feature-environment cell contains the number of combinations that evaluated to `true` and `false` for the feature in the given environment. This can be expanded into a more detailed overview over what combinations of context fields evaluated to `true` and `false` along with any [variants](../reference/feature-toggle-variants).
 
 <Figure caption='A small table showing the detailed evaluation for a feature in the "development" environment. The provided context contained three values for the "userId" property, so the table contains three rows, showing all different combinations of the context.' img="/img/playground-results-development.png"/>
 
-As with all of Unleash's client SDKs, the playground respects [stickiness](../reference/stickiness.md). The [stickiness algorithm](../reference/stickiness.md#calculation) guarantees that you'll always get the same variants and the same gradual rollout results if you provide the same context, as long as you provide the context field used for calculating stickiness.
+As with all of Unleash's client SDKs, the playground respects [stickiness](../reference/stickiness). The [stickiness algorithm](../reference/stickiness#calculation) guarantees that you'll always get the same variants and the same gradual rollout results if you provide the same context, as long as you provide the context field used for calculating stickiness.
 
 ### The diff view
 
@@ -108,14 +108,14 @@ There's currently two cases where the playground can't evaluate the strategy:
 1. The [strategy is a custom strategy](#custom-strategies) and the playground doesn't have an implementation for the strategy.
 2. The [strategy is the 'Application Hostname' strategy](#application-hostname).
 
-Even if the playground doesn't recognize or otherwise can't evaluate a specific strategy, it _may_ still evaluate the overall strategy result to `false` (and be certain that it is the right result). If a strategy has [constraints](../reference/strategy-constraints.md) or [segments](segments.mdx) that are not satisfied, the playground knows that the strategy result wouldn't be `true`, regardless of the actual strategy implementation. As such, if a strategy can't be evaluated, it can be **either** _unknown_ or _`false`_.
+Even if the playground doesn't recognize or otherwise can't evaluate a specific strategy, it _may_ still evaluate the overall strategy result to `false` (and be certain that it is the right result). If a strategy has [constraints](../reference/strategy-constraints) or [segments](segments) that are not satisfied, the playground knows that the strategy result wouldn't be `true`, regardless of the actual strategy implementation. As such, if a strategy can't be evaluated, it can be **either** _unknown_ or _`false`_.
 
 ### Custom Strategies
 
-The playground does not have any implementations for [custom strategies](../reference/custom-activation-strategies.md) and adding custom strategy implementations to Unleash is not currently supported. Because of this, custom strategies will never be evaluated as `true`.
+The playground does not have any implementations for [custom strategies](../reference/custom-activation-strategies) and adding custom strategy implementations to Unleash is not currently supported. Because of this, custom strategies will never be evaluated as `true`.
 
 ### The Application Hostname strategy {#application-hostname}
 
-The [application hostname strategy](../reference/activation-strategies.md#hostnames) is a little different from the other built-in strategies: it depends on external state and _not_ on the Unleash context to evaluate. In short, the strategy checks its application environment to get the hostname, so the Unleash context has no effect on the result of this strategy.
+The [application hostname strategy](../reference/activation-strategies#hostnames) is a little different from the other built-in strategies: it depends on external state and _not_ on the Unleash context to evaluate. In short, the strategy checks its application environment to get the hostname, so the Unleash context has no effect on the result of this strategy.
 
 Because the application hostname strategy depends on external state, the playground can't guarantee whether the strategy would be true or false in a client. Further, the result in the playground would most likely be different from what you'd see in a client. Because of this, the playground does not evaluate this strategy.

website/docs/reference/project-collaboration-mode.md

@@ -12,9 +12,9 @@ title: Project Collaboration Mode
 
 Project collaboration modes allow you to manage project visibility and interaction levels, ensuring better control and collaboration within your organization.
 
-The collaboration mode of a [project](projects.md) defines who within your Unleash instance can access the project. This setting also determines who can submit [change requests](change-requests.md)–a feature that provides controlled and secure updates for feature flags.
+The collaboration mode of a [project](./projects) defines who within your Unleash instance can access the project. This setting also determines who can submit [change requests](./change-requests)–a feature that provides controlled and secure updates for feature flags.
 
-Unleash supports three collaboration modes: **open**, **protected**, and **private**. A user's [predefined root and project roles](rbac.md#predefined-roles), as well as their [custom root roles](rbac.md#custom-root-roles), determine what projects they can access.
+Unleash supports three collaboration modes: **open**, **protected**, and **private**. A user's [predefined root and project roles](./rbac#predefined-roles), as well as their [custom root roles](./rbac#custom-root-roles), determine what projects they can access.
 
 ## Open collaboration mode
 
@@ -28,7 +28,7 @@ All users of your Unleash instance can view the project but only project Members
 
 ## Private collaboration mode
 
-Only project Members, Admins, Editors, and users with [custom root roles](rbac.md#custom-root-roles) can view the project. Viewers, who are not project Members, can't see the project in the project list. Only project Members and Admins can submit change requests. 
+Only project Members, Admins, Editors, and users with [custom root roles](./rbac#custom-root-roles) can view the project. Viewers, who are not project Members, can't see the project in the project list. Only project Members and Admins can submit change requests. 
 
 
 |           | View project                                                                                    | Submit change requests     |
@@ -39,7 +39,7 @@ Only project Members, Admins, Editors, and users with [custom root roles](rbac.m
 
 # Set project collaboration mode
 
-To [create a new project](projects.md#create-a-project) with a specific collaboration mode, do the following:
+To [create a new project](./projects#create-a-project) with a specific collaboration mode, do the following:
 1. In the Unleash Admin UI, go to **Projects** > **New project**.
 2. Enter **Project name**.
 3. Click **Open** to choose your collaboration mode.

website/docs/reference/projects.mdx

@@ -9,9 +9,9 @@ Projects help you organize feature flags within Unleash. For example, you can us
 
 Each instance requires at least one project. New instances get a default project that all members can access. You cannot delete this project, but you can [rename](#update-a-project) or [archive it](#archive-a-project).
 
-You can configure which [environments](environments.md) are available within a project. By default, all global environments are available. You can only enable and disable feature flags for the environments you've configured for the project.
+You can configure which [environments](./environments) are available within a project. By default, all global environments are available. You can only enable and disable feature flags for the environments you've configured for the project.
 
-By default, projects have an open [collaboration mode](project-collaboration-mode.md), which means all members of your instance can access the project and submit change requests. To learn more, visit [Project Collaboration Mode](project-collaboration-mode.md).
+By default, projects have an open [collaboration mode](./project-collaboration-mode), which means all members of your instance can access the project and submit change requests. To learn more, visit [Project Collaboration Mode](./project-collaboration-mode).
 
 ## Create a project
 
@@ -23,7 +23,7 @@ By default, projects have an open [collaboration mode](project-collaboration-mod
 
 To create a new project:
 1. Go to **Projects** > **New project** and enter a project name.
-2. Optionally configure settings such as [environments](environments.md), [stickiness](stickiness.md), [collaboration mode](project-collaboration-mode.md), and [change requests](change-requests.md).
+2. Optionally configure settings such as [environments](./environments), [stickiness](./stickiness), [collaboration mode](./project-collaboration-mode), and [change requests](./change-requests).
 3. Click **Create project**.
 
 
@@ -37,9 +37,9 @@ To create a new project:
 
 You can update all aspects of a project except its ID.
 
-To update a project, go to **Projects** and select the project you'd like to edit. In the **Project settings** tab, you can update general settings such as project name, description, [stickiness](stickiness.md), [collaboration mode](project-collaboration-mode.md), and more. You can also configure user and API access, [change requests](change-requests.md), and [actions](actions.md), add [segments](segments.mdx) and [environments](environments.md), and update the [default strategy](#project-default-strategy).
+To update a project, go to **Projects** and select the project you'd like to edit. In the **Project settings** tab, you can update general settings such as project name, description, [stickiness](./stickiness), [collaboration mode](./project-collaboration-mode), and more. You can also configure user and API access, [change requests](./change-requests), and [actions](./actions), add [segments](./segments) and [environments](./environments), and update the [default strategy](#project-default-strategy).
 
-The available project settings depend on a user's [root and project roles](rbac.md).
+The available project settings depend on a user's [root and project roles](./rbac).
 
 ## Archive a project
 
@@ -51,7 +51,7 @@ The available project settings depend on a user's [root and project roles](rbac.
 
 The archive projects functionality allows you to hide a project while maintaining historical project data. Archiving lets you manage short-lived projects, for example, to represent specific initiatives in your organization.
 
-Before archiving a project, you must archive all feature flags within it. Archiving automatically disables all project [actions](actions.md). Once you archive a project, you cannot add or move feature flags to it.
+Before archiving a project, you must archive all feature flags within it. Archiving automatically disables all project [actions](./actions). Once you archive a project, you cannot add or move feature flags to it.
 
 To archive a project:
 
@@ -100,9 +100,9 @@ import Figure from '@site/src/components/Figure/Figure.tsx'
 
 :::
 
-Each project has a default strategy of [gradual rollout](activation-strategies.md#gradual-rollout) to 100% of the user base. The default strategy only applies when **no active strategies** are defined for a flag in a specific environment.
+Each project has a default strategy of [gradual rollout](./activation-strategies#gradual-rollout) to 100% of the user base. The default strategy only applies when **no active strategies** are defined for a flag in a specific environment.
 
-You can change the default strategies of a project per environment. You can customize the default strategies by changing the rollout percentage and [stickiness](stickiness.md) and adding [segments](segments.mdx), [constraints](strategy-constraints.md), and [variants](strategy-variants.md).
+You can change the default strategies of a project per environment. You can customize the default strategies by changing the rollout percentage and [stickiness](./stickiness) and adding [segments](./segments), [constraints](./strategy-constraints), and [variants](./strategy-variants).
 
 To change the default strategy for an environment in a project:
 

website/docs/reference/rbac.md

@@ -148,7 +148,7 @@ Custom project roles let you define your own project roles with a specific set o
 environment level. The roles can then be assigned to users in specific projects. All users have viewer access to all
 projects and resources, but must be assigned a project role to be allowed to edit a project's resources. For a
 step-by-step walkthrough of how to create and assign custom project roles, see [_how to create and assign custom project
-roles_](../how-to/how-to-create-and-assign-custom-project-roles.md).
+roles_](../how-to/how-to-create-and-assign-custom-project-roles).
 
 Each custom project role consists of:
 
@@ -190,9 +190,9 @@ You can assign the following permissions on a per-environment level within the p
 | **delete activation strategies** | Lets the user delete feature flag activation strategies within the environment.                                                                                                                                                                                                                                                                       |
 | **enable/disable flags**         | Lets the user enable and disable flags within the environment.                                                                                                                                                                                                                                                                                        |
 | **update variants**              | Lets the user create, edit and remove variants within the environment.                                                                                                                                                                                                                                                                                |
-| **approve a change request**     | Lets the user approve [change requests](change-requests.md) in the environment.                                                                                                                                                                                                                                                                       |
+| **approve a change request**     | Lets the user approve [change requests](./change-requests) in the environment.                                                                                                                                                                                                                                                                       |
 | **apply a change request**       | Lets the user apply change requests in the environment.                                                                                                                                                                                                                                                                                               |
-| **skip change requests**         | Lets the user ignore change request requirements. This applies **only when using the API** directly; when using the admin UI, users with this permission will still need to go through the normal change request flow. You can find more details in the section on [circumventing change requests](change-requests.md#circumventing-change-requests). |
+| **skip change requests**         | Lets the user ignore change request requirements. This applies **only when using the API** directly; when using the admin UI, users with this permission will still need to go through the normal change request flow. You can find more details in the section on [circumventing change requests](./change-requests#circumventing-change-requests). |
 
 ## Multiple Project Roles
 

website/docs/reference/resource-limits.mdx

@@ -15,22 +15,22 @@ To ensure that Unleash operates smoothly, it includes resource limits for some o
 
 The resources and their respective limits and environment variables are:
 
-| Resource                                                        | OSS limit | Pro limit | Enterprise limit | Environment variable                           |
+| Resource                                                       | OSS limit | Pro limit | Enterprise limit | Environment variable                           |
-|-----------------------------------------------------------------|----------:|----------:|-----------------:|------------------------------------------------|
+|----------------------------------------------------------------|----------:|----------:|-----------------:|------------------------------------------------|
-| [Feature flags](feature-toggles.mdx)[^1]                        |     5,000 |     5,000 |           50,000 | `UNLEASH_FEATURE_FLAGS_LIMIT`                  |
+| [Feature flags](./feature-toggles)[^1]                         |     5,000 |     5,000 |           50,000 | `UNLEASH_FEATURE_FLAGS_LIMIT`                  |
-| [Strategies](activation-strategies.md) per flag per environment |        30 |        30 |               30 | `UNLEASH_FEATURE_ENVIRONMENT_STRATEGIES_LIMIT` |
+| [Strategies](./activation-strategies) per flag per environment |        30 |        30 |               30 | `UNLEASH_FEATURE_ENVIRONMENT_STRATEGIES_LIMIT` |
-| [Constraints](strategy-constraints.md) per strategy             |        30 |        30 |               30 | `UNLEASH_CONSTRAINTS_LIMIT`                    |
+| [Constraints](./strategy-constraints) per strategy             |        30 |        30 |               30 | `UNLEASH_CONSTRAINTS_LIMIT`                    |
-| Values per [constraint](strategy-constraints.md)                |       250 |       250 |            1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT`              |
+| Values per [constraint](./strategy-constraints)                |       250 |       250 |            1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT`              |
-| [Segments](segments.mdx)                                        |       300 |       300 |              300 | `UNLEASH_SEGMENTS_LIMIT`                       |
+| [Segments](./segments)                                         |       300 |       300 |              300 | `UNLEASH_SEGMENTS_LIMIT`                       |
-| [API tokens](api-tokens-and-client-keys.mdx)                    |     2,000 |     2,000 |            2,000 | `UNLEASH_API_TOKENS_LIMIT`                     |
+| [API tokens](./api-tokens-and-client-keys)                     |     2,000 |     2,000 |            2,000 | `UNLEASH_API_TOKENS_LIMIT`                     |
-| [Projects](projects.md)                                         |         1 |         3 |              500 | `UNLEASH_PROJECTS_LIMIT`                       |
+| [Projects](./projects)                                         |         1 |         3 |              500 | `UNLEASH_PROJECTS_LIMIT`                       |
-| [Environments](environments.md)                                 |         2 |         2 |               50 | `UNLEASH_ENVIRONMENTS_LIMIT`                   |
+| [Environments](./environments)                                 |         2 |         2 |               50 | `UNLEASH_ENVIRONMENTS_LIMIT`                   |
-| [Signal](signals.md) endpoints                                  |       N/A |       N/A |                5 | `UNLEASH_SIGNAL_ENDPOINTS_LIMIT`               |
+| [Signal](./signals) endpoints                                  |       N/A |       N/A |                5 | `UNLEASH_SIGNAL_ENDPOINTS_LIMIT`               |
-| [Signal](signals.md) tokens per endpoint                        |       N/A |       N/A |                5 | `UNLEASH_SIGNAL_TOKENS_PER_ENDPOINT_LIMIT`     |
+| [Signal](./signals) tokens per endpoint                        |       N/A |       N/A |                5 | `UNLEASH_SIGNAL_TOKENS_PER_ENDPOINT_LIMIT`     |
-| [Action](actions.md) set actions                                |       N/A |       N/A |               10 | `UNLEASH_ACTION_SET_ACTIONS_LIMIT`             |
+| [Action](./actions) set actions                                |       N/A |       N/A |               10 | `UNLEASH_ACTION_SET_ACTIONS_LIMIT`             |
-| [Action](actions.md) sets per project                           |       N/A |       N/A |                5 | `UNLEASH_ACTION_SETS_PER_PROJECT_LIMIT`        |
+| [Action](./actions) sets per project                           |       N/A |       N/A |                5 | `UNLEASH_ACTION_SETS_PER_PROJECT_LIMIT`        |
-| [Action](actions.md) set filters                                |       N/A |       N/A |                5 | `UNLEASH_ACTION_SET_FILTERS_LIMIT`             |
+| [Action](./actions) set filters                                |       N/A |       N/A |                5 | `UNLEASH_ACTION_SET_FILTERS_LIMIT`             |
-| [Action](actions.md) set filter values                          |       N/A |       N/A |               25 | `UNLEASH_ACTION_SET_FILTER_VALUES_LIMIT`       |
+| [Action](./actions) set filter values                          |       N/A |       N/A |               25 | `UNLEASH_ACTION_SET_FILTER_VALUES_LIMIT`       |
 
 ## Overriding the limits
 

website/docs/reference/sdks/index.mdx

@@ -73,31 +73,31 @@ If you see an item marked with a ❌ that you would find useful, feel free to re
 | static | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
 | function | ✅ | ✅ | ⭕ | ✅ | ✅ (4.3) | ✅ | ✅ | ⭕ |
 | **Category: Built-in strategies** |  |  |  |  |  |  |  |  |
-| [Standard](../reference/activation-strategies#standard) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| [Standard](./activation-strategies#standard) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| [Gradual rollout](../reference/activation-strategies#gradual-rollout) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| [Gradual rollout](./activation-strategies#gradual-rollout) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| [Gradual rollout: custom stickiness](../reference/activation-strategies#customize-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
+| [Gradual rollout: custom stickiness](./activation-strategies#customize-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
-| [UserID](../reference/activation-strategies#userids) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| [UserID](./activation-strategies#userids) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| [IP](../reference/activation-strategies#ips) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| [IP](./activation-strategies#ips) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| [IP](../reference/activation-strategies#ips): CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ |
+| [IP](./activation-strategies#ips): CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ |
-| [Hostname](../reference/activation-strategies#hostnames) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| [Hostname](./activation-strategies#hostnames) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| **Category: [Custom strategies](../custom-activation-strategies.md)** |  |  |  |  |  |  |  |  |
+| **Category: [Custom strategies](./custom-activation-strategies)** |  |  |  |  |  |  |  |  |
 | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| <span id="strategy-constraints">**Category: [Strategy constraints](../strategy-constraints.md)**</span> |  |  |  |  |  |  |  |  |
+| <span id="strategy-constraints">**Category: [Strategy constraints](./strategy-constraints)**</span> |  |  |  |  |  |  |  |  |
 | Basic support (`IN`, `NOT_IN` operators) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | <span id="strategy-constraints-advanced-support">Advanced support (Semver, date, numeric, and extended string operators)</span> (introduced in) | ✅ (5.1) | ✅ (3.12) | ✅ (3.3) | ✅ (5.1) | ✅ (4.2) | ✅ (2.1) | ✅ (1.3.1) | ⭕ |
-| **Category: [Unleash Context](../reference/unleash-context)** |  |  |  |  |  |  |  |  |
+| **Category: [Unleash Context](./unleash-context)** |  |  |  |  |  |  |  |  |
 | Static fields (`environment`, `appName`) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Defined fields | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Custom properties | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| **Category: [`isEnabled`](../client-specification#implementation-of-isenabled)** |  |  |  |  |  |  |  |  |
+| **Category: [`isEnabled`](./client-specification#implementation-of-isenabled)** |  |  |  |  |  |  |  |  |
 | Can take context | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Override fallback value | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Fallback function | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ⭕ | ⭕ |
-| **Category: [Variants](../feature-toggle-variants.md)** |  |  |  |  |  |  |  |  |
+| **Category: [Variants](./feature-toggle-variants)** |  |  |  |  |  |  |  |  |
 | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Custom fallback variant | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
 | Custom weight | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
-| [Custom stickiness](../stickiness.md#custom-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
+| [Custom stickiness](./stickiness#custom-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
 | [Strategy Variants](./strategy-variants)| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
 | **Category: Local backup** |  |  |  |  |  |  |  |  |
 | File-based backup | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
@@ -105,7 +105,7 @@ If you see an item marked with a ❌ that you would find useful, feel free to re
 | Can disable metrics | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Client registration | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
 | Basic usage metrics (yes/no) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
-| [Impression data](../impression-data.md) | ✅ | ✅ | ⭕ | ✅ | ⭕ | ⭕ | ✅ | ⭕ |
+| [Impression data](./impression-data) | ✅ | ✅ | ⭕ | ✅ | ⭕ | ⭕ | ✅ | ⭕ |
 | **Category: Bootstrap (beta)** |  |  |  |  |  |  |  |  |
 | Bootstrap from file | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
 | Custom Bootstrap implementation | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
@@ -138,7 +138,7 @@ Here's some of the fantastic work our community has done to make Unleash work in
 If you can't find an SDK that fits your requirements, you can also develop your own SDK. To make implementation easier, check out these resources:
 
 -   [Unleash Client Specifications](https://github.com/Unleash/client-specification) - Used by all official SDKs to make sure they behave correctly across different language implementations. This lets us verify that a gradual rollout to 10% of the users would affect the same users regardless of which SDK you're using.
--   [Client SDK overview](../client-specification) - A brief, overall guide of the _Unleash Architecture_ and important aspects of the SDK role in it all.
+-   [Client SDK overview](./client-specification) - A brief, overall guide of the _Unleash Architecture_ and important aspects of the SDK role in it all.
 
 ## Client-side SDK behavior
 

website/docs/reference/segments.mdx

@@ -14,7 +14,7 @@ import VideoContent from '@site/src/components/VideoContent.jsx'
 
 <VideoContent videoUrls={["https://www.youtube.com/embed/LWMCCFcRic0"]}/>
 
-A **segment** is a reusable collection of [strategy constraints](../reference/strategy-constraints.md). Like with strategy constraints, you apply segments to [feature flag activation strategies](../reference/activation-strategies.md).
+A **segment** is a reusable collection of [strategy constraints](./strategy-constraints). Like with strategy constraints, you apply segments to [feature flag activation strategies](./activation-strategies).
 
 You can apply the same segment to multiple activation strategies. If you update the segment, the changes will affect every strategy that uses that segment.
 
@@ -30,7 +30,7 @@ Because segments stay in sync across strategies, any changes will propagate to a
 -   release one or more new features at a specified time
 -   create events with start and end times and guarantee that features will only be active during that period
 
-Segments can be global or scoped to a specific project. If a segment is scoped to a single project, it can only be used in that project and it adheres to that project's [change request](change-requests.md#change-request-for-segments "change requests for segments") settings.
+Segments can be global or scoped to a specific project. If a segment is scoped to a single project, it can only be used in that project and it adheres to that project's [change request](./change-requests#change-request-for-segments "change requests for segments") settings.
 
 ## Structure and evaluation
 
@@ -52,23 +52,23 @@ In theory, you could create segments with a thousand constraints, each with a mi
 
 By default, you can apply **at most 5 segments to any one strategy**. Separate strategies (even on the same feature) do not count towards the same total, so you can have two strategies with 5 segments each.
 
-You **can** [configure segment limits](/using-unleash/deploy/configuring-unleash.md#segments) with environment variables.
+You **can** [configure segment limits](./using-unleash/deploy/configuring-unleash#segments) with environment variables.
 
 ### A note on large segments {#large-segments}
 
 Segments are just constraints, so any limitations that apply to constraints also apply to segments.
 
-This means that if you want to add a hundred different user IDs to one of your constraints, you are most likely better off thinking about finding another way to solve this problem. That may be using a different abstraction or finding another pattern that you can use instead. Refer to the section on [constraint limitations](../reference/strategy-constraints.md#limitations) for a more thorough explanation or to [the topic guide on using Unleash with large constraints](../understanding-unleash/managing-constraints.mdx) for a more thorough .
+This means that if you want to add a hundred different user IDs to one of your constraints, you are most likely better off thinking about finding another way to solve this problem. That may be using a different abstraction or finding another pattern that you can use instead. Refer to the section on [constraint limitations](../reference/strategy-constraints#limitations) for a more thorough explanation or to [the topic guide on using Unleash with large constraints](../understanding-unleash/managing-constraints) for a more thorough .
 
 ## Creating, updating, and deleting segments
 
 :::info
 
-Currently in development, Unleash will soon count segments as being in use when they are used in [change requests](change-requests.md).
+Currently in development, Unleash will soon count segments as being in use when they are used in [change requests](./change-requests).
 
 :::
 
-Segments can be created, edited, and deleted from the segments page in the admin UI or via the API (see the [segments API documentation](/reference/api/legacy/unleash/admin/segments.mdx)).
+Segments can be created, edited, and deleted from the segments page in the admin UI or via the API (see the [segments API documentation](/reference/api/legacy/unleash/admin/segments)).
 
 A segment that is in use cannot be deleted. If you'd like to delete a segment that is in use, you must first remove the segment from all the activation strategies that are currently using it. If a segment is in use by an archived flag, you must either unarchive the flag and remove the segment or delete the flag entirely before the segment can be deleted.
 

website/docs/reference/sso.md

@@ -21,8 +21,8 @@ In order to configure Single-Sign-On you will need to log in to the Unleash inst
 
 Unleash enterprise supports multiple authentication providers.
 
-- [OpenID Connect with Okta](../how-to/how-to-add-sso-open-id-connect.md)
+- [OpenID Connect with Okta](../how-to/how-to-add-sso-open-id-connect)
-- [SAML 2.0 with Okta](../how-to/how-to-add-sso-saml.md)
+- [SAML 2.0 with Okta](../how-to/how-to-add-sso-saml)
-- [SAML 2.0 with Keycloak](../how-to/how-to-add-sso-saml-keycloak.md)
+- [SAML 2.0 with Keycloak](../how-to/how-to-add-sso-saml-keycloak)
-- [SAML 2.0 with Microsoft Entra ID](../how-to/how-to-add-sso-azure-saml.md)
+- [SAML 2.0 with Microsoft Entra ID](../how-to/how-to-add-sso-azure-saml)
-- [Google Authentication](../how-to/how-to-add-sso-google.md) (deprecated)
+- [Google Authentication](../how-to/how-to-add-sso-google) (deprecated)

website/docs/reference/stickiness.md

@@ -14,17 +14,17 @@ If both the user id and the session id is unavailable, the calculation returns a
 
 Because the number assigned to a user won't change, Unleash also guarantees that the a user will keep seeing the same features even if certain other parameters change.
 
-For instance: When using the [gradual rollout activation strategy](../reference/activation-strategies.md#gradual-rollout), any user whose number is less than or equal to the rollout percentage will see the feature. This means that the same users will keep seeing the feature even as you increase the percentage of your user base that sees the feature.
+For instance: When using the [gradual rollout activation strategy](../reference/activation-strategies#gradual-rollout), any user whose number is less than or equal to the rollout percentage will see the feature. This means that the same users will keep seeing the feature even as you increase the percentage of your user base that sees the feature.
 
 ## Custom stickiness {#custom-stickiness}
 
 :::note Availability
 
-**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table).
+**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table).
 
 :::
 
-When using [the gradual rollout strategy](../reference/activation-strategies.md#gradual-rollout) or [feature flag variants](./feature-toggle-variants.md), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context.md) as long as you have enabled custom stickiness for these fields.
+When using [the gradual rollout strategy](../reference/activation-strategies#gradual-rollout) or [feature flag variants](./feature-toggle-variants), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context) as long as you have enabled custom stickiness for these fields.
 
 
 ### Enabling custom stickiness
@@ -43,7 +43,7 @@ To enable custom stickiness on a field, navigate to the Create Context screen in
 
 Each project in Unleash can have its own default stickiness context field. Whenever you add a gradual rollout strategy or variants to a feature in that project, Unleash will use the configured context field as the initial value. 
 
-Only context fields that have the [custom stickiness](unleash-context.md#custom-stickiness) option turned on can be used as default stickiness fields.
+Only context fields that have the [custom stickiness](unleash-context#custom-stickiness) option turned on can be used as default stickiness fields.
 
 If you don't specify a default custom stickiness, the project will use the "default" stickiness option, which works as described in the [calculation section](#calculation).
 

website/docs/reference/strategy-constraints.mdx

@@ -30,7 +30,7 @@ You can constrain both on [standard context fields](../reference/unleash-context
 Unleash SDKs expect all context values to be strings. If you use an operator that acts on non-string values, such as [numeric operators](#numeric-operators) or [date and time operators](#date-and-time-operators), the SDK will attempt to convert the string into the expected type. If the conversion fails, the constraint will evaluate to `false`.
 :::
 
-This page explains what strategy constraints are in Unleash and how they work. If you want to know *how you add* strategy constraints to an activation strategy, see [the corresponding how-to guide](../how-to/how-to-add-strategy-constraints.md "how to add strategy constraints").
+This page explains what strategy constraints are in Unleash and how they work. If you want to know *how you add* strategy constraints to an activation strategy, see [the corresponding how-to guide](../how-to/how-to-add-strategy-constraints).
 
 <VideoContent videoUrls={["https://www.youtube.com/embed/kqtqMFhLRBE"]}/>
 
@@ -38,7 +38,7 @@ This page explains what strategy constraints are in Unleash and how they work. I
 ## Constraining on custom context fields
 
 :::info Making custom context fields available
-To be able to constrain on a field, it must be listed under the Context Field menu. If a field isn't listed, you can add it yourself. See [the how-to guide for creating your own custom fields](../how-to/how-to-define-custom-context-fields.md) for more info.
+To be able to constrain on a field, it must be listed under the Context Field menu. If a field isn't listed, you can add it yourself. See [the how-to guide for creating your own custom fields](../how-to/how-to-define-custom-context-fields) for more info.
 :::
 
 Unleash only provides a limited set of context fields by default, and they may not fulfill all your needs.
@@ -75,7 +75,7 @@ To clarify, here's a few example strategy constraints and what they do:
 In this section, `<context-field>` is used as a placeholder for an arbitrary context field. With the exception of the `currentTime` field, you can use any context field in its place.
 :::
 
-Unleash supports a wide range of constraint operators. `IN` and `NOT_IN` are basic operators that are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](../reference/sdks/index.md#strategy-constraints).
+Unleash supports a wide range of constraint operators. `IN` and `NOT_IN` are basic operators that are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](../reference/sdks#strategy-constraints).
 
 ### Constraint negation / inversion {#constraint-negation}
 
@@ -174,7 +174,7 @@ Additionally, you can use negation to get _less than or equal to_ and _greater t
 This section gives a brief overview over to use the client SDKs to interact with strategy constraints. The exact steps will vary depending on which client you are using, so make sure to consult the documentation for your specific client SDK.
 :::
 
-Strategy constraints require [the Unleash Context](../reference/unleash-context) to work. All official [Unleash client SDKs](../reference/sdks/index.md) support the option to pass [dynamic context values](../reference/unleash-context#structure "Unleash Context, section: structure") to the `isEnabled` function (or the SDK's equivalent).
+Strategy constraints require [the Unleash Context](../reference/unleash-context) to work. All official [Unleash client SDKs](../reference/sdks) support the option to pass [dynamic context values](../reference/unleash-context#structure) to the `isEnabled` function (or the SDK's equivalent).
 
 If the strategy constraint uses a [**standard Unleash Context field**](../reference/unleash-context#structure), set the context field to the value you wish to give it.
 
@@ -188,7 +188,7 @@ This value can still be negated as explained in [the section on negating values]
 
 :::tip
 
-Explore the content in this subsection in more depth in [the topic guide on using Unleash with large constraints](/understanding-unleash/managing-constraints.mdx).
+Explore the content in this subsection in more depth in [the topic guide on using Unleash with large constraints](/understanding-unleash/managing-constraints).
 
 :::
 
@@ -209,12 +209,12 @@ If you use the new constraints with old SDKs, here's how it'll affect _some_ of
 - The Python client SDK will evaluate the flag to false, as it cannot evaluate the constraint successfully.
 - The .NET, Ruby, and PHP SDKs raise exceptions if the provided operator is not `IN` or `NOT_IN`.
 
-Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks/index.md#strategy-constraints).
+Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks#strategy-constraints).
 
 After Unleash 4.9, we updated the [Unleash client specification](https://github.com/Unleash/client-specification). Going forward, any constraint that a client does not recognize, **must be evaluated as `false`**
 
 ## [Deprecated]: Constrain on a specific environment {#constrain-on-a-specific-environment}
 
-Before Unleash 4.3, using strategy constraints was the recommended way to have different flag configurations per environment. Now that Unleash has environment support built in, we no longer recommend you use strategy constraints for this. Instead, see the [environments documentation](../reference/environments.md).
+Before Unleash 4.3, using strategy constraints was the recommended way to have different flag configurations per environment. Now that Unleash has environment support built in, we no longer recommend you use strategy constraints for this. Instead, see the [environments documentation](../reference/environments).
 
 [^1]: `userScore` is not a default Unleash field, but can be added as a [custom context field](../reference/unleash-context#custom-context-fields).

website/docs/reference/unleash-context.md

@@ -2,7 +2,7 @@
 title: Unleash Context
 ---
 
-The **Unleash Context** contains information relating to the current feature flag request. Unleash uses this context to evaluate [activation strategies](activation-strategies.md) and [strategy constraints](../reference/strategy-constraints.md) and to calculate [flag stickiness](../reference/stickiness.md). The Unleash Context is an important feature of all the [Unleash client SDKs](../reference/sdks/index.md).
+The **Unleash Context** contains information relating to the current feature flag request. Unleash uses this context to evaluate [activation strategies](activation-strategies) and [strategy constraints](../reference/strategy-constraints) and to calculate [flag stickiness](../reference/stickiness). The Unleash Context is an important feature of all the [Unleash client SDKs](../reference/sdks).
 
 ## Structure
 
@@ -12,7 +12,7 @@ You can group the Unleash Context fields into two separate groups based on how t
 
 **Dynamic** fields, however, can change with every request. You'll typically provide these when checking whether a flag is enabled in your client.
 
-_All fields are optional_, but some strategies depend on certain fields being present. For instance, [the UserIDs strategy](activation-strategies.md#userids) requires that the `userId` field is present on the Context.
+_All fields are optional_, but some strategies depend on certain fields being present. For instance, [the UserIDs strategy](activation-strategies#userids) requires that the `userId` field is present on the Context.
 
 The below table gives a brief overview over what the fields' intended usage is, their lifetime, and their type. Note that the exact type can vary between programming languages and implementations. Be sure to consult your specific client SDK for more information on its implementation of the Unleash Context.
 
@@ -29,7 +29,7 @@ The below table gives a brief overview over what the fields' intended usage is,
 
 ### The `properties` field
 
-The `properties` field is different from the others. You can use the `properties` field to provide arbitrary data to [custom strategies](../reference/custom-activation-strategies.md) or to [strategy constraints](../reference/strategy-constraints.md). The `properties` field is also where you add values for [custom context fields](#custom-context-fields).
+The `properties` field is different from the others. You can use the `properties` field to provide arbitrary data to [custom strategies](../reference/custom-activation-strategies) or to [strategy constraints](../reference/strategy-constraints). The `properties` field is also where you add values for [custom context fields](#custom-context-fields).
 
 
 #### A note on properties and constraints
@@ -48,7 +48,7 @@ For operators that work on non-string types, such as numeric and date time opera
 
 :::
 
-Custom context fields allow you to extend the Unleash Context with more data that is applicable to your situation. Each context field definition consists of a name and an optional description. Additionally, you can choose to define a set of [_legal values_](#legal-values "legal values for custom context fields"), and you can choose whether or not the context field can be used in [custom stickiness calculations](../reference/stickiness.md#custom-stickiness) for the [gradual rollout strategy](activation-strategies.md#customize-stickiness-beta) and for [feature flag variants](../reference/feature-toggle-variants.md).
+Custom context fields allow you to extend the Unleash Context with more data that is applicable to your situation. Each context field definition consists of a name and an optional description. Additionally, you can choose to define a set of [_legal values_](#legal-values "legal values for custom context fields"), and you can choose whether or not the context field can be used in [custom stickiness calculations](../reference/stickiness#custom-stickiness) for the [gradual rollout strategy](activation-strategies#customize-stickiness-beta) and for [feature flag variants](../reference/feature-toggle-variants).
 
 When interacting with custom context fields in code, they must be accessed via the Unleash Context's `properties` map, using the context field's name as the key.
 
@@ -63,7 +63,7 @@ You can update custom context fields after they have been created. You can chang
 By using the **legal values** option when creating a context field, you can create a set of valid options for a context field's values.
 If a context field has a defined set of legal values, the Unleash Admin UI will only allow users to enter one or more of the specified values. If a context field _doesn't_ have any defined legal values, the user can enter whatever they want.
 
-Using a custom context field called _region_ as an example: if you define the field's legal values as _Africa_, _Asia_, _Europe_, and _North America_, then you would only be allowed to use one or more of those four values when using the custom context field as a [strategy constraint](../reference/strategy-constraints.md).
+Using a custom context field called _region_ as an example: if you define the field's legal values as _Africa_, _Asia_, _Europe_, and _North America_, then you would only be allowed to use one or more of those four values when using the custom context field as a [strategy constraint](../reference/strategy-constraints).
 
 ![A strategy constraint form with a constraint set to "region". The "values" input is a dropdown menu containing the options "Africa", "Asia", "Europe", and "North America", as defined in the preceding paragraph.](/img/constraints_legal_values.png)
 
@@ -71,14 +71,14 @@ Using a custom context field called _region_ as an example: if you define the fi
 
 :::note SDK compatibility
 
-Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks/index.md#server-side-sdk-compatibility-table) for the full overview.
+Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks#server-side-sdk-compatibility-table) for the full overview.
 
 :::
 
-Any context field _can_ be used to [calculate custom stickiness](../reference/stickiness.md#custom-stickiness). However, you need to explicitly tell Unleash that you want a field to be used for custom stickiness for it to be possible. You can enable this functionality either when you create the context field or at any later point. For steps on how to do this, see [the _How to define custom context fields_ guide](../how-to/how-to-define-custom-context-fields).
+Any context field _can_ be used to [calculate custom stickiness](../reference/stickiness#custom-stickiness). However, you need to explicitly tell Unleash that you want a field to be used for custom stickiness for it to be possible. You can enable this functionality either when you create the context field or at any later point. For steps on how to do this, see [the _How to define custom context fields_ guide](../how-to/how-to-define-custom-context-fields).
 
 
 
-[^1]: If you're on Unleash 4.3 or higher, you'll probably want to use [the environments feature](../reference/environments.md) instead of relying on the `environment` context field when working with environments.
+[^1]: If you're on Unleash 4.3 or higher, you'll probably want to use [the environments feature](../reference/environments) instead of relying on the `environment` context field when working with environments.
 
-[^2]: Check the [*strategy constraints: advanced support* row of the compatibility table](../reference/sdks/index.md#strategy-constraints-advanced-support) for an overview of which SDKs provide the `currentTime` property.
+[^2]: Check the [*strategy constraints: advanced support* row of the compatibility table](../reference/sdks#strategy-constraints-advanced-support) for an overview of which SDKs provide the `currentTime` property.

website/docs/reference/whats-new-v4.md

@@ -6,7 +6,7 @@ Version 4 of Unleash brings a lot of improvements to Unleash. In this document w
 
 ### Upgrade with ease {#upgrade-with-ease}
 
-Unleash can either be hosted by us or self-hosted. If you have a managed Unleash Enterprise instance you are automatically upgraded to version 4. If you manage Unleash yourself (either Open-Source or Enterprise Self-hosted) we recommend reading the [migration guide](../using-unleash/deploy/upgrading-unleash.md).
+Unleash can either be hosted by us or self-hosted. If you have a managed Unleash Enterprise instance you are automatically upgraded to version 4. If you manage Unleash yourself (either Open-Source or Enterprise Self-hosted) we recommend reading the [migration guide](../using-unleash/deploy/upgrading-unleash).
 
 **PS! The first time you access Unleash v4 from a self-hosted instance you will need to login with the default admin user:**
 
@@ -17,16 +17,16 @@ _(We recommend changing the password of the default user from the admin section.
 
 ### Role-Based Access Control {#role-based-access-control}
 
-With Role-Based Access Control you can now assign groups to users in order to control access. You can control access to root resources in addition to controlling access to [projects](projects.md). _Please be aware that all existing users will become "Owner" of all existing projects as part of the migration from v3 to v4._
+With Role-Based Access Control you can now assign groups to users in order to control access. You can control access to root resources in addition to controlling access to [projects](./projects). _Please be aware that all existing users will become "Owner" of all existing projects as part of the migration from v3 to v4._
 
-[Read more](rbac.md)
+[Read more](./rbac)
 
 ### New Integrations {#new-integrations}
 
 Integrations make it easy to integrate Unleash with other systems. In version 4 we bring two new integrations to Unleash:
 
-- [Microsoft Teams](../reference/integrations/teams.md)
+- [Microsoft Teams](../reference/integrations/teams)
-- [Datadog](../reference/integrations/datadog.md)
+- [Datadog](../reference/integrations/datadog)
 
 ### Improved UX {#improved-ux}
 
@@ -40,15 +40,15 @@ In version 4 we added support for [OpenID Connect](https://openid.net/connect/)
 
 In version 4 we improved the User Management and made it available for Unleash Open-Source and Unleash Enterprise. Starting in v4 all users accessing Unleash needs to exist in Unleash in order to gain access (because they need to have the proper permission from RBAC.)
 
-[Read more](../how-to/how-to-add-users-to-unleash.md)
+[Read more](../how-to/how-to-add-users-to-unleash)
 
 ### API access {#api-access}
 
 In version 4 we improved the API Access and made it available for Unleash Open-Source and Unleash Enterprise. Starting from Unleash v4 we require all SDKs to use an access token in order to connect to Unleash.
 
-[Read more](../how-to/how-to-use-the-admin-api.md)
+[Read more](../how-to/how-to-use-the-admin-api)
 
 ### Custom stickiness {#custom-stickiness}
 
 In Unleash Enterprise v4 you can configure stickiness when you are
-doing a gradual rollout with the "gradual rollout" strategy (previously known as "flexible rollout") or together with feature flag variants. This means that you can now have consistent behavior based on any field available on the [Unleash context](unleash-context.md).
+doing a gradual rollout with the "gradual rollout" strategy (previously known as "flexible rollout") or together with feature flag variants. This means that you can now have consistent behavior based on any field available on the [Unleash context](./unleash-context).

website/docs/topics/concepts/what-is-a-feature-flag.mdx

@@ -148,7 +148,7 @@ Contrary to the short-lived nature of most feature flags, kill switches are inhe
 
 Operational flags manage a system’s technical aspects that do not directly influence user-visible features but are crucial for the application’s underlying stability and performance. For example, during a library version upgrade, operational flags can toggle between the old and new implementations to ensure the update does not adversely affect the system. By enabling real-time switching between different operational states or configurations, these flags allow for thorough validation of changes in a live environment without disrupting the user experience.
 
-Operational flags should be short-lived, existing only long enough to confirm that a change, such as a library update, is stable and does not introduce regressions. Once the new state is validated, the flag should be promptly retired to avoid accumulating technical debt. Avoid using operational flags as a solution for long-term configuration management; see our [Best practices for building and scaling feature flags](../feature-flags/feature-flag-best-practices.md) guide to learn more.
+Operational flags should be short-lived, existing only long enough to confirm that a change, such as a library update, is stable and does not introduce regressions. Once the new state is validated, the flag should be promptly retired to avoid accumulating technical debt. Avoid using operational flags as a solution for long-term configuration management; see our [Best practices for building and scaling feature flags](./topics/feature-flags/feature-flag-best-practices) guide to learn more.
 
 
 ### Permission flags
@@ -213,6 +213,6 @@ Unleash is on a mission to make developers’ lives easier. Individual developer
 
 If you want to learn more about how to implement feature flags at scale, check out the following resources:
 - [Feature Flag Tutorials](/feature-flag-tutorials)
-- [Best practices for using feature flags at scale](../feature-flags/best-practices-using-feature-flags-at-scale.md)
+- [Best practices for using feature flags at scale](./topics/feature-flags/best-practices-using-feature-flags-at-scale)
-- [Best practices for building and scaling feature flags](../feature-flags/feature-flag-best-practices.md)
+- [Best practices for building and scaling feature flags](./topics/feature-flags/feature-flag-best-practices)
 - [Try Unleash for Free](https://www.getunleash.io/pricing)

website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.mdx

@@ -6,7 +6,7 @@ import Figure from '@site/src/components/Figure/Figure.tsx'
 
 “A feature flag is just an if statement,” you say. This is true in a way, but when your organization has thousands of developers, each managing dozens or hundreds of flags with complex targeting rules and audit trails across dozens of microservices-based applications, those if statements can quickly become complex. This is especially true if you don’t set up your system correctly in the first place.
 
-This guide to using feature flag systems at scale is based on lessons learned working with some of the largest feature flag deployments in the world through the [Unleash Open-Source](https://github.com/Unleash/unleash) and [Enterprise Feature Management platform](https://www.getunleash.io/enterprise-feature-management-platform). However, the principles outlined do not apply only to Unleash. They apply to any large-scale feature flag system, including one you build yourself or another commercial solution. For tips on how to stand up and run a feature flag system, see our [principles for building and scaling feature flags](feature-flag-best-practices.md).
+This guide to using feature flag systems at scale is based on lessons learned working with some of the largest feature flag deployments in the world through the [Unleash Open-Source](https://github.com/Unleash/unleash) and [Enterprise Feature Management platform](https://www.getunleash.io/enterprise-feature-management-platform). However, the principles outlined do not apply only to Unleash. They apply to any large-scale feature flag system, including one you build yourself or another commercial solution. For tips on how to stand up and run a feature flag system, see our [principles for building and scaling feature flags](./feature-flag-best-practices).
 
 This guide is organized into three sections that align with the stages of a large-scale feature flag rollout:
 
@@ -68,7 +68,7 @@ Modern applications are composed of multiple services with many complex dependen
 
 Just because a user might need to interact with a flag does not mean you should display it by default when it is outside your main organizational parameters. However, all flags should be easily searchable. When a user finds one, they should be able to inspect its configuration and ownership so that they might request additional permissions or [submit change requests for approval](#6-implement-flag-approval-workflows-early).
 
-This is why feature flag systems should be [open by default](feature-flag-best-practices.md#9-choose-open-by-default-democratize-feature-flag-access). There are valid use cases for excluding flags from global search. For example, a public company in the middle of an acquisition where exposing flags related to the website or app changes might breach regulatory guidelines. Your feature flag system should accommodate these private projects; however, they should be the exception, not the rule.
+This is why feature flag systems should be [open by default](./feature-flag-best-practices#9-choose-open-by-default). There are valid use cases for excluding flags from global search. For example, a public company in the middle of an acquisition where exposing flags related to the website or app changes might breach regulatory guidelines. Your feature flag system should accommodate these private projects; however, they should be the exception, not the rule.
 
 ### 3. Design for flag permissions to change over time.
 
@@ -192,7 +192,7 @@ Here are a few examples of functionality managed by feature flags and where you
 When building new (often complex) features for users, systems require changes across multiple parts – modules within an application or services in a microservices architecture. While it's tempting to use a single feature flag to control all these changes and evaluate it locally in each module, we recommend against it for a few reasons:
 
 -   Unpredictable Timing: User requests flow through the system and touch different parts as they progress. Between each invocation, time passes. Even with perfectly synchronized feature flags, requests will hit different system parts at slightly different times. This means the flag state could change between evaluations, leading to inconsistent behavior for the user.
--   Laws of distributed computing: Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience transient errors at any time. Feature flag systems generally [prefer availability over consistency](feature-flag-best-practices.md#6-design-for-failure-favor-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users.
+-   Laws of distributed computing: Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience transient errors at any time. Feature flag systems generally [prefer availability over consistency](./feature-flag-best-practices#6-prioritize-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users.
 -   Violates Single Responsibility: Using the same flag in multiple locations spreads feature control logic throughout your codebase, violating the single-responsibility principle.
 
 We find that companies are usually more successful when using feature flags when they can protect new complex features with a single flag evaluated only once per user request. This approach ensures consistent behavior and simplifies long-term code maintainability.
@@ -245,7 +245,7 @@ To keep complexity down, we generally advise not to have complex targeting rules
 
 Both feature flags and configuration settings control an application’s behavior. However, it's crucial to distinguish between feature flagging systems and configuration management systems and use each for its intended purpose. Otherwise, you risk management nightmares and security vulnerabilities
 
-Feature flags are intended for dynamic and temporary use, giving you [runtime control](feature-flag-best-practices.md#1-enable-run-time-control-control-flags-dynamically-not-using-config-files) to enable or disable functionality in a live environment. This flexibility supports [short-lived experiments](feature-flag-best-practices.md#7-make-feature-flags-short-lived-do-not-confuse-flags-with-application-configuration), such as A/B testing or gradual rollouts, instead of relying on configuration settings that require an application redeploy to take effect. Despite the ease of turning off and on features or functionality with feature flags, they should not be repurposed for managing configuration.
+Feature flags are intended for dynamic and temporary use, giving you [runtime control](./feature-flag-best-practices#1-enable-runtime-control) to enable or disable functionality in a live environment. This flexibility supports [short-lived experiments](./feature-flag-best-practices#7-make-flags-short-lived), such as A/B testing or gradual rollouts, instead of relying on configuration settings that require an application redeploy to take effect. Despite the ease of turning off and on features or functionality with feature flags, they should not be repurposed for managing configuration.
 
 A dedicated config management system should manage long-term configuration settings. These systems are designed to handle sensitive information such as API keys and access credentials securely, unlike feature flag systems, which typically do not encrypt flag states. Misusing feature flags for configuration can lead to security risks and management complexities.
 
@@ -341,4 +341,4 @@ Feature flags are a powerful tool for delivering software efficiently while main
 
 Remember, the key to successful feature flag management at scale lies in clear processes, regular maintenance, and a commitment to best practices. With these in place, you can leverage feature flags to drive innovation and improve your software development lifecycle.
 
-This guide was all about using feature flags at scale. For similar tips on building and scaling the feature flag system itself, see our [feature flag best practices guide](feature-flag-best-practices.md).
+This guide was all about using feature flags at scale. For similar tips on building and scaling the feature flag system itself, see our [feature flag best practices guide](./feature-flag-best-practices).

website/docs/understanding-unleash/managing-constraints.mdx

@@ -8,7 +8,7 @@ In this explanatory guide, we will discuss how best to deal with large and compl
 
 :::
 
-Unleash offers several ways to limit feature exposure to a specified audience, such as the [User IDs strategy](../reference/activation-strategies.md#userids), [strategy constraints](../reference/strategy-constraints.md), and [segments](../reference/segments.mdx). Each of these options makes it easy to add some sort of user identifier to the list of users who should get access to a feature.
+Unleash offers several ways to limit feature exposure to a specified audience, such as the [User IDs strategy](../reference/activation-strategies#userids), [strategy constraints](../reference/strategy-constraints), and [segments](../reference/segments). Each of these options makes it easy to add some sort of user identifier to the list of users who should get access to a feature.
 
 Because of their availability and ease of use with smaller lists, it can be tempting to just keep adding identifiers to those lists. However, once you start approaching a hundred elements, we recommend that you find another way to manage these IDs. In fact, it's probably better to stop well before you get that far.
 
@@ -18,7 +18,7 @@ How large is too large? How complex is too complex? It depends. However, smaller
 
 ## The cost of data
 
-First, let's talk a bit about Unleash's architecture: **Your Unleash instance** is where you define all your features, their strategies, and constraints (and a lot more). However, the Unleash instance itself does not do any of the feature evaluation[^1]. That responsibility is delegated to the Unleash SDKs (or [Edge](/generated/unleash-edge.md) / the [Unleash proxy](/generated/unleash-proxy.md)).
+First, let's talk a bit about Unleash's architecture: **Your Unleash instance** is where you define all your features, their strategies, and constraints (and a lot more). However, the Unleash instance itself does not do any of the feature evaluation[^1]. That responsibility is delegated to the Unleash SDKs (or [Edge](../reference/unleash-edge) / the [Unleash proxy](../reference/unleash-proxy)).
 
 For the SDKs (Edge/proxy included) to evaluate a feature, it needs to know everything about that feature in a specific environment. This includes all strategies and their constraints. This means that the Unleash instance must transmit all information about this feature (and all other features) as a response to an API call.
 
@@ -32,7 +32,7 @@ In other words: it's not good.
 
 Okay, so putting all these IDs in Unleash isn't good. But how **do** you manage features for these 124 special cases you have?
 
-The first thing to think about would be whether you can group these special cases in some way. Maybe you already have an [Unleash context](../reference/unleash-context.md) field that covers the same amount of users. In that case, you can constrain that instead. If you don't have a context field that matches these users, then you might need to create one.
+The first thing to think about would be whether you can group these special cases in some way. Maybe you already have an [Unleash context](../reference/unleash-context) field that covers the same amount of users. In that case, you can constrain that instead. If you don't have a context field that matches these users, then you might need to create one.
 
 Further, if you have a lot of special cases and require complex constraint logic to model it correctly, this probably reflects some logic that is specific to your domain. It's also likely that this same logic is used elsewhere in your system external to Unleash. Modeling this logic in multiple places can quickly lead to breakage, and we recommend having a single source of truth for cases like this.
 
@@ -52,4 +52,4 @@ An option is to set up an external data store that handles this information spec
 
 The Unleash SDKs are designed to be fast and unobtrusive. This means that resolving a large set of constraints at runtime results in one of two problems: either the SDK needs to resolve very large amounts of data, which can put pressure on your network or it needs to make a potentially slow network call to resolve the segment. Both of these are undesirable for the health of your application.
 
-[^1]: Well, except for in the case of the [front-end API](../reference/front-end-api.md). But even then, the size of the data to transmit matters.
+[^1]: Well, except for in the case of the [front-end API](../reference/front-end-api). But even then, the size of the data to transmit matters.

website/docs/understanding-unleash/the-anatomy-of-unleash.mdx

@@ -4,7 +4,7 @@ title: The Anatomy of Unleash
 
 import Figure from "@site/src/components/Figure/Figure.tsx";
 
-This guide's purpose is to give you a conceptual overview of how Unleash works. It covers the various components that exist within our system and how they interact with each other and with external applications. The diagrams help you understand the fundamental building blocks, such as [projects](../reference/projects.md), [environments](../reference/environments.md), [variants](../reference/feature-toggle-variants.md) and of course, [feature flags](../reference/feature-toggles.mdx).
+This guide's purpose is to give you a conceptual overview of how Unleash works. It covers the various components that exist within our system and how they interact with each other and with external applications. The diagrams help you understand the fundamental building blocks, such as [projects](../reference/projects), [environments](../reference/environments), [variants](../reference/strategy-variants) and of course, [feature flags](../reference/feature-toggles).
 
 The end of this guide presents a [short use case, explaining how you might configure Unleash](#use-case) to start working with feature flags.
 
@@ -12,17 +12,17 @@ The end of this guide presents a [short use case, explaining how you might confi
 
 Some things in Unleash are configured and defined on the root level. These options apply across the entire Unleash instance. The most important root configuration options for day-to-day operations are:
 
--   [API access tokens](../reference/api-tokens-and-client-keys.mdx)
+-   [API access tokens](../reference/api-tokens-and-client-keys)
--   [Projects](../reference/projects.md)
+-   [Projects](../reference/projects)
--   [Segments](../reference/segments.mdx)
+-   [Segments](../reference/segments)
--   [Strategy types](../reference/activation-strategies.md) (including [custom activation strategy types](../reference/custom-activation-strategies.md))
+-   [Strategy types](../reference/activation-strategies) (including [custom activation strategy types](../reference/custom-activation-strategies))
--   [Tag types](../reference/tags.md)
+-   [Tag types](../reference/tags)
--   [Unleash context](../reference/unleash-context.md) fields (including [custom context fields](../reference/unleash-context.md#custom-context-fields))
+-   [Unleash context](../reference/unleash-context) fields (including [custom context fields](../reference/unleash-context#custom-context-fields))
--   Users, [user groups](../reference/rbac.md#user-groups) and [roles](../reference/rbac.md)
+-   Users, [user groups](../reference/rbac#user-groups) and [roles](../reference/rbac)
 
 ## Projects
 
-[**Projects**](../reference/projects.md) contain [feature flags](../reference/feature-toggles.mdx) and their configurations, and a set of active [environments](../reference/environments.md).
+[**Projects**](../reference/projects) contain [feature flags](../reference/feature-toggles) and their configurations, and a set of active [environments](../reference/environments).
 
 All Unleash instances must have at least one project at any given time. New instances get a project called “Default”.
 
@@ -41,7 +41,7 @@ Pro and Enterprise customers can create, rename, and delete projects as they wis
     caption="Feature flags can be activated or deactivated independently in different environments. For instance, a feature flag can be active in the development environment, and deactivated in the production environment. Even if their configuration is otherwise identical, deactivated feature flags will never be considered enabled."
 />
 
-[**Environments**](../reference/environments.md) in Unleash let you change how a feature flag works in your application’s different environments. For instance, while you are developing a feature, it’s likely that you’ll want it to be available in your development environment, but not in your production environment: environments let you do that. You might also want to enable a feature for only some users in your development environment, but no users in your production environment: environments let you do that.
+[**Environments**](../reference/environments) in Unleash let you change how a feature flag works in your application’s different environments. For instance, while you are developing a feature, it’s likely that you’ll want it to be available in your development environment, but not in your production environment: environments let you do that. You might also want to enable a feature for only some users in your development environment, but no users in your production environment: environments let you do that.
 
 Environments exist on two different levels within Unleash. The set of **all available environments is defined on the root level**. Additionally, **each project** can choose which of these root environments should be **available on the project level**. The set of environments available to any given project is **always a subset** of the set of all available environments at the root level.
 
@@ -49,7 +49,7 @@ Each project must always have **at least one** active environment.
 
 Enterprise users can create and remove environments. Open-source and Pro customers get access to two environments: **development** and **production.**
 
-Environments are adjacent to [feature flags](../reference/feature-toggles.mdx) in Unleash: neither one contains the other, but they come together to let you define activation strategies.
+Environments are adjacent to [feature flags](../reference/feature-toggles) in Unleash: neither one contains the other, but they come together to let you define activation strategies.
 
 <Figure
     img="/img/anatomy-of-unleash-new-feature-rollout.png"
@@ -64,9 +64,9 @@ When connecting an SDK to Unleash, it's the **API key that decides which environ
 
 ## Features (feature flags)
 
-[**Feature flags**](../reference/feature-toggles.mdx) are at the heart of Unleash’s functionality. Feature flags belong to projects and live next to project environments. In and of itself, a feature flag doesn’t do anything. You must assign [**activation strategies**](../reference/activation-strategies.md) to it for it to start taking effect.
+[**Feature flags**](../reference/feature-toggles) are at the heart of Unleash’s functionality. Feature flags belong to projects and live next to project environments. In and of itself, a feature flag doesn’t do anything. You must assign [**activation strategies**](../reference/activation-strategies) to it for it to start taking effect.
 
-When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggles#feature-flag-types), a [project](../reference/projects.md) it belongs to, and an optional description. Everything except for the name can be changed later.
+When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggles#feature-flag-types), a [project](../reference/projects) it belongs to, and an optional description. Everything except for the name can be changed later.
 
 <Figure
     img="/img/anatomy-of-unleash-features.png"
@@ -82,16 +82,16 @@ When creating a feature flag, you must assign a unique (across your Unleash inst
     alt="A hierarchy displaying an environment containing a feature flag configuration with an activation strategy."
 />
 
-[**Activation strategies**](../reference/activation-strategies.md) (or just **strategies** for short) are the part of feature flags that tell Unleash **who should get a feature**. An activation strategy is assigned to **one **feature flag in **one **environment.
+[**Activation strategies**](../reference/activation-strategies) (or just **strategies** for short) are the part of feature flags that tell Unleash **who should get a feature**. An activation strategy is assigned to **one **feature flag in **one **environment.
 
-When you check a [feature flag](../reference/feature-toggles.mdx) in an application, the following decides the result:
+When you check a [feature flag](../reference/feature-toggles) in an application, the following decides the result:
 
 1. Is the flag active in the current environment? If not, it will be disabled.
 2. If the flag **is** active in the current environment, the flag’s strategies decide the result. As long as **at least one** of a flag’s strategies resolves to `true` for the current context (user or application), then the flag will be considered enabled. In other words, if you have a hundred strategies and ninety-nine of them resolve to false, but one of them resolves to true, then the flag is enabled.
 
-Activation strategies tie feature flags and [environments](../reference/environments.md) together. When you assign an activation strategy to a feature flag, you do so in one environment at a time. You can assign the same strategy to the same flag in different environments, but they will be different instances of the same strategy and do not stay in sync. Unleash also lets you copy strategies from one environment to another.
+Activation strategies tie feature flags and [environments](../reference/environments) together. When you assign an activation strategy to a feature flag, you do so in one environment at a time. You can assign the same strategy to the same flag in different environments, but they will be different instances of the same strategy and do not stay in sync. Unleash also lets you copy strategies from one environment to another.
 
-Unleash comes with a number of [built-in strategies](../reference/activation-strategies.md). You can also create your own [custom activation strategies](../reference/custom-activation-strategies.md). All strategies can be further augmented by [**strategy constraints**](../reference/strategy-constraints.md).
+Unleash comes with a number of [built-in strategies](../reference/activation-strategies). You can also create your own [custom activation strategies](../reference/custom-activation-strategies). All strategies can be further augmented by [**strategy constraints**](../reference/strategy-constraints).
 
 <Figure
     img="/img/anatomy-of-unleash-environments-strategies.png"
@@ -105,7 +105,7 @@ Unleash comes with a number of [built-in strategies](../reference/activation-str
 
 ## Strategy constraints
 
-[**Strategy constraints**](../reference/strategy-constraints.md) (or just **constraints**) help you fine-tune your strategies. They are an extra layer of prerequisites that help you narrow the audience of a strategy down. Strategy constraints are applied to [**activation strategies**](../reference/activation-strategies.md).
+[**Strategy constraints**](../reference/strategy-constraints) (or just **constraints**) help you fine-tune your strategies. They are an extra layer of prerequisites that help you narrow the audience of a strategy down. Strategy constraints are applied to [**activation strategies**](../reference/activation-strategies).
 
 For example, if you wanted to roll a feature out to 50% of users with **a specific email domain **(such as “@mycompany.com”), then strategy constraints would let you target only users with that email domain.
 
@@ -126,9 +126,9 @@ Note that even if all the constraints are met, the strategy itself might not res
 
 :::
 
-You can define constraints on whatever properties you want in your [Unleash context](../reference/unleash-context.md).
+You can define constraints on whatever properties you want in your [Unleash context](../reference/unleash-context).
 
-Constraints are applied to individual strategies and do not stay in sync with each other. When you need to have the same constraints applied to multiple strategies and need those constraints to stay in sync, use [**segments**](../reference/segments.mdx).
+Constraints are applied to individual strategies and do not stay in sync with each other. When you need to have the same constraints applied to multiple strategies and need those constraints to stay in sync, use [**segments**](../reference/segments).
 
 <Figure
     img="/img/anatomy-of-unleash-constraint.png"
@@ -138,7 +138,7 @@ Constraints are applied to individual strategies and do not stay in sync with ea
 
 ## Segments
 
-[**Segments**](../reference/segments.mdx) add extra functionality on top of [**strategy constraints**](../reference/strategy-constraints.md). A segment is a reusable collection of strategy constraints with a name and an optional description. When you apply a segment to a [strategy](../reference/activation-strategies.md), the strategy will be evaluated as if all of the segment's constraints were applied to it.
+[**Segments**](../reference/segments) add extra functionality on top of [**strategy constraints**](../reference/strategy-constraints). A segment is a reusable collection of strategy constraints with a name and an optional description. When you apply a segment to a [strategy](../reference/activation-strategies), the strategy will be evaluated as if all of the segment's constraints were applied to it.
 
 Segments let you apply a set of constraints to multiple strategies **and** keep the constraints in sync between those strategies. Whenever you apply a segment to a strategy, you essentially create a **reference** to that segment. This means that whenever you change the segment by adding, removing, or changing constraints, this change propagates to all the strategies that reference this segment.
 
@@ -153,7 +153,7 @@ Segments are only available to Pro and Enterprise users.
 
 ## Variants and feature flag payloads
 
-By default, a [feature flag](../reference/feature-toggles.mdx) in Unleash only tells you whether a feature is enabled or disabled, but you can also add more information to your flags by using [**feature flag variants**](../reference/feature-toggle-variants.md). Variants also allow you to run [A/B testing experiments](../feature-flag-tutorials/use-cases/a-b-testing.md).
+By default, a [feature flag](../reference/feature-toggles) in Unleash only tells you whether a feature is enabled or disabled, but you can also add more information to your flags by using [**feature flag variants**](../reference/feature-toggle-variants). Variants also allow you to run [A/B testing experiments](../feature-flag-tutorials/use-cases/a-b-testing).
 
 Feature flags are designed to let you decide which users get access to a feature. Variants are designed to let you decide **which version** of the feature a user gets access to. For instance, if user A is part of your beta testing program and gets access to a new beta feature, then you can use variants to decide whether they should get the red version or the green version of the feature.
 
@@ -165,7 +165,7 @@ A feature flag can have as many variants as you want.
 
 ### Variants and environments
 
-Prior to 4.21, variants were independent of [environments](../reference/environments.md). In other words: if you're on 4.19 or lower, you’ll always have the exact same variants with the exact same weightings and the exact same payloads in all environments.
+Prior to 4.21, variants were independent of [environments](../reference/environments). In other words: if you're on 4.19 or lower, you’ll always have the exact same variants with the exact same weightings and the exact same payloads in all environments.
 
 <Figure
     img="/img/anatomy-of-unleash-variants.png"
@@ -197,9 +197,9 @@ Because you’d like to see the new color scheme while you’re developing it, y
 
 ### In your application
 
-You configure an [Unleash SDK for your server](../reference/sdks/index.md) to communicate with Unleash. When rendering the page, you check the state of the new-color-scheme feature and render a different stylesheet based on the results.
+You configure an [Unleash SDK for your server](../reference/sdks) to communicate with Unleash. When rendering the page, you check the state of the new-color-scheme feature and render a different stylesheet based on the results.
 
-In pseudocode (loosely based on the [Node.js SDK](/docs/generated/sdks/server-side/node.md)), that might look like this:
+In pseudocode (loosely based on the [Node.js SDK](../reference/sdks/node)), that might look like this:
 
 ```js
 if (unleash.isEnabled(“new-color-scheme”)) {

website/docs/understanding-unleash/unleash-overview.md

@@ -11,7 +11,7 @@ If you want more details you can read about [our unique architecture](https://ww
 Before you can connect your application to Unleash you need a Unleash server. You have a few options available:
 
 1. **Unleash Open-Source**
-   - [Docker](../using-unleash/deploy/getting-started.md)
+   - [Docker](../using-unleash/deploy/getting-started)
    - [Helm Chart](https://github.com/unleash/helm-charts/)
    - [GitLab](https://docs.gitlab.com/ee/operations/feature_flags.html#choose-a-client-library)
 2. **Unleash Enterprise**
@@ -23,8 +23,8 @@ Before you can connect your application to Unleash you need a Unleash server. Yo
 ![A visual overview of an Unleash system as described in the following paragraph.](/img/unleash-architecture-edge.png 'System Overview')
 
 - [**Unleash API**](/reference/api/unleash) - The Unleash instance. This is where you create feature flags, configure activation strategies, and parameters, etc. The service that contains all feature flags and their configurations. Configurations declare which activation strategies to use and which parameters they should get.
-- **Unleash Admin UI** - The bundled web interface for interacting with the Unleash instance. Manage flags, define strategies, look at metrics, and much more. Use the UI to [create feature flags](how-to/how-to-create-feature-toggles.md), [manage project access roles](../how-to/how-to-create-and-assign-custom-project-roles.md), [create API tokens](how-to/how-to-create-api-tokens.mdx), and more.
+- **Unleash Admin UI** - The bundled web interface for interacting with the Unleash instance. Manage flags, define strategies, look at metrics, and much more. Use the UI to [create feature flags](how-to/how-to-create-feature-toggles), [manage project access roles](../how-to/how-to-create-and-assign-custom-project-roles), [create API tokens](how-to/how-to-create-api-tokens), and more.
-- [**Unleash SDKs**](../reference/sdks/index.md) - Unleash SDKs integrate into your applications and get feature configurations from the Unleash API. Use them to check whether features are enabled or disabled and to send metrics to the Unleash API. [See all our SDKs](../reference/sdks/index.md)
+- [**Unleash SDKs**](../reference/sdks) - Unleash SDKs integrate into your applications and get feature configurations from the Unleash API. Use them to check whether features are enabled or disabled and to send metrics to the Unleash API. [See all our SDKs](../reference/sdks)
-- [**Unleash Edge**](../generated/unleash-edge.md) - The Unleash Edge sits between front-end and native applications on one side and the Unleash API on the other. It can also sit between server-side SDKs and the Unleash API as well. You can scale it independently of the Unleash API to handle large request rates without causing issues for the Unleash API. Edge has all endpoints for the client API, frontend API, and proxy API. 
+- [**Unleash Edge**](../reference/unleash-edge) - The Unleash Edge sits between front-end and native applications on one side and the Unleash API on the other. It can also sit between server-side SDKs and the Unleash API as well. You can scale it independently of the Unleash API to handle large request rates without causing issues for the Unleash API. Edge has all endpoints for the client API, frontend API, and proxy API. 
 
-To be super fast (_we're talking nano-seconds_), the [client SDK](../reference/sdks/index.md) caches all feature flags and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a flag is on or off because it is just a simple function operating on local state, without the need to poll data from the database.
+To be super fast (_we're talking nano-seconds_), the [client SDK](../reference/sdks) caches all feature flags and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a flag is on or off because it is just a simple function operating on local state, without the need to poll data from the database.

website/docs/unleash-academy/academy.mdx

@@ -41,7 +41,7 @@ Example titles are provided for additional guidance:
   * Manager, Executive
 
 :::note
-All roles working with Unleash start with the [**Foundational**](foundational.md) training. Then, role dependent courses are offered thereafter.
+All roles working with Unleash start with the [**Foundational**](./foundational) training. Then, role dependent courses are offered thereafter.
 :::
 
 **2. Now check the course directory or the graphic below to find out which courses apply to your persona!**
@@ -90,6 +90,6 @@ See also the following visualization of the learning paths
 
 ### Directory by Course
 
-- [**Foundational**](foundational.md) - For all roles working with Unleash - Developers, Product owners, Leaders.
+- [**Foundational**](./foundational) - For all roles working with Unleash - Developers, Product owners, Leaders.
-- [**Advanced for Developers**](advanced-for-devs.md) - For Developers only, after Foundational content has been reviewed
+- [**Advanced for Developers**](./advanced-for-devs) - For Developers only, after Foundational content has been reviewed
-- [**Managing Unleash for DevOps/Admins**](managing-unleash-for-devops.md) - For DevOps, Platform leads and Admins only after Foundational content has been reviewed
+- [**Managing Unleash for DevOps/Admins**](./managing-unleash-for-devops) - For DevOps, Platform leads and Admins only after Foundational content has been reviewed

website/docs/using-unleash/deploy/email-service.md

@@ -19,7 +19,7 @@ was not sent to the user because email configuration is lacking
 
 ## Configuring {#configuring}
 
-Depending on your deploy case there are different ways of configuring this service. Full documentation of all configuration possibilities is available [here](./configuring-unleash.md)
+Depending on your deploy case there are different ways of configuring this service. Full documentation of all configuration possibilities is available [here](./configuring-unleash).
 
 ### Docker {#docker}
 

website/docs/using-unleash/deploy/upgrading-unleash.mdx

@@ -154,7 +154,7 @@ Read more in the [API token documentation](../../how-to/how-to-create-api-tokens
 
 ### 2. Configuring Unleash {#2-configuring-unleash}
 
-We have done a lot of changes to the options you can pass in to Unleash. If you are manually configuring Unleash you should have a look on the updated [configuring Unleash documentation](./configuring-unleash.md)
+We have done a lot of changes to the options you can pass in to Unleash. If you are manually configuring Unleash you should have a look on the updated [configuring Unleash documentation](./configuring-unleash).
 
 ### 3. Role-based Access Control (RBAC) {#3-role-based-access-control-rbac}