Some more link fixes

antonpirker · antonpirker · commit 07900dcb717b · 2024-10-11T16:34:49.000+02:00
diff --git a/develop-docs/sdk/data-model/envelopes.mdx b/develop-docs/sdk/data-model/envelopes.mdx
@@ -44,8 +44,7 @@ POST /api/<project_id>/envelope/
 ## Serialization Format
 
 This section defines the Envelope data format and serialization. For details on
-data integrity and a list of valid Item types refer to the next section [Data
-Model](#data-model).
+data integrity and a list of valid Item types refer to [Envelope Items](/sdk/data-model/envelope-items/).
 
 ### Prerequisites
 
@@ -102,7 +101,7 @@ Payload = { * } ;
   [Headers](#headers) section. Attributes defined in the Envelope header scope
   the contents of the Envelope and can be thought of as applying to all Items.
 - Based on the contents of the Envelope, certain header attributes may be
-  required. See [Data Model](#data-model) for a specification of required
+  required. See [Envelope Items](/sdk/data-model/envelope-items/) for a specification of required
   attributes.
 - **Items** comprise their own headers and a payload. There can be
   an arbitrary number of **Items** in an Envelope separated by a newline. An
@@ -185,7 +184,7 @@ There are two generic headers for every Item:
 `type`
 
 : **String, required.** Specifies the type of this Item and its contents. Based
-  on the Item type, more headers may be required. See [Data Model](#data-model) for a list
+  on the Item type, more headers may be required. See [Envelope Items](/sdk/data-model/envelope-items/) for a list
   of all Item types.
 
 `length`
diff --git a/develop-docs/sdk/data-model/event-payloads/contexts.mdx b/develop-docs/sdk/data-model/event-payloads/contexts.mdx
@@ -640,7 +640,7 @@ Additional information that allows Sentry to connect multiple transactions, span
 
 `op`
 
-: _Optional_. Short code identifying the type of operation the span is measuring. For more details, see [Sentry's conventions around span operations](https://develop.sentry.dev/sdk/performance/span-operations/).
+: _Optional_. Short code identifying the type of operation the span is measuring. For more details, see [Sentry's conventions around span operations](/sdk/performance/span-operations/).
 
 - Example: `"http.server"`
 
@@ -692,7 +692,7 @@ Additional information that allows Sentry to connect multiple transactions, span
 
 `dynamic_sampling_context`
 
-: _Optional_. The [Dynamic Sampling Context](https://develop.sentry.dev/sdk/performance/dynamic-sampling-context/).
+: _Optional_. The [Dynamic Sampling Context](/sdk/performance/dynamic-sampling-context/).
 
 - Example: `{ "trace_id": "12312012123120121231201212312012", "sample_rate": "1.0", "public_key": "93D0D1125146288EAEE2A9B3AF4F96CCBE3CB316" },`
 
diff --git a/develop-docs/sdk/expected-features/data-handling.mdx b/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/miscellaneous/unified-api/#static-api) can be used to register a callback with custom logic to remove sensitive data.
+- [`before-send` and `event-processors`](/sdk/miscellaneous/unified-api/#static-api) can be used to register a callback with custom logic to remove sensitive data.
 
 ### Application State
 
diff --git a/develop-docs/sdk/expected-features/rate-limiting.mdx b/develop-docs/sdk/expected-features/rate-limiting.mdx
@@ -15,7 +15,7 @@ Each *quota_limit* has the form `retry_after:categories:scope:reason_code:namesp
 
 - `retry_after`: Number of seconds (as an integer or a floating point number) until this rate limit expires.
 - `categories`: Semicolon-separated list of [data categories](https://github.com/getsentry/relay/blob/master/relay-base-schema/src/data_category.rs#L91). **If empty, this limit applies to all categories**.
-    While these categories might look similar to the [envelope item types](/sdk/data-model/envelopes/#data-model), they are not identical, and have slight differences.
+    While these categories might look similar to the [envelope item types](/sdk/data-model/envelope-items/), they are not identical, and have slight differences.
 - `scope`: The scope that this limit applies to. Can be ignored by SDKs.
 - `reason_code`: A unique identifier for the quota hinting at the rate limiting reason. Can be ignored by SDKs.
 - `namespaces`: Semicolon-separated list of metric namespace identifiers. This will only be present if the rate limit applies to the `metric_bucket` data category. If the namespace is not present, the backoff applies to all metrics.
@@ -83,7 +83,7 @@ Guidelines for how SDKs should determine the current rate limits:
 As stated earlier, SDKs can ignore the `scope` dimension. These definitions are here as a suplement to explain what the `X-Sentry-Rate-Limits` header is made of.
 
 - **Category:** Classifies the type of data that is being counted. Arbitrary categories can be added as long as they can be inferred from the event or data being ingested.
-While these [data categories](https://github.com/getsentry/relay/blob/master/relay-base-schema/src/data_category.rs#L91) might look similar to the [envelope item types](/sdk/data-model/envelopes/#data-model), they are not identical, and have slight differences.
+While these [data categories](https://github.com/getsentry/relay/blob/master/relay-base-schema/src/data_category.rs#L91) might look similar to the [envelope item types](/sdk/data-model/envelope-items/), they are not identical, and have slight differences.
   - `default`: Events with an event_type not listed explicitly below.
   - `error`: Error events.
   - `transaction`: Transaction type events.
diff --git a/develop-docs/sdk/miscellaneous/unified-api/index.mdx b/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/miscellaneous/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/hub_and_scope_refactoring/">Hub & Scope Refactoring</Link>
 
 </Alert>
 
@@ -280,7 +280,7 @@ processing happens.
 
 ## Options
 
-Many options are standardized across SDKs. For a list of these refer to [the main options documentation](https://docs.sentry.io/error-reporting/configuration/).
+Many options are standardized across SDKs. For a list of these refer to [the main options documentation](https://docs.sentry.io/platforms/javascript/configuration/).
 
 ## Integrations
 
diff --git a/develop-docs/sdk/telemetry/check-ins.mdx b/develop-docs/sdk/telemetry/check-ins.mdx
@@ -66,7 +66,7 @@ The following fields exist:
 `contexts`
 
 : _Object, optional_. A dictionary of contextual information about the environment running
- the check-in. Right now we only support the [trace context](https://develop.sentry.dev/sdk/data-model/event-payloads/contexts/#trace-context)
+ the check-in. Right now we only support the [trace context](/sdk/data-model/event-payloads/contexts/#trace-context)
   and use the `trace_id` in order to link check-ins to associated errors.
 
 ## Monitor upsert support
diff --git a/develop-docs/sdk/telemetry/replays.mdx b/develop-docs/sdk/telemetry/replays.mdx
@@ -19,7 +19,7 @@ The following attributes are specific to the `"replay_event"` Item type.
 | Key                    | Type                      | Description                                                                                                                                                                                                                                                                        |
 | ---------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | type                   | `"replay_event"`          | Must be `"replay_event"`                                                                                                                                                                                                                                                           |
-| replay_id              | string                    | A unique ID for the replay. Follows the [same requirements](https://develop.sentry.dev/sdk/data-model/event-payloads/#required-attributes) as an `event_id`: Hexadecimal string representing a uuid4 value. The length is exactly 32 characters. Dashes are not allowed. Has to be lowercase. |
+| replay_id              | string                    | A unique ID for the replay. Follows the [same requirements](/sdk/data-model/event-payloads/#required-attributes) as an `event_id`: Hexadecimal string representing a uuid4 value. The length is exactly 32 characters. Dashes are not allowed. Has to be lowercase.                |
 | replay_type            | `"session"` \| `"buffer"` | Describes the type of replay. `buffer` means the replay is buffered while waiting for an error to occur or until a manual flush. `session` means the replay starts recording immediately and continues through the lifespan of the replay session.                                 |
 | segment_id             | number                    | The segment id.                                                                                                                                                                                                                                                                    |
 | replay_start_timestamp | number                    | UNIX timestamp of the start of the replay (in seconds). This is only required on the first segment.                                                                                                                                                                                |
@@ -29,7 +29,7 @@ The following attributes are specific to the `"replay_event"` Item type.
 
 ### Event Attributes
 
-The following attributes are a subset of the [optional attributes](https://develop.sentry.dev/sdk/data-model/event-payloads/#optional-attributes) of an Event.
+The following attributes are a subset of the [optional attributes](/sdk/data-model/event-payloads/#optional-attributes) of an Event.
 
 | Key                        | Type   | Description                                      |
 | -------------------------- | ------ | ------------------------------------------------ |
diff --git a/develop-docs/sdk/telemetry/traces/frames-delay.mdx b/develop-docs/sdk/telemetry/traces/frames-delay.mdx
@@ -21,11 +21,11 @@ The major downside is that they lack essential information on how long they last
 significant problem when prioritizing which unresponsive application parts need improvement. The following
 scenarios highlight the problem when prioritizing by looking at slow and frozen frames.
 
-Scenario | Slow Frames | Frozen Frames |
--- | -- | -- | --
-1 |  5 all 500ms | 0 |
-2 | 10 all 20ms | 0 |
-3 |  0 | 1 with 800ms |
+Scenario | Slow Frames | Frozen Frames
+-- | -- | --
+1 |  5 all 500ms | 0
+2 | 10 all 20ms | 0
+3 |  0 | 1 with 800ms
 
 When comparing the different scenarios, a user might want to fix scenario 3 first because it contains one frozen
 frame. When comparing scenarios 1 and 2, they would pick scenario 2 cause it has more slow frames. While scenario
