links fixed

fern/docs/pages/api-overview.mdx

@@ -15,7 +15,7 @@ Default: `https`
 </CodeBlock>
 
 <Callout intent="Security: API key">
-All the DevRev APIs require a token to authenticate the user. Provide `Authorization: <token>` as a header for every API request. [How do I find my token?](/welcome/authentication#generate-a-personal-access-token--pat-)
+All the DevRev APIs require a token to authenticate the user. Provide `Authorization: <token>` as a header for every API request. [How do I find my token?](/welcome/about-the-dev-rev-api/authentication)
 
 An API key is a token that you provide when making API calls. Include the token in a header parameter called Authorization.
 

fern/docs/pages/concepts.mdx

@@ -30,13 +30,13 @@ A connection uses a keyring object to provide authentication, access token refre
 
 ## Event source
 
-[Event sources](../snap-ins/references/event_sources) collect events from webhooks, emails, and timer-based API calls. Events can also be manually published. DevRev supports the ingestion of webhooks from any source. Each event source is assigned to a dev org.
+[Event sources](/welcome/snap-in-development/references/event-sources) collect events from webhooks, emails, and timer-based API calls. Events can also be manually published. DevRev supports the ingestion of webhooks from any source. Each event source is assigned to a dev org.
 
 For example, if you want to collect webhook events from an organization's GitHub, create an event source which in turn gives us a URL to subscribe to on GitHub. Webhook events published to this URL are available from this event source.
 
 ## Function
 
-The framework for executing code provided by users is [functions](../snap-ins/references/functions). Currently, Javascript/TypeScript can be taken as input from the user and deployed as a function.
+The framework for executing code provided by users is [functions](/welcome/snap-in-development/references/functions). Currently, Javascript/TypeScript can be taken as input from the user and deployed as a function.
 
 Connection values can be passed to a function at runtime, enabling it to execute API calls to DevRev and to external systems such as GitHub, Slack, Bitbucket, and Discord.
 
@@ -46,17 +46,17 @@ Snap-ins can be configured to enable and disable features, based on custom input
 
 ## Commands
 
-A user can trigger [commands](../snap-ins/references/commands) on different surfaces based on some parameters. Once a command is executed, a function is triggered.
+A user can trigger [commands](/welcome/snap-in-development/references/commands) on different surfaces based on some parameters. Once a command is executed, a function is triggered.
 
 A developer can develop commands to be included in a snap-in Version along with associated functions. These commands are installed when the snap-in is installed.
 
 As part of the snap-in, commands have access to keyrings, global variables, and event sources.
 
 ## Hooks
 
-[Hooks](../snap-ins/references/hooks) enable developers to invoke functions when various events in the lifecycle of a snap-in occur. Hooks can be used to perform various actions based on the event such as validating the snap-in inputs and keyrings when the configuration is updated, registering event-sources and webhooks in external platforms when snap-in is activated, or setting custom fields to be used by the snap-in.
+[Hooks](/welcome/snap-in-development/references/hooks) enable developers to invoke functions when various events in the lifecycle of a snap-in occur. Hooks can be used to perform various actions based on the event such as validating the snap-in inputs and keyrings when the configuration is updated, registering event-sources and webhooks in external platforms when snap-in is activated, or setting custom fields to be used by the snap-in.
 
-Detailed documentation on hooks can be found in the [hooks reference](./references/hooks.mdx).
+Detailed documentation on hooks can be found in the [hooks reference](/welcome/snap-in-development/references/hooks).
 
 ## States
 
@@ -78,7 +78,7 @@ The following diagram illustrates the transitions between different states.
 
 ## Snap-kit
 
-[Snap-kit](../snap-ins/references/snapkit) defines UI customization components. It's defined in the snap-in package and used to display developer-defined components. A snap-kit component can display data to a user or collect input for triggering a function.
+[Snap-kit](/welcome/snap-in-development/references/snapkit) defines UI customization components. It's defined in the snap-in package and used to display developer-defined components. A snap-kit component can display data to a user or collect input for triggering a function.
 
 ## Marketplace
 

fern/docs/pages/developer-intro.mdx

@@ -2,16 +2,16 @@
 
 If you are new to DevRev, we would recommend learning about our [core concepts](https://docs.devrev.ai/intro) before getting started.
 
-Once you have a DevRev account, you can access the APIs with a [personal access token](./authentication) (PAT) that you create in the DevRev app.
+Once you have a DevRev account, you can access the APIs with a [personal access token](/welcome/about-the-dev-rev-api/authentication) (PAT) that you create in the DevRev app.
 
-A brief [tutorial](./welcome) shows you how to access the APIs.
+A brief [tutorial](/welcome/getting-started) shows you how to access the APIs.
 
 ## 🧬 Methods
 
-Specifications covering the supported APIs are based on OpenAPI Specification 3.0. You can download the specs to use an OpenAPI 3.0-compliant tool to perform a variety of actions, including rendering them in UI and generating SDKs. Two [versions](./versioning) of the DevRev API are available: [public](https://devrev.ai/docs/apis/methods) and [early access/beta](https://devrev.ai/docs/apis/beta-api-spec). Descriptions of the public [entities](./entities) are available.
+Specifications covering the supported APIs are based on OpenAPI Specification 3.0. You can download the specs to use an OpenAPI 3.0-compliant tool to perform a variety of actions, including rendering them in UI and generating SDKs. Two [versions](/welcome/about-the-dev-rev-api/versioning) of the DevRev API are available: [public](https://devrev.ai/docs/apis/methods) and [early access/beta](https://devrev.ai/docs/apis/beta-api-spec). Descriptions of the public [entities](/welcome/about-the-dev-rev-api/entities) are available.
 
-To take action based on events from the DevRev platform, [webhooks](./webhooks) are also supported. 
+To take action based on events from the DevRev platform, [webhooks](/welcome/getting-started-with-webhooks) are also supported. 
 
 ## 🧩 Snap-ins
 
-Numerous snap-ins are available on the DevRev [Marketplace](https://devrev.ai/marketplace). The [snap-in framework](./snapin-concepts) is available for you to create your own snap-ins for automation of DevRev workflows or integration with other system.
+Numerous snap-ins are available on the DevRev [Marketplace](https://devrev.ai/marketplace). The [snap-in framework](/welcome/snap-in-development/concepts) is available for you to create your own snap-ins for automation of DevRev workflows or integration with other system.

fern/docs/pages/entities.mdx

@@ -19,7 +19,7 @@ Security tokens are required for accessing DevRev. There are four types of secur
 - **Personal Access Token (PAT)**: Uniquely identifies a dev user.
 - **Session Token**: Obtained by an application to access DevRev APIs on behalf of a customer (or customer).
 
-For more information about security tokens, refer to [Authentication](/welcome/authentication).
+For more information about security tokens, refer to [Authentication](/welcome/about-the-dev-rev-api/authentication).
 
 ## Product builders: `dev-users`
 
@@ -47,7 +47,7 @@ Work items DevRev objects have a timeline that contains discussions and events.
 
 Webhooks enable building custom workflows in response to events on the DevRev platform. A webhook can be thought of as a 'reverse API' that's driven by events rather than requests. While APIs are used to pull data from the system, webhooks are a mechanism for the system to push data to a pre-configured endpoint. Webhooks allow you to receive notifications based on events without having to explicitly make a request.
 
-For more information about webhooks, refer to [Getting started with webhooks](./webhooks).
+For more information about webhooks, refer to [Getting started with webhooks](/welcome/getting-started-with-webhooks).
 
 ## Tickets and issues: `works`
 

fern/docs/pages/publish_to_marketplace.mdx

@@ -24,21 +24,21 @@ Any item in marketplace listings that's available for installation.
 
 Marketplace listing refers to all the marketplace items that belong to the same marketplace and have the same slug. It's also important to note that at most one marketplace item, belonging to a specific marketplace listing, can be in the _Published_ state.
 
-![marketplace listing](/img/marketplace_listing.png)
+![marketplace_listing](https://github.com/devrev/fern-api-docs/assets/74637789/fb0b82c7-99ae-492c-935a-69b62648097a)
 
 ## Publishing process
 
 The publishing process commences by initiating a marketplace submission, which entails requesting the creation of a new marketplace listing or updating an existing one. The submission is created by the marketplace publisher and subsequently reviewed by the marketplace admin. Once the submission is prepared for review, the publisher must transition it to the "waiting for review" state. During this phase, the marketplace admin conducts a review and decides whether to approve or reject the submission. If the submission is approved, the marketplace publisher can proceed to publish it. However, if the submission is rejected, the publisher has the option to make updates and resubmit it for another round of review.
 
-![life cycle](/img/lifecycle.png)
+![lifecycle](https://github.com/devrev/fern-api-docs/assets/74637789/d46e0c84-7331-4ce0-8fd4-19399bc77812)
 
 ## Get started
 
-To get started with publishing marketplace item, you need DevRev CLI. Refer to [DevRev CLI Cheatsheet](references/cli) for more information.
+To get started with publishing marketplace item, you need DevRev CLI. Refer to [DevRev CLI Cheatsheet](/welcome/snap-in-development/references/install-dev-rev-cli) for more information.
 
 ### Create a snap-in
 
-To proceed with making a submission in marketplace, you need a snap-in for which you are creating this submission. If you are new to snap-ins, [follow the development and deployment guide](../snap-ins/start) to create your first snap-in.
+To proceed with making a submission in marketplace, you need a snap-in for which you are creating this submission. If you are new to snap-ins, [follow the development and deployment guide](/welcome/snap-in-development/tutorials/overview) to create your first snap-in.
 
 ## Create marketplace listing
 

fern/docs/pages/references/event_sources.mdx

@@ -171,10 +171,10 @@ In `function_2`, you can use the payload of the scheduled event as follows:
 ```
 
 <Callout intent="info">
-The `/event-sources.schedule` API is currently in early access. For API details, see [event-sources-schedule-event](https://devrev.ai/docs/apis/beta-api-spec#/operations/event-sources-schedule-event).
+The `/event-sources.schedule` API is currently in early access. For API details, see [event-sources-schedule-event](/beta/dev-rev-rest-api/api-reference/event-source/event-sources-schedule-event).
 </Callout>
 
-To cancel scheduled events, you can utilize the `/event-sources.unschedule` API. For API details, see [event-sources-delete-scheduled-event](https://devrev.ai/docs/apis/beta-api-spec#/operations/event-sources-delete-scheduled-event).
+To cancel scheduled events, you can utilize the `/event-sources.unschedule` API. For API details, see [event-sources-delete-scheduled-event](/beta/dev-rev-rest-api/api-reference/event-source/event-sources-delete-scheduled-event).
 
 ## Generic event sources
 

fern/docs/pages/references/functions.mdx

@@ -1,6 +1,6 @@
 Using functions, you can provide custom code and link it to your event sources, automations, or snap-kit actions. Functions are written in JavaScript and can be used to transform events, send notifications, or perform any other custom logic including network calls.
 
-In order to create a snap-in version, functions must be defined as shown in the [code samples](../examples/samples). Functions are packaged and provided as an artifact at the time of snap-in version creation and then used to deploy functions to snap-in versions. An artifact may contain multiple function definitions. The artifact is a zip file containing the following files:
+In order to create a snap-in version, functions must be defined as shown in the [code samples](/welcome/snap-in-development/code-samples). Functions are packaged and provided as an artifact at the time of snap-in version creation and then used to deploy functions to snap-in versions. An artifact may contain multiple function definitions. The artifact is a zip file containing the following files:
 
 ```bash
 /
@@ -26,4 +26,4 @@ functions:
 - `name`: It is the function name that should match the corresponding function name in the folder.
 - `description`: It describes the function.
 
-Refer to the [function invocation](./function_invocation) for details about the exact payload of the function.
+Refer to the [function invocation](/welcome/snap-in-development/references/function-invocation) for details about the exact payload of the function.

fern/docs/pages/references/hooks.mdx

@@ -18,9 +18,9 @@ hooks:
     function: update-resource
 ```
 
-The above definition would register the hooks and invoke the provided functions alongside each hook. The functions can be defined in the manifest and provided in the code as explained in the [functions reference](./functions).
+The above definition would register the hooks and invoke the provided functions alongside each hook. The functions can be defined in the manifest and provided in the code as explained in the [functions reference](/welcome/snap-in-development/references/functions).
 
-For the event schema received by the function invocation, refer to the [function invocation reference](./function_invocation).
+For the event schema received by the function invocation, refer to the [function invocation reference](/welcome/snap-in-development/references/function-invocation).
 
 The event name is the identifier for the hook. The event name can be used to identify the hook that's being invoked. The identifiers are defined in the summary table below.
 

fern/docs/pages/references/manifest.mdx

@@ -1,5 +1,5 @@
 <Callout intent="info">
-The following section is for version 2 of the manifest specification. For the previous version, see [Manifest V1](v1-manifest).
+The following section is for version 2 of the manifest specification. For the previous version, see [Manifest V1](/welcome/snap-in-development/references/snap-in-v-1-manifest).
 </Callout>
 
 The snap-in manifest is what the developers write to define a snap-in. The manifest has the following sections:
@@ -61,7 +61,7 @@ Keyrings defined in the manifest can be provided in the snap-in configuration sc
 
 Organization keyrings are common to the organization, while user keyrings are set per user. User keyrings are optional, so the developer must correctly handle cases where the keyring isn't found.
 
-To view the supported connection types, see [Keyrings](./keyrings).
+To view the supported connection types, see [Keyrings](/welcome/snap-in-development/references/keyrings).
 
 ## Developer keyrings
 
@@ -143,7 +143,7 @@ Event sources can be categorized as "organization" level and "user" level. Event
 
 ```
 
-Refer to [Event sources](./event_sources) for a checklist of supported event sources and their corresponding event types.
+Refer to [Event sources](/welcome/snap-in-development/references/event-sources) for a checklist of supported event sources and their corresponding event types.
 
 Refer to the [webhook-event-request docs](https://devrev.ai/docs/apis/methods#/schemas/webhook-event-request) for a list of supported webhooks.
 

fern/docs/pages/references/v1-manifest.mdx

@@ -1,5 +1,5 @@
 <Callout intent="info">
-The following guide is for the version 1 of the manifest spec. For the latest version, refer to [Manifest](./manifest).
+The following guide is for the version 1 of the manifest spec. For the latest version, refer to [Manifest](/welcome/snap-in-development/references/snap-in-manifest).
 </Callout>
 
 The snap-in manifest is what the developers write to define a snap-in. The manifest has the following sections:
@@ -40,7 +40,7 @@ connections:
       - devrev-github-oauth
 ```
 
-Service that stores these secrets and has the business logic to refresh tokens, when applicable. Here is the list of currently supported connection types - [Connections](./keyrings)
+Service that stores these secrets and has the business logic to refresh tokens, when applicable. Here is the list of currently supported connection types - [Connections](/welcome/snap-in-development/references/keyrings)
 
 ## Developer connections
 
@@ -106,7 +106,7 @@ Event sources are specified in the manifest with the following syntax:
         type: <enum specifying what type of the source should be created>
 ```
 
-Here is the [list of supported event sources](./event_sources).
+Here is the [list of supported event sources](/welcome/snap-in-development/references/event-sources).
 
 Refer to [webhook-event-request docs](https://devrev.ai/docs/apis/methods#/schemas/webhook-event-request) for the list of supported webhooks.