Fix broken links

api-reference/v1/recipes.mdx

@@ -35,7 +35,7 @@ Use a recipe when:
 You will need:
 
 - Python 3.9+ installed
-- A [Personal Access Token (PAT)](/personal-settings/create-personal-tokens#personal-access-tokens)
+- A [Personal Access Token (PAT)](/personal-settings/create-personal-tokens)
 - Your Lightdash instance URL
 - The project UUID you want to modify
 

explore/create-custom-fields.mdx

@@ -130,7 +130,7 @@ Custom SQL dimensions let you pull in new data directly from your database, whic
 <Info>
 
 **Security note:**  
-Custom SQL dimensions can query any data from your warehouse, so they should only be created by trusted users (admins and developers). For most cases, it's safer and more reusable to define dimensions in your dbt files. If you want to make a custom SQL dimension reusable, use the [dbt write-back](/integrations/dbt/write-back#dbt-write-back) feature to move it into your dbt project.
+Custom SQL dimensions can query any data from your warehouse, so they should only be created by trusted users (admins and developers). For most cases, it's safer and more reusable to define dimensions in your dbt files. If you want to make a custom SQL dimension reusable, use the [dbt write-back](/integrations/dbt/write-back#write-back-dimensions-from-custom-dimensions) feature to move it into your dbt project.
 
 </Info>
 

explore/sql-runner.mdx

@@ -41,7 +41,7 @@ You can access your **Query history** from your session by clicking on the `SQL
 
 Once you've run your query, you can either:
 
-1. [**Build and save a Chart**](#building-charts-in-the-sql-runner)
+1. [**Build and save a Chart**](#saved-charts-in-the-sql-runner)
 2. [**Create a Virtual View so your query becomes a reusable table in Lightdash**](/semantic-layer/virtual-views)
 3. [**Write-back to dbt so your query is saved as a governed model.**](/integrations/dbt/write-back)
 4. Click the link icon in the top-right to share your query draft with a coworker (or save it yourself to return to later).

get-started/quickstart/connect-project.mdx

@@ -43,6 +43,8 @@ We always recommend giving read-only permissions to Lightdash, that way you ensu
   Combine this with **Connect via Lightdash CLI (SSO)** on Snowflake or **Sign in with Google** on BigQuery (see below) to create a project without ever pasting a credential — the same feature flag also enables smart defaults (recommended project, largest dataset/database, recommended warehouse) after you authenticate.
   </Accordion>
 
+  <a id="adding-lightdashs-static-ip-addresses-to-your-allow-list" />
+
   <Accordion title="Adding Lightdash's static IP addresses to your allow-list">
 
   Since we host your Lightdash for you, you may need to add our static IP addresses to the allow-list for your security group or firewall rules so they don’t block calls from your Lightdash Cloud to your connected databases.

self-host/customize-deployment/environment-variables.mdx

@@ -750,7 +750,7 @@ On server start, we will check the following variables, and update some configur
 
 ## Initialize multiple projects
 
-Set `LD_SETUP_PROJECTS` to a JSON array to provision **multiple projects at once**. This is a drop-in replacement for the single-project `LD_SETUP_PROJECT_*` variables described in [Initialize instance](#initialize-instance) — when `LD_SETUP_PROJECTS` is set, the legacy `LD_SETUP_PROJECT_*` and `LD_SETUP_GITHUB_*` variables are ignored.
+Set `LD_SETUP_PROJECTS` to a JSON array to provision **multiple projects at once**. This is a drop-in replacement for the single-project `LD_SETUP_PROJECT_*` variables described in [Initialize instance](#initialize-instance-enterprise) — when `LD_SETUP_PROJECTS` is set, the legacy `LD_SETUP_PROJECT_*` and `LD_SETUP_GITHUB_*` variables are ignored.
 
 On every boot, Lightdash matches each entry to an existing project by its `name`: new names are created, existing names are updated in place.
 
@@ -762,7 +762,7 @@ Multi-project setup supports Databricks project types and GitHub dbt configurati
 
 ### Required companion variables
 
-The admin, organization, and API key variables from [Initialize instance](#initialize-instance) still apply. `LD_SETUP_ADMIN_EMAIL` is required — without it, `LD_SETUP_PROJECTS` is ignored.
+The admin, organization, and API key variables from [Initialize instance](#initialize-instance-enterprise) still apply. `LD_SETUP_ADMIN_EMAIL` is required — without it, `LD_SETUP_PROJECTS` is ignored.
 
 ### Schema
 

semantic-layer/dimensions.mdx

@@ -25,7 +25,7 @@ models:
 Write these entries by hand, or generate one for every column in a model with [`lightdash generate`](/workflow/cli/generate).
 
 <Warning>
-  Dimensions cannot use window functions in their `sql`. A dimension's SQL is inserted into the same `SELECT` as the main `GROUP BY` in the generated query, and SQL does not allow window functions in that position. If you need window-function logic, either model it directly in your dbt model (so the value is precomputed before Lightdash queries it), or add a [table calculation](/explore/table-calculations) on the query results. Lightdash also supports a small set of built-in window operations through [post calculation metrics](/semantic-layer/metrics#post-calculation-metrics) (`percent_of_previous`, `percent_of_total`, `running_total`).
+  Dimensions cannot use window functions in their `sql`. A dimension's SQL is inserted into the same `SELECT` as the main `GROUP BY` in the generated query, and SQL does not allow window functions in that position. If you need window-function logic, either model it directly in your dbt model (so the value is precomputed before Lightdash queries it), or add a [table calculation](/explore/table-calculations) on the query results. Lightdash also supports a small set of built-in window operations through [post calculation metrics](/semantic-layer/metrics#post-calculation-metrics-experimental) (`percent_of_previous`, `percent_of_total`, `running_total`).
 </Warning>
 
 

semantic-layer/joins.mdx

@@ -928,7 +928,7 @@ FROM accounts
 
 **Option 2: Add a chained join to the other explore**
 
-Explicitly add the missing table as a [chained join](#chained-join-example) on any explore that needs it. This makes the referenced fields available in that context.
+Explicitly add the missing table as a chained join on any explore that needs it. This makes the referenced fields available in that context.
 
 <CodeGroup>
 ```yaml dbt v1.10+

semantic-layer/lightdash-config-yml.mdx

@@ -220,7 +220,7 @@ PUT /api/v2/projects/{projectUuid}/defaults
 { "pre_aggregate_execution_fallback": false }
 ```
 
-This setting only covers **execution-time** failures on a matched query. Queries that don't match any pre-aggregate — including cases where the pre-aggregate can't be resolved, or when a `sql_filter` or non-field reference makes the query [ineligible](/semantic-layer/pre-aggregates#sql-filter-and-pre-aggregates) — still run against the warehouse.
+This setting only covers **execution-time** failures on a matched query. Queries that don't match any pre-aggregate — including cases where the pre-aggregate can't be resolved, or when a `sql_filter` or non-field reference makes the query [ineligible](/semantic-layer/pre-aggregates#sql_filter-and-pre-aggregates) — still run against the warehouse.
 
 
 ### Case sensitivity hierarchy

semantic-layer/metrics.mdx

@@ -143,15 +143,15 @@ Aggregate metric types perform (surprise, surprise) aggregations. Sums and avera
 
 Aggregate metrics can _only_ reference dimensions, not other metrics.
 
-Aggregate metrics cannot use window functions in their `sql`. Their SQL is wrapped in an aggregate function and evaluated as part of the main `GROUP BY` in the generated query, and SQL does not allow window functions inside an aggregate call. See [post calculation metrics](#post-calculation-metrics) for the window operations Lightdash does support and what to do instead.
+Aggregate metrics cannot use window functions in their `sql`. Their SQL is wrapped in an aggregate function and evaluated as part of the main `GROUP BY` in the generated query, and SQL does not allow window functions inside an aggregate call. See [post calculation metrics](#post-calculation-metrics-experimental) for the window operations Lightdash does support and what to do instead.
 
 ### Non-aggregate metrics
 
 Non-aggregate metrics are metric types that, you guessed it, do _not_ perform aggregations.
 
 Numbers and booleans are examples of non-aggregate metrics. These metric types perform a calculation on a single data point, so they can only reference aggregate metrics. They _cannot_ reference dimensions.
 
-Non-aggregate metrics cannot use window functions in their `sql`. Their SQL is inserted alongside the aggregate metrics in the same `SELECT`, which runs in the same step as the `GROUP BY`, so window functions — which must run after aggregation — are not allowed. See [post calculation metrics](#post-calculation-metrics) for the window operations Lightdash does support and what to do instead.
+Non-aggregate metrics cannot use window functions in their `sql`. Their SQL is inserted alongside the aggregate metrics in the same `SELECT`, which runs in the same step as the `GROUP BY`, so window functions — which must run after aggregation — are not allowed. See [post calculation metrics](#post-calculation-metrics-experimental) for the window operations Lightdash does support and what to do instead.
 
 ### Post calculation metrics <Badge icon="test-pipe-2" color="orange" size="sm" shape="pill">Experimental</Badge>
 
@@ -317,8 +317,8 @@ Here are all of the properties you can customize:
 | [number](#number)                           | Non-aggregate                   | For adding calculations to metrics that return numbers.                         |
 | [string](#string)                           | Non-aggregate                   | For metrics that contain letters or special characters                          |
 | [sum](#sum)                                 | Aggregate                       | Generates a sum of values within a column                                       |
-| [sum_distinct](#sum_distinct)               | Aggregate (Beta)                | Generates a sum of values, deduplicating by specified keys                      |
-| [average_distinct](#average_distinct)       | Aggregate (Beta)                | Generates an average of values, deduplicating by specified keys                 |
+| [sum_distinct](#sum_distinct-beta)               | Aggregate (Beta)                | Generates a sum of values, deduplicating by specified keys                      |
+| [average_distinct](#average_distinct-beta)       | Aggregate (Beta)                | Generates an average of values, deduplicating by specified keys                 |
 | [percent_of_previous](#percent_of_previous) | Post calculation (Experimental) | Current value as a percentage of the previous row's value                       |
 | [percent_of_total](#percent_of_total)       | Post calculation (Experimental) | Current value as a percentage of the total across the result set (or partition) |
 | [running_total](#running_total)             | Post calculation (Experimental) | Cumulative total                                                                |
@@ -327,7 +327,7 @@ Here are all of the properties you can customize:
 
 Takes the percentile of the values in the given field. Like SQL's `PERCENTILE_CONT` function.
 
-The `percentile` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
+The `percentile` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
 
 For example, this creates a metric `median_price` by taking the 50% percentile of the `item_price` dimension:
 
@@ -372,7 +372,7 @@ metrics:
 
 Takes the 50th percentile of the values in the given field. Like SQL's `PERCENTILE_CONT(0.5)` function.
 
-The `median` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
+The `median` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
 
 For example, this creates a metric `median_price` by taking the 50% percentile of the `item_price` dimension:
 
@@ -414,7 +414,7 @@ metrics:
 
 Takes the average (mean) of the values in the given field. Like SQL's `AVG` function.
 
-The `average` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
+The `average` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
 
 For example, this creates a metric `avg_price` by taking the average of the `item_price` dimension:
 
@@ -509,7 +509,7 @@ metrics:
 
 Does a table count, like SQL’s `COUNT` function.
 
-The `count` metric can be used on any dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a set of values.
+The `count` metric can be used on any dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a set of values.
 
 For example, this creates a metric `number_of_users` by counting the number of `user_id` values in the table:
 
@@ -551,7 +551,7 @@ metrics:
 
 Counts the number of distinct values in a given field. It's like SQL’s `COUNT DISTINCT` function.
 
-The `count_distinct` metric can be used on any dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a set of values.
+The `count_distinct` metric can be used on any dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a set of values.
 
 For example, this creates a metric `number_of_unique_users` by counting the number of unique `user_id` values in the table:
 
@@ -645,7 +645,7 @@ metrics:
 
 Max gives you the largest value in a given numeric field. It's like SQL’s `MAX` function.
 
-The `max` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric value.
+The `max` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric value.
 
 Because `type: max` metrics only work with numerical fields, you can't use them to find a maximum date. Instead, you can use the `MAX()` function in the `sql` parameter of a metric of `type: date` to get a maximum date (you can see an [example of this in the date section](#date).
 
@@ -689,7 +689,7 @@ metrics:
 
 Min gives you the smallest value in a given numeric field. It's like SQL’s `MIN` function.
 
-The `min` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric value.
+The `min` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric value.
 
 Because `type: min` metrics only work with numerical fields, you can't use them to find a minimum date. Instead, you can use the `MIN()` function in the `sql` parameter of a metric of `type: date` to get a minimum date (you can see an [example of this in the date section](#date).
 
@@ -801,7 +801,7 @@ The example above also uses the NULLIF() SQL function to avoid division-by-zero
 
 Adds up the values in a given field. Like SQL's `SUM` function.
 
-The `sum` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
+The `sum` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column.
 
 For example, this creates a metric `total_revenue` by adding up the values in the `revenue` dimension:
 
@@ -1021,7 +1021,7 @@ If you want a per-group total that varies with an unrelated dimension, add that
 
 `average_distinct` is in [Beta](/support/feature-maturity-levels).
 
-Calculates the average of values in a given field while deduplicating data based on one or more specified distinct keys. This works the same way as [`sum_distinct`](#sum_distinct), but computes an average instead of a sum.
+Calculates the average of values in a given field while deduplicating data based on one or more specified distinct keys. This works the same way as [`sum_distinct`](#sum_distinct-beta), but computes an average instead of a sum.
 
 <Info>
 Lightdash already supports [SQL fanout protection](/semantic-layer/joins#handling-fanouts) to remove duplicates when joining tables together. `average_distinct` allows you to remove duplicates from wide tables where deduplication cannot be handled at the join level.
@@ -1185,7 +1185,7 @@ metrics:
 ```
 </CodeGroup>
 
-`average_distinct` follows the same rules as `sum_distinct` for how selected dimensions interact with `distinct_keys`. See [How selected dimensions interact with `distinct_keys`](#sum_distinct) for details.
+`average_distinct` follows the same rules as `sum_distinct` for how selected dimensions interact with `distinct_keys`. See [How selected dimensions interact with `distinct_keys`](#sum_distinct-beta) for details.
 
 ### string