fix many more

JustinBeckwith · JustinBeckwith · commit 9b30374ffac6 · 2025-04-16T09:03:30.000-07:00
diff --git a/docs/change-log/2022-07-01-add-subcommand-groups-and-subcommands-to-message-interaction-objects.md b/docs/change-log/2022-07-01-add-subcommand-groups-and-subcommands-to-message-interaction-objects.md
@@ -4,7 +4,7 @@ date: "2022-07-01"
 breaking: true
 ---
 
-While this is a breaking change, most apps only rely on interaction responses (`INTERACTION_CREATE`), *not* message interaction objects (`MESSAGE_CREATE`). [Interaction responses](/docs/interactions/receiving-and-responding#message-interaction-object/interaction-object-interaction-data) are unaffected by this change.
+While this is a breaking change, most apps only rely on interaction responses (`INTERACTION_CREATE`), *not* message interaction objects (`MESSAGE_CREATE`). [Interaction responses](/docs/interactions/receiving-and-responding#interaction-object-interaction-data) are unaffected by this change.
 
 #### Upcoming Changes
 
diff --git a/docs/developer-tools/game-sdk.mdx b/docs/developer-tools/game-sdk.mdx
@@ -647,7 +647,7 @@ For more detailed information and documentation around the Rich Presence feature
 | Custom    | 4     |
 | Competing | 5     |
 
-For more details about the activity types, [see Gateway documentation](/docs/events/gateway-events#/activity-object-activity-types).
+For more details about the activity types, [see Gateway documentation](/docs/events/gateway-events#activity-object-activity-types).
 
 `ActivityType` is strictly for the purpose of handling events that you receive from Discord; though the SDK will not reject a payload with an `ActivityType` sent, it will be discarded and will not change anything in the client.
 
diff --git a/docs/discord-social-sdk/design-guidelines/connection-points.mdx b/docs/discord-social-sdk/design-guidelines/connection-points.mdx
@@ -14,7 +14,7 @@ If the game has account management, then this connection point is **required**,
 
 Discord's sign-in button is presented as the **primary option** to log-in for the player amongst the list of **external identity-providers** due to providing deeper user-benefits than a standard OAuth login.
 
-Please use the [**Blurple Button**](/docs/discord-social-sdk/design-guidelines/branding-guidelines/buttons) button styling for the sign-in connection point.
+Please use the [**Blurple Button**](/docs/discord-social-sdk/design-guidelines/branding-guidelines#buttons) button styling for the sign-in connection point.
 
 ![Signing In](images/social-sdk/design-guidelines/ConnectionPoints-03.png)
 
diff --git a/docs/discord-social-sdk/design-guidelines/signing-in.mdx b/docs/discord-social-sdk/design-guidelines/signing-in.mdx
@@ -11,7 +11,7 @@ sidebar_label: Signing In
 
 ## Overall flow 
 
-Sign-in or log-in flows all begin with the interaction of a [**Discord-styled button**](/docs/discord-social-sdk/design-guidelines_BRANDING_GUIDELINES/buttons).
+Sign-in or log-in flows all begin with the interaction of a [**Discord-styled button**](/docs/discord-social-sdk/design-guidelines/branding-guidelines#buttons).
 
 The Discord Social SDK will support the user-journeys for those who already **have a Discord account** and those who **do not**. We will similarly support those who have Discord installed as well as those who do not (via browser).
 
diff --git a/docs/discord-social-sdk/development-guides.mdx b/docs/discord-social-sdk/development-guides.mdx
@@ -72,7 +72,7 @@ If you are new to the Discord Social SDK, we recommend you start with the [Getti
 ## Developer Best Practices
 
 <Container>
-  <Card title="Debugging & Logging" link="/docs/discord-social-sdk/development-guides_DEBUGGING_LOGGING" icon="BugIcon">
+  <Card title="Debugging & Logging" link="/docs/discord-social-sdk/development-guides/debugging-logging" icon="BugIcon">
     Use logging and debugging tools to troubleshoot issues.
   </Card>
   <Card title="Using with Discord APIs" link="/docs/discord-social-sdk/development-guides/using-with-discord-apis" icon="ClydeIcon">
diff --git a/docs/discord-social-sdk/development-guides/account-linking-on-consoles.mdx b/docs/discord-social-sdk/development-guides/account-linking-on-consoles.mdx
@@ -92,11 +92,11 @@ If you plan to handle console authorization manually, you can follow these steps
 
 We'll be following the same OAuth2 device authorization flow as the automatic method, but you'll need to manually handle the polling and token exchange.
 
-1. [Request a device code from Discord](/docs/discord-social-sdk/development-guides/account-linking-on-consoles/step-1-request-a-device-code-from-discord)
-2. [Display the user verification information](/docs/discord-social-sdk/development-guides/account-linking-on-consoles/step-2-display-authorize-screen-with-qr-code-and-user-code) or open the authorization screen (optional)
-3. [Poll for the user's authorization](/docs/discord-social-sdk/development-guides/account-linking-on-consoles/step-3-poll-for-users-authorization)
-4. [Exchange the device code for an access token](/docs/discord-social-sdk/development-guides/account-linking-on-consoles/step-4-exchange-device-code-for-access-token)
-5. [Handle the token response](/docs/discord-social-sdk/development-guides/account-linking-on-consoles/step-5-handle-token-response) and close authorization screen (optional)
+1. [Request a device code from Discord](/docs/discord-social-sdk/development-guides/account-linking-on-consoles#step-1-request-a-device-code-from-discord)
+2. [Display the user verification information](/docs/discord-social-sdk/development-guides/account-linking-on-consoles#step-2-display-authorize-screen-with-qr-code-and-user-code) or open the authorization screen (optional)
+3. [Poll for the user's authorization](/docs/discord-social-sdk/development-guides/account-linking-on-consoles#step-3-poll-for-users-authorization)
+4. [Exchange the device code for an access token](/docs/discord-social-sdk/development-guides/account-linking-on-consoles#step-4-exchange-device-code-for-access-token)
+5. [Handle the token response](/docs/discord-social-sdk/development-guides/account-linking-on-consoles#step-5-handle-token-response) and close authorization screen (optional)
 
 ### Step 1: Request a Device Code from Discord
 
diff --git a/docs/discord-social-sdk/development-guides/linked-channels.mdx b/docs/discord-social-sdk/development-guides/linked-channels.mdx
@@ -116,7 +116,7 @@ struct GuildChannel {
 
 ### Saving a channel link selection
 
-Once the user has chosen a channel to link to, you can call [`Client::LinkChannelToLobby`] to set or change the channel a lobby is linked to. You can also use [`Client::UnlinkChannelFromLobby`] to remove the link. The conditions specified in [Linked Channel Requirements](/docs/discord-social-sdk/development-guides/linked-channels/channel-requirements) must be met for the given lobby, channel, and user.
+Once the user has chosen a channel to link to, you can call [`Client::LinkChannelToLobby`] to set or change the channel a lobby is linked to. You can also use [`Client::UnlinkChannelFromLobby`] to remove the link. The conditions specified in [Linked Channel Requirements](/docs/discord-social-sdk/development-guides/linked-channels#channel-requirements) must be met for the given lobby, channel, and user.
 
 ### Try It Out
 
diff --git a/docs/events/gateway.mdx b/docs/events/gateway.mdx
@@ -9,7 +9,7 @@ The Gateway API lets apps open secure WebSocket connections with Discord to rece
 > info
 > In *most* cases, performing REST operations on Discord resources can be done using the [HTTP API](/docs/reference#http-api) rather than the Gateway API. 
 
-The Gateway is Discord's form of real-time communication used by clients (including apps), so there are nuances and data passed that simply isn't relevant to apps. Interacting with the Gateway can be tricky, but there are [community-built libraries](/docs/developer-tools/community-resources/libraries) with built-in support that simplify the most complicated bits and pieces. If you're planning on writing a custom implementation, be sure to read the following documentation in its entirety so you understand the sacred secrets of the Gateway (or at least those that matter for apps).
+The Gateway is Discord's form of real-time communication used by clients (including apps), so there are nuances and data passed that simply isn't relevant to apps. Interacting with the Gateway can be tricky, but there are [community-built libraries](/docs/developer-tools/community-resources#libraries) with built-in support that simplify the most complicated bits and pieces. If you're planning on writing a custom implementation, be sure to read the following documentation in its entirety so you understand the sacred secrets of the Gateway (or at least those that matter for apps).
 
 ## Gateway Events
 
@@ -441,7 +441,7 @@ In addition to the gateway restrictions described here, Discord's REST API is al
 
 #### Enabling Privileged Intents
 
-Before using privileged intents, you must enable them in your app's settings. In the [Developer Portal](#APPLICATIONS), you can navigate to your app's settings then toggle the privileged intents on the **Bots** page under the "Privileged Gateway Intents" section. You should only toggle privileged intents that your bot *requires to function*.
+Before using privileged intents, you must enable them in your app's settings. In the [Developer Portal](https://discord.com/developers/applications), you can navigate to your app's settings then toggle the privileged intents on the **Bots** page under the "Privileged Gateway Intents" section. You should only toggle privileged intents that your bot *requires to function*.
 
 If your app qualifies for [verification](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified), you must first [verify your app](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified) and request access to these intents during the verification process. If your app is already verified and you need to request additional privileged intents, you can [contact support](https://dis.gd/support).
 
diff --git a/docs/events/overview.mdx b/docs/events/overview.mdx
@@ -19,7 +19,7 @@ Read details about each way to receive events in the sections below.
 
 Gateway events are the primary way apps can listen and send events. Most events related to resources in Discord, like updates to channels, guilds, roles, and messages, are only available over [Gateway](/docs/events/gateway).
 
-Gateway events are sent over a WebSocket-based [Gateway connection](/docs/events/gateway#connections) between Discord and your app. To receive Gateway events, your app must open and maintain a persistent Gateway connection which you can read details about in the [Gateway documentation](/docs/events/gateway#connections). To make receiving Gateway events simpler, we suggest using a [developer library](/docs/developer-tools/community-resources/libraries) which helps setup, maintain, and handle common pitfalls with Gateway connections (like [rate limits](/docs/events/gateway#rate-limiting)).
+Gateway events are sent over a WebSocket-based [Gateway connection](/docs/events/gateway#connections) between Discord and your app. To receive Gateway events, your app must open and maintain a persistent Gateway connection which you can read details about in the [Gateway documentation](/docs/events/gateway#connections). To make receiving Gateway events simpler, we suggest using a [developer library](/docs/developer-tools/community-resources#libraries) which helps setup, maintain, and handle common pitfalls with Gateway connections (like [rate limits](/docs/events/gateway#rate-limiting)).
 
 Details about receiving events using the Gateway API is in the [Gateway documentation](/docs/events/gateway#receiving-events), and the full list of available Gateway events is in the [Gateway Events documentation](/docs/events/gateway-events).
 
diff --git a/docs/interactions/application-commands.mdx b/docs/interactions/application-commands.mdx
@@ -27,7 +27,7 @@ Application commands are native ways to interact with apps in the Discord client
 | dm_permission?             | boolean                                                                                                                              | **Deprecated (use `contexts` instead)**; Indicates whether the command is available in DMs with the app, only for globally-scoped commands. By default, commands are visible.                                                                                                       | all                 |
 | default_permission?        | ?boolean                                                                                                                             | Not recommended for use as field will soon be deprecated. Indicates whether the command is enabled by default when the app is added to a guild, defaults to `true`                                                                                                                  | all                 |
 | nsfw?                      | boolean                                                                                                                              | Indicates whether the command is [age-restricted](/docs/interactions/application-commands#agerestricted-commands), defaults to `false`                                                                                                                                              | all                 |
-| integration_types?         | list of [integration types](/docs/resources/application#application-object-application-integration-types)                            | [Installation contexts](/docs/resources/application#installation-context) where the command is available, only for globally-scoped commands. Defaults to your app's [configured contexts](/docs/resources/application#installation-context/setting-supported-installation-contexts) | all                 |
+| integration_types?         | list of [integration types](/docs/resources/application#application-object-application-integration-types)                            | [Installation contexts](/docs/resources/application#installation-context) where the command is available, only for globally-scoped commands. Defaults to your app's [configured contexts](/docs/resources/application#setting-supported-installation-contexts) | all                 |
 | contexts?                  | ?list of [interaction context types](/docs/interactions/receiving-and-responding#interaction-object-interaction-context-types)       | [Interaction context(s)](/docs/interactions/receiving-and-responding#interaction-object-interaction-context-types) where the command can be used, only for globally-scoped commands. By default, all interaction context types included for new commands.                           | all                 |
 | version                    | snowflake                                                                                                                            | Autoincrementing version identifier updated during substantial record changes                                                                                                                                                                                                       | all                 |
 | handler?                   | one of [command handler types](/docs/interactions/application-commands#application-command-object-entry-point-command-handler-types) | Determines whether the interaction is handled by the app's interactions handler or by Discord                                                                                                                                                                                       | PRIMARY_ENTRY_POINT |
diff --git a/docs/interactions/overview.mdx b/docs/interactions/overview.mdx
@@ -157,7 +157,7 @@ except BadSignatureError:
 
 In addition to ensuring your app validates security-related request headers at the time of saving your endpoint, Discord will also perform automated, routine security checks against your endpoint, including purposefully sending you invalid signatures. If you fail the validation, we will remove your interactions URL and alert you via email and System DM.
 
-We highly recommend checking out our [Community Resources](/docs/developer-tools/community-resources/interactions) and the libraries found there. They not only provide typing for Interactions data models, but also include decorators for API frameworks like Flask and Express to make validation easy.
+We highly recommend checking out our [Community Resources](/docs/developer-tools/community-resources#interactions) and the libraries found there. They not only provide typing for Interactions data models, but also include decorators for API frameworks like Flask and Express to make validation easy.
 
 #### Adding an Interactions Endpoint URL
 
diff --git a/docs/topics/certified-devices.md b/docs/topics/certified-devices.md
@@ -6,7 +6,7 @@ Baked into Discord is the ability for hardware manufacturers to tell us a little
 
 I'm glad you asked!
 
-1. [Create an application](#APPLICATIONS) for your hardware vendor—save the Client ID!
+1. [Create an application](https://discord.com/developers/applications) for your hardware vendor—save the Client ID!
 2. Talk to Discord via one simple HTTP or WebSocket call
 3. Send us a [`SET_CERTIFIED_DEVICES`](/docs/topics/rpc#setcertifieddevices) WebSocket payload or equivalent HTTP POST whenever the state of the device changes
 
diff --git a/docs/topics/oauth2.md b/docs/topics/oauth2.md
@@ -4,7 +4,7 @@ OAuth2 enables application developers to build applications that utilize authent
 
 ## Shared Resources
 
-The first step in implementing OAuth2 is [registering a developer application](#APPLICATIONS) and retrieving your client ID and client secret. Most people who will be implementing OAuth2 will want to find and utilize a library in the language of their choice. For those implementing OAuth2 from scratch, please see [RFC 6749](https://tools.ietf.org/html/rfc6749) for details. After you create your application with Discord, make sure that you have your `client_id` and `client_secret` handy. The next step is to figure out which OAuth2 flow is right for your purposes.
+The first step in implementing OAuth2 is [registering a developer application](https://discord.com/developers/applications) and retrieving your client ID and client secret. Most people who will be implementing OAuth2 will want to find and utilize a library in the language of their choice. For those implementing OAuth2 from scratch, please see [RFC 6749](https://tools.ietf.org/html/rfc6749) for details. After you create your application with Discord, make sure that you have your `client_id` and `client_secret` handy. The next step is to figure out which OAuth2 flow is right for your purposes.
 
 ###### OAuth2 URLs
 
diff --git a/docs/topics/rpc.md b/docs/topics/rpc.md
@@ -40,7 +40,7 @@ For WebSocket connections, the connection is always `ws://127.0.0.1:PORT/?v=VERS
 - `PORT` is the port of the RPC Server.
 - `ENCODING` is the type of encoding for this connection to use. `json` and `etf` are supported.
 
-To begin, you'll need to create an app. Head to [your apps](#APPLICATIONS) and click the big plus button. When you create an app on our Developers site, you must specify an "RPC Origin" and "Redirect URI" from which to permit connections and authorizations. **The origin you send when connecting and the redirect uri you send when exchanging an authorization code for an access token must match one of the ones entered on the Developers site.**
+To begin, you'll need to create an app. Head to [your apps](https://discord.com/developers/applications) and click the big plus button. When you create an app on our Developers site, you must specify an "RPC Origin" and "Redirect URI" from which to permit connections and authorizations. **The origin you send when connecting and the redirect uri you send when exchanging an authorization code for an access token must match one of the ones entered on the Developers site.**
 
 When establishing a WebSocket connection, we verify the Origin header on connection to prevent client ID spoofing. You will be instantly disconnected if the Origin does not match.
 
diff --git a/docs/tutorials/developing-a-user-installable-app.mdx b/docs/tutorials/developing-a-user-installable-app.mdx
@@ -276,7 +276,7 @@ The keys in the object are the relevant installation context(s) (`GUILD_INSTALL`
 > info
 > `authorizing_integration_owners` is not the same as the user that triggered the interaction. Information about the user that triggered the interaction is in the `user` object.
 
-Understanding the authorization owner can be helpful when handling interactions from message components for apps installed to a user, which is discussed more in the [message component interactions](/docs/tutorials/developing-a-user-installable-app/using-metadata-for-message-component-interactions) section. Or you can find technical details in the [Authorizing Integration Owners](/docs/interactions/receiving-and-responding#interaction-object-authorizing-integration-owners-object) documentation.
+Understanding the authorization owner can be helpful when handling interactions from message components for apps installed to a user, which is discussed more in the [message component interactions](/docs/tutorials/developing-a-user-installable-app#using-metadata-for-message-component-interactions) section. Or you can find technical details in the [Authorizing Integration Owners](/docs/interactions/receiving-and-responding#interaction-object-authorizing-integration-owners-object) documentation.
 
 ###### `app_permissions`
 
diff --git a/docs/tutorials/upgrading-to-application-commands.md b/docs/tutorials/upgrading-to-application-commands.md
diff --git a/tools/checkLinks.ts b/tools/checkLinks.ts
