Fixed more links

Author: antonpirker

develop-docs/sdk/data-model/envelope-items.mdx

@@ -7,7 +7,7 @@ Each Envelope consists of headers and a potentially empty list of Items, each
 with their own headers. Which Headers are required depends on the Items in an
 Envelope. This section describes all Item types and their respective required
 headers. It is worth noting that the list of Item types doesn't match the data
-categories used for [rate limiting](/sdk/rate-limiting/#definitions) and
+categories used for [rate limiting](/sdk/expected-features/rate-limiting/#definitions) and
 client reports.
 
 The type of an Item is declared in the `type` header, as well as the payload
@@ -118,7 +118,7 @@ file. It is always associated to an event or transaction.
 Item type `"session"` contains a single session initialization or update to an
 existing session for Release Health.
 
-See the <Link to="/sdk/sessions/">sessions</Link> documentation for the payload
+See the <Link to="/sdk/telemetry/sessions/">sessions</Link> documentation for the payload
 details.
 
 **Constraints:**
@@ -134,7 +134,7 @@ details.
 
 Item type `"sessions"` contains buckets of pre-aggregated session counts.
 
-See the <Link to="/sdk/sessions/">sessions</Link> documentation for the payload
+See the <Link to="/sdk/telemetry/sessions/">sessions</Link> documentation for the payload
 details.
 
 **Constraints:**
@@ -246,7 +246,7 @@ details.
 
 Item type `"replay_event"` contains a replay payload encoded in JSON.
 
-See the <Link to="/sdk/replays/">replays</Link> documentation for the payload
+See the <Link to="/sdk/telemetry/replays/">replays</Link> documentation for the payload
 details.
 
 **Constraints:**
@@ -266,7 +266,7 @@ details.
 
 Item type `"replay_recording"` contains a replay recording payload encoded in JSON *or* a gzipped JSON.
 
-See the <Link to="/sdk/replays/">replays</Link> documentation for the payload
+See the <Link to="/sdk/telemetry/replays/">replays</Link> documentation for the payload
 details.
 
 **Constraints:**

develop-docs/sdk/expected-features/data-handling.mdx

@@ -31,7 +31,7 @@ All other platforms require the event to include `user.ip={{auto}}` which happen
 
 Before sending events to Sentry, the SDKs should invokes callbacks. That allows users to remove any sensitive data client-side.
 
-- [`before-send` and `event-processors`](https://develop.sentry.dev/sdk/unified-api/#static-api) can be used to register a callback with custom logic to remove sensitive data.
+- [`before-send` and `event-processors`](https://develop.sentry.dev/sdk/miscellaneous/unified-api/#static-api) can be used to register a callback with custom logic to remove sensitive data.
 
 ### Application State
 
@@ -119,4 +119,4 @@ Fields in the event payload that allow user-specified or dynamic values are rest
 Additionally, size limits apply to all store requests for the total size of the request, event payload, and attachments. Sentry rejects all requests exceeding these limits. Please refer the following resources for the exact size limits:
 
 - <Link to="/sdk/data-model/envelopes/#size-limits">Envelope Endpoint Size Limits</Link>
-- <Link to="/sdk/store/#size-limits">Store Endpoint Size Limits</Link>
+- <Link to="/sdk/miscellaneous/store/#size-limits">Store Endpoint Size Limits</Link>

develop-docs/sdk/miscellaneous/hub_and_scope_refactoring.mdx

@@ -9,7 +9,7 @@ This is work in progress.
 Development has started in JS and Python, but we are still ironing out the wrinkles.
 </Alert>
 
-Historically Sentry's SDKs implemented the Hubs and Scopes models, a major defining aspect of the <Link to="/sdk/unified-api/">Unified API</Link>. This introduced a lot of complexity in a user facing manner, allowed more room for error from the user as well as SDK maintainers. Since looking at adopting OpenTelemetry "packages", to replace or in addition to, our existing performance packages in SDKs, there is a forcing factor. Sentry's model being different to OpenTelemetry's prevents us from supporting OpenTelemetry.
+Historically Sentry's SDKs implemented the Hubs and Scopes models, a major defining aspect of the <Link to="/sdk/miscellaneous/unified-api/">Unified API</Link>. This introduced a lot of complexity in a user facing manner, allowed more room for error from the user as well as SDK maintainers. Since looking at adopting OpenTelemetry "packages", to replace or in addition to, our existing performance packages in SDKs, there is a forcing factor. Sentry's model being different to OpenTelemetry's prevents us from supporting OpenTelemetry.
 
 ## A) Why Are We Doing This?
 
@@ -135,7 +135,7 @@ We should make it very clear in the changelog that top level API only writes to
 
 ## E) Implementation Details
 
-We will merge the functionality of the `Hub` and the `Scope` of the <Link to="/sdk/unified-api/">Unified API</Link> into the `Scope` and we will remove the `Hub`. We will add some new APIs that make it easier for the user to do custom instrumentation. We will update our auto instrumentation to fork a scope whenever a new span is created. This aligns us with what OTel does.
+We will merge the functionality of the `Hub` and the `Scope` of the <Link to="/sdk/miscellaneous/unified-api/">Unified API</Link> into the `Scope` and we will remove the `Hub`. We will add some new APIs that make it easier for the user to do custom instrumentation. We will update our auto instrumentation to fork a scope whenever a new span is created. This aligns us with what OTel does.
 
 TODO: add where the propagation context is stored and applied, add how tracing without performance works, where spans/transactions live and other problems we discovered and solved in implementing this in the first two SDKs.
 

develop-docs/sdk/miscellaneous/unified-api/index.mdx

@@ -17,7 +17,7 @@ _Types Example:_ Typed languages might have very different developer experience
 
 _Platform Example:_ Does Rust have exceptions? Nope, don't name APIs for rust like `captureException`.
 
-_Unified API Example:_ We don't like Hubs and Scopes anymore, and we are redefining that, <Link to="/sdk/hub_and_scope_refactoring/">Hub & Scope Refactoring</Link>
+_Unified API Example:_ We don't like Hubs and Scopes anymore, and we are redefining that, <Link to="/sdk/miscellaneous/hub_and_scope_refactoring/">Hub & Scope Refactoring</Link>
 
 </Alert>
 

develop-docs/sdk/research/performance/index.mdx

@@ -26,7 +26,7 @@ In the next section, we’ll discuss some of the shortcomings with the current m
 
 ## Identified Issues
 
-While the reuse of the [Unified SDK architecture](https://develop.sentry.dev/sdk/unified-api/) (hubs, clients, scopes) and the transaction ingestion model have merits, experience revealed some issues that we categorize into two groups.
+While the reuse of the [Unified SDK architecture](https://develop.sentry.dev/sdk/miscellaneous/unified-api/) (hubs, clients, scopes) and the transaction ingestion model have merits, experience revealed some issues that we categorize into two groups.
 
 The first group has to do with scope propagation, in essence the ability to determine what the “current scope” is. This operation is required for both manual instrumentation in user code as well as for automatic instrumentation in SDK integrations.
 
@@ -36,7 +36,7 @@ The second group is for issues related to the wire format used to send transacti
 
 _This issue is tracked by [getsentry/sentry-javascript#3751](https://github.com/getsentry/sentry-javascript/issues/3751)._
 
-The [Unified SDK architecture](https://develop.sentry.dev/sdk/unified-api/) is fundamentally based on the existence of a `hub` per unit of concurrency, each `hub` having a stack of pairs of `client` and `scope`. A `client` holds configuration and is responsible for sending data to Sentry by means of a `transport`, while a `scope` holds contextual data that gets appended to outgoing events, such as tags and breadcrumbs.
+The [Unified SDK architecture](https://develop.sentry.dev/sdk/miscellaneous/unified-api/) is fundamentally based on the existence of a `hub` per unit of concurrency, each `hub` having a stack of pairs of `client` and `scope`. A `client` holds configuration and is responsible for sending data to Sentry by means of a `transport`, while a `scope` holds contextual data that gets appended to outgoing events, such as tags and breadcrumbs.
 
 Every `hub` knows what the current scope is. It is always the scope on top of the stack. The difficult part is having a `hub` “per unit of concurrency”.
 

develop-docs/sdk/serverless-sdks/index.mdx

@@ -4,4 +4,4 @@ description: Information specific to developing serverless SDKs.
 sidebar_order: 9
 ---
 
-- [AWS Lambda](/sdk/serverless/aws-lambda/)
+- [AWS Lambda](/sdk/serverless-sdks/aws-lambda/)

develop-docs/sdk/telemetry/client-reports.mdx

@@ -82,7 +82,7 @@ The following fields exist:
 : _List of outcome objects_ \{`reason`, `category`, `quantity`\}
 
 - `reason`: A string reason that defines why events were lost.
-- `category`: The data category for which the discard reason applies. These are the same data categories used for [rate limits](/sdk/rate-limiting/#definitions).
+- `category`: The data category for which the discard reason applies. These are the same data categories used for [rate limits](/sdk/expected-features/rate-limiting/#definitions).
 - `quantity`: The number of events which were lost
 
 The following discard reasons are currently defined for `discarded_events`:

develop-docs/sdk/telemetry/sessions/index.mdx

@@ -378,7 +378,7 @@ received and end it when a response is returned.
 
 ### Unified API Implications
 
-The <Link to="/sdk/unified-api/">Unified API</Link> that SDKs should
+The <Link to="/sdk/miscellaneous/unified-api/">Unified API</Link> that SDKs should
 adhere to defines the concepts of `Hub`, `Scope` and `Client`.
 
 Conceptually speaking, the session is a concern of the `Hub`, and unlike scopes,

docs/concepts/data-management/size-limits.mdx

@@ -26,6 +26,6 @@ To avoid using up your attachments quota — which is based on size and not numb
 Sentry's exact size limits may change over time. For more information, please refer to the following resources:
 
 - [Envelope Size Limits](https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits)
-- [Store Endpoint Size Limits](https://develop.sentry.dev/sdk/store/#size-limits)
+- [Store Endpoint Size Limits](https://develop.sentry.dev/sdk/miscellaneous/store/#size-limits)
 - [Minidump Size Limits](/platforms/native/guides/minidumps/#size-limits)
 - [Variable Size Limits](https://develop.sentry.dev/sdk/data-handling/#variable-size)

docs/platforms/android/migration/index.mdx

@@ -420,7 +420,7 @@ Other than that, the APIs didn't change. Release Heath sets by default. If you p
 
 ## Migrating from `io.sentry:sentry-android 1.x` to `io.sentry:sentry-android 2.x`
 
-With Sentry Android, we've updated the API to resemble the [Unified API](https://develop.sentry.dev/sdk/unified-api/) more closely. And now that the SDK isn't built on top of `io.sentry:sentry-java`, Sentry Android has more Android-specific features.
+With Sentry Android, we've updated the API to resemble the [Unified API](https://develop.sentry.dev/sdk/miscellaneous/unified-api/) more closely. And now that the SDK isn't built on top of `io.sentry:sentry-java`, Sentry Android has more Android-specific features.
 
 If you want to upgrade from the previous version of the SDK, please check the following sections of changes that may need updating in your code.