Convert 307 Redirects to Permanent in Docs (#751)

* fix: update email configuration link in recurring digests guide

Co-Authored-By: [email protected] <[email protected]>

* fix: update Concepts slug and convert integration redirects to permanent

Co-Authored-By: [email protected] <[email protected]>

* fix: revert SlackKit links to /in-app-ui/react/slack-kit and update Concepts references

Co-Authored-By: [email protected] <[email protected]>

* update concepts links

* update concepts links again

* point to overview page

* update integration links

* point to right concept pages

---------

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Co-authored-by: [email protected] <[email protected]>
Co-authored-by: Jeff Everhart <[email protected]>

content/concepts/channels.mdx

@@ -54,7 +54,7 @@ Some providers may require additional, per-recipient data to send notifications.
 
 In Knock, we refer to this concept as "Channel Data" as it represents the data that exists for a recipient on a particular channel.
 
-You can read more about [setting channel data here](/send-notifications/setting-channel-data). You can also see channel data requirements in the documentation for each provider.
+You can read more about [setting channel data here](/managing-recipients/setting-channel-data). You can also see channel data requirements in the documentation for each provider.
 
 ## Frequently asked questions
 

content/guides/alerting.mdx

@@ -104,7 +104,7 @@ Since there is no one-size-fits-all approach here, you’ll need to weigh these
   height={944}
 />
 
-The first step in creating an alerting system with Knock as the source of truth involves modeling your alert as an [Object](https://docs.knock.app/concepts/objects). Objects allow you to represent non-user recipients and create a relationship with users through subscriptions, which we’ll cover in the next step.
+The first step in creating an alerting system with Knock as the source of truth involves modeling your alert as an [Object](/concepts/objects). Objects allow you to represent non-user recipients and create a relationship with users through subscriptions, which we’ll cover in the next step.
 
 ```javascript title="Create an Object to represent the alert and config"
 const alert = await knock.objects.set("alert", alertId, {
@@ -114,11 +114,11 @@ const alert = await knock.objects.set("alert", alertId, {
 });
 ```
 
-Using custom properties, you can store additional information directly on the Object, like the `channels` that should be used in the alert, or the `events` that the alert is configured for. This allows you to encode the conditional logic of where and when a notification should send directly into Knock. Using the `batchWindow` property, you could even store [a custom window rule](https://docs.knock.app/designing-workflows/batch-function#set-a-dynamic-batch-window-using-a-variable) on the alert object to represent how it should batch notifications.
+Using custom properties, you can store additional information directly on the Object, like the `channels` that should be used in the alert, or the `events` that the alert is configured for. This allows you to encode the conditional logic of where and when a notification should send directly into Knock. Using the `batchWindow` property, you could even store [a custom window rule](/designing-workflows/batch-function#set-a-dynamic-batch-window-using-a-variable) on the alert object to represent how it should batch notifications.
 
 ### Subscribe Users to the alert
 
-Once you have an Object modeled to store your alert data, you can add individual recipient [subscriptions](https://docs.knock.app/concepts/subscriptions) to your alert object. This allows you to fan out to an unlimited number of recipients while still triggering a single workflow.
+Once you have an Object modeled to store your alert data, you can add individual recipient [subscriptions](/concepts/subscriptions) to your alert object. This allows you to fan out to an unlimited number of recipients while still triggering a single workflow.
 
 <Image
   className="rounded-md mx-auto border border-gray-200"
@@ -128,7 +128,7 @@ Once you have an Object modeled to store your alert data, you can add individual
   height={1336}
 />
 
-Subscriptions can also hold their [own unique properties](https://docs.knock.app/concepts/subscriptions#subscribing-recipients-to-an-object) that can be accessed during a workflow run. For example, users could select their own `channels`, `events`, or `batchWindow` if they wanted to and store them as properties of the subscription.
+Subscriptions can also hold their [own unique properties](/concepts/subscriptions#subscribing-recipients-to-an-object) that can be accessed during a workflow run. For example, users could select their own `channels`, `events`, or `batchWindow` if they wanted to and store them as properties of the subscription.
 
 ```javascript title="Subscribe a user to an alert Object"
 knock.objects.addSubscriptions("alerts", alertId, {
@@ -192,32 +192,32 @@ For our alert workflow, we find it’s best to have a single workflow that has a
 
 Since our application lets alerts subscribe to specific events, we’ll also want to ignore any events that the alert isn’t configured for.
 
-To do that, we can use a [Trigger Step Condition](https://docs.knock.app/designing-workflows/step-conditions#trigger-step-conditions) to evaluate if `data.alerts.events` contains `data.event`. If it does, then we can continue to the next step. If not, we can halt the workflow immediately.
+To do that, we can use a [Trigger Step Condition](/designing-workflows/step-conditions#trigger-step-conditions) to evaluate if `data.alerts.events` contains `data.event`. If it does, then we can continue to the next step. If not, we can halt the workflow immediately.
 
-Knock’s [conditions model](https://docs.knock.app/concepts/conditions) is very expressive, so it’s also possible to represent conditions other than basic string matching. For example, if you had an alert property like `usageThreshold` you could create a greater than comparison to a piece of data in the payload.
+Knock’s [conditions model](/concepts/conditions) is very expressive, so it’s also possible to represent conditions other than basic string matching. For example, if you had an alert property like `usageThreshold` you could create a greater than comparison to a piece of data in the payload.
 
 ### Deciding when to send notifications
 
-Next, we might want to either send notifications immediately or open a batch to catch multiple notifications of the same type. We can do that with [a branch step](https://docs.knock.app/designing-workflows/branch-function), where we examine whether or not there is a value for the batch window in `data.alert.batchWindow`. If there is, we’ll proceed to a batch step. If not, we’ll execute channel steps immediately.
+Next, we might want to either send notifications immediately or open a batch to catch multiple notifications of the same type. We can do that with [a branch step](/designing-workflows/branch-function), where we examine whether or not there is a value for the batch window in `data.alert.batchWindow`. If there is, we’ll proceed to a batch step. If not, we’ll execute channel steps immediately.
 
 ### Deciding how to batch notifications
 
-Let’s take a look at the batching example first. When using the batch function, Knock provides multiple ways to express when a batch window should close using [a dynamic batch window](https://docs.knock.app/designing-workflows/batch-function#set-a-dynamic-batch-window-using-a-variable). All batches are automatically created on a per-recipient basis, so in the case of a fan-out like we have here, a batch will be created for each recipient subscribed to the alert.
+Let’s take a look at the batching example first. When using the batch function, Knock provides multiple ways to express when a batch window should close using [a dynamic batch window](/designing-workflows/batch-function#set-a-dynamic-batch-window-using-a-variable). All batches are automatically created on a per-recipient basis, so in the case of a fan-out like we have here, a batch will be created for each recipient subscribed to the alert.
 
-You might also want to create a particular batch per event type. You can do that by using a [batch key](https://docs.knock.app/designing-workflows/batch-function#selecting-a-batch-key), which in this case could be `data.event`. As you trigger alerting events in your app, Knock will use this key to open a batch per-recipient and per-event.
+You might also want to create a particular batch per event type. You can do that by using a [batch key](/designing-workflows/batch-function#selecting-a-batch-key), which in this case could be `data.event`. As you trigger alerting events in your app, Knock will use this key to open a batch per-recipient and per-event.
 
 ### Deciding which channels to use
 
-Lastly, let’s look at how you would decide which channels to send notifications to. When you configured your `alert` you stored an array of `channels` on the Object. As the workflow processes each channel step you can use [a step condition](https://docs.knock.app/designing-workflows/step-conditions) to evaluate whether the current channel type exists in the array of configured channels: `data.alert.channels contains "sms"`.
+Lastly, let’s look at how you would decide which channels to send notifications to. When you configured your `alert` you stored an array of `channels` on the Object. As the workflow processes each channel step you can use [a step condition](/designing-workflows/step-conditions) to evaluate whether the current channel type exists in the array of configured channels: `data.alert.channels contains "sms"`.
 
 If that condition doesn’t evaluate to `true`, that particular channel step is skipped.
 
 ### Interacting with user preferences
 
-Up until now, much of the configuration on when and where to send notifications has existed in the `alert` object we created. But since users have [preferences](https://docs.knock.app/preferences/overview) as well, it’s possible that those preferences interact with some values configured in the `alert` itself. For example, even if the `alert` is configured to send email, if a user has opted out of the email channel, they will not get that notification.
+Up until now, much of the configuration on when and where to send notifications has existed in the `alert` object we created. But since users have [preferences](/preferences/overview) as well, it’s possible that those preferences interact with some values configured in the `alert` itself. For example, even if the `alert` is configured to send email, if a user has opted out of the email channel, they will not get that notification.
 
 There are a few ways to look at preferences in this context:
 
-1. Developers control [which preferences](https://docs.knock.app/preferences/overview#how-preferences-work) are exposed to the user, so it’s worth considering how you want to create a preference center and at what level of granularity you want users to be able to opt out. For example, you may just never want to expose global `channel_type` preference settings and instead expose `workflow` or `category` settings. In this case, just omitting a setting for your alerting workflow means users can’t opt out.
-2. Developers can always [override user preferences](https://docs.knock.app/preferences/overview#advanced-concepts) at the workflow level in the dashboard. Enabling this option means that every message sent from that particular workflow will override preferences set by the user.
-3. You can always [examine the preferences](https://docs.knock.app/preferences/overview#preference-evaluation-rules) Knock evaluates on a given recipient in the workflow debugger.
+1. Developers control [which preferences](/preferences/overview#how-preferences-work) are exposed to the user, so it’s worth considering how you want to create a preference center and at what level of granularity you want users to be able to opt out. For example, you may just never want to expose global `channel_type` preference settings and instead expose `workflow` or `category` settings. In this case, just omitting a setting for your alerting workflow means users can’t opt out.
+2. Developers can always [override user preferences](/preferences/overview#advanced-concepts) at the workflow level in the dashboard. Enabling this option means that every message sent from that particular workflow will override preferences set by the user.
+3. You can always [examine the preferences](/preferences/overview#preference-evaluation-rules) Knock evaluates on a given recipient in the workflow debugger.

content/guides/customer-webhooks.mdx

@@ -135,7 +135,7 @@ Since your customers won't have access to Knock, you can use the [Message delive
 
 ### Reporting on failed webhook deliveries
 
-You might want to provide a way to notify your customers that their webhooks are failing. You can do so by leveraging Knock’s [outbound webhooks](https://docs.knock.app/concepts/outbound-webhooks) features to create a webhook callback to your server that listens for `message.undelivered` events.
+You might want to provide a way to notify your customers that their webhooks are failing. You can do so by leveraging Knock’s [outbound webhooks](/developer-tools/outbound-webhooks/overview) features to create a webhook callback to your server that listens for `message.undelivered` events.
 
 ### Providing a dynamic signing key
 

content/guides/modeling-users-objects-and-tenants.mdx

@@ -28,7 +28,7 @@ Users in Knock are the most straightforward concept to explain in this guide bec
   alt="users modeled as users"
 />
 
-Users can have any number of custom properties associated with them, and [Knock reserves a number of optional properties](https://docs.knock.app/concepts/users#optional-attributes) like `email`, `name`, `phone_number`, `timezone`, and `avatar` that are used as defaults across different message delivery channels.
+Users can have any number of custom properties associated with them, and [Knock reserves a number of optional properties](/concepts/users#optional-attributes) like `email`, `name`, `phone_number`, `timezone`, and `avatar` that are used as defaults across different message delivery channels.
 
 ```javascript title="Example user modeled as an Knock User"
 {
@@ -46,7 +46,7 @@ You can sync these properties with Knock through a process called [identificatio
 
 ## Objects in Knock
 
-[Objects](https://docs.knock.app/concepts/objects) in Knock are a flexible abstraction that you can use to send notifications to non-user recipients. You can also represent relationships between these non-user recipients and users via [Subscriptions](https://docs.knock.app/concepts/subscriptions).
+[Objects](/concepts/objects) in Knock are a flexible abstraction that you can use to send notifications to non-user recipients. You can also represent relationships between these non-user recipients and users via [Subscriptions](/concepts/subscriptions).
 
 Let’s look at some non-user recipient use cases first.
 
@@ -191,7 +191,7 @@ In practice, that means the first workflow run using the `project` object can ge
 
 ## Tenants in Knock
 
-[Tenants](https://docs.knock.app/concepts/tenants) in Knock are a concept that allow you to segment your users and their messages. Most SaaS applications have some concept that is similar to “accounts,” “organizations,” “workspaces,” or “groups.” Under the hood, Tenants are a system-level Object collection called `$tenants`, so you can operate on them the same way you would an Object. You can set custom properties and subscribe users to them.
+[Tenants](/concepts/tenants) in Knock are a concept that allow you to segment your users and their messages. Most SaaS applications have some concept that is similar to “accounts,” “organizations,” “workspaces,” or “groups.” Under the hood, Tenants are a system-level Object collection called `$tenants`, so you can operate on them the same way you would an Object. You can set custom properties and subscribe users to them.
 
 In Collab.io, tenants are modeled as `workspaces`, which contain `projects` and `alerts`. You can create a corresponding Tenant in Knock using the same id that you use in your application:
 
@@ -218,6 +218,6 @@ await knock.workflows.trigger("new-comment", {
 });
 ```
 
-Tagging messages with a particular tenant can help you segment your notifications and [apply per-tenant branding and preferences.](https://docs.knock.app/concepts/tenants#guides-for-using-tenants)
+Tagging messages with a particular tenant can help you segment your notifications and [apply per-tenant branding and preferences.](/concepts/tenants#guides-for-using-tenants)
 
-Tenants are also useful for helping you [scope the in-app feed](https://docs.knock.app/concepts/tenants#scoping-in-app-feeds) to messages about a certain workspace or organization.
+Tenants are also useful for helping you [scope the in-app feed](/concepts/tenants#scoping-in-app-feeds) to messages about a certain workspace or organization.

content/in-app-ui/ios/overview.mdx

@@ -8,18 +8,18 @@ Our Swift SDK library lets you create notification experiences using Knock's API
 
 ## Getting started
 
-Please reference our iOS SDK [documentation](https://docs.knock.app/sdks/ios/quick-start) to set up the library.
+Please reference our iOS SDK [documentation](/sdks/ios/quick-start) to set up the library.
 
 ## Pre-built components
 
 The Knock iOS SDK ships the following pre-built UI elements:
 
 ### In-app notifications
 
-- [`InAppFeedView`](https://docs.knock.app/in-app-ui/ios/components#knockinappfeedview): A full-page list of notifications.
-- [`InAppFeedViewController`](https://docs.knock.app/in-app-ui/ios/components#knockinappfeedview): A wrapper for InAppFeedView to be used with UIKit.
-- [`InAppFeedViewModel`](https://docs.knock.app/in-app-ui/ios/components#knockinappfeedviewmodel): All of the logic needed to support your in-app feed. Can be used independently from `InAppFeedView` if you want to build your own UI.
-- [`InAppFeedNotificationIconButton`](https://docs.knock.app/in-app-ui/ios/components#inappfeednotificationiconbutton): For adding a bell icon to your application that shows the current count of unread or unseen notifications.
+- [`InAppFeedView`](/in-app-ui/ios/components#knockinappfeedview): A full-page list of notifications.
+- [`InAppFeedViewController`](/in-app-ui/ios/components#knockinappfeedview): A wrapper for InAppFeedView to be used with UIKit.
+- [`InAppFeedViewModel`](/in-app-ui/ios/components#knockinappfeedviewmodel): All of the logic needed to support your in-app feed. Can be used independently from `InAppFeedView` if you want to build your own UI.
+- [`InAppFeedNotificationIconButton`](/in-app-ui/ios/components#inappfeednotificationiconbutton): For adding a bell icon to your application that shows the current count of unread or unseen notifications.
 
 ## Links
 

content/in-app-ui/javascript/overview.mdx

@@ -10,7 +10,7 @@ section: Building in-app UI
     <>
       If you're looking to use pre-built in-app UI elements for a web
       application, you can look at{" "}
-      <a href="/in-app-ui/react">React components</a>.
+      <a href="/in-app-ui/react/overview">React components</a>.
     </>
   }
 />

content/in-app-ui/message-types.mdx

@@ -26,7 +26,7 @@ Knock comes with the following in-app messages types to use as message templates
 - Modal (`<Modal />` )
 - Card (`<Card />`)
 
-Once a template type exists, you can use it in the Knock in-app template editor:
+Once a template type exists, you can use it in the [Knock in-app template editor](/designing-workflows/template-editor/overview):
 
 ![In-app message types](/images/in-app-ui/message-types-template-editor.png)
 

content/in-app-ui/overview.mdx

@@ -22,7 +22,7 @@ Knock differs from other customer messaging platforms by separating the **conten
 
 In-app messages in Knock are generated when a workflow runs for a recipient. Those in-app messages are available via our client API, which your application uses to fetch messages and update their state (seen, read, interacted with, archived).
 
-In-app messages encode **content**, which is created using the Knock template editor as part of creating a workflow. You can read more on working with in-app message templates below.
+In-app messages encode **content**, which is created using the [Knock template editor](/designing-workflows/template-editor/overview) as part of creating a workflow. You can read more on working with in-app message templates below.
 
 The Knock in-app API also provides filtering capabilities to only return messages with a particular status (unread, read, seen etc) or custom property (sent as the data payload in the workflow trigger). You can also sort responses from the Knock in-app API by priority, for cases where you only want to display one in-app message to a user at a time. This makes it possible to build highly customized in-app experiences within your product