diff --git a/docs/api/utility-apis.md b/docs/api/utility-apis.md
index 3e60124775..8d882227ec 100644
--- a/docs/api/utility-apis.md
+++ b/docs/api/utility-apis.md
@@ -10,31 +10,31 @@ Backstage plugins strive to be self-contained, with as much functionality as pos
 
 Backstage provides two primary methods for plugins to communicate across their
 boundaries in client-side code. The first one being the
-[`createPlugin`](../reference/core-plugin-api.createplugin.md) API along with the
+[`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) API along with the
 extensions that it can provide, and the second one being Utility APIs. While the
-[`createPlugin`](../reference/core-plugin-api.createplugin.md) API is focused on
+[`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) API is focused on
 the initialization plugins and the app, the Utility APIs provide ways for
 plugins to communicate during their entire life cycle.
 
 ## Consuming APIs
 
-Each Utility API is tied to an [`ApiRef`](../reference/frontend-plugin-api.apiref.md)
+Each Utility API is tied to an [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)
 instance, which is a global singleton object without any additional state or
 functionality, its only purpose is to reference Utility APIs.
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md)s are created using
-[`createApiRef`](../reference/frontend-plugin-api.createapiref.md), which is exported
-by [`@backstage/core-plugin-api`](../reference/core-plugin-api.md). There are also
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)s are created using
+[`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html), which is exported
+by [`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). There are also
 many predefined Utility APIs in
-[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), and they're all
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), and they're all
 exported with a name of the pattern `*ApiRef`, for example
-[`errorApiRef`](../reference/frontend-plugin-api.errorapiref.md).
+[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html).
 
 To access one of the Utility APIs inside a React component, use the
-[`useApi`](../reference/frontend-plugin-api.useapi.md) hook exported by
-[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), or the
-[`withApis`](../reference/frontend-plugin-api.withapis.md) HOC if you prefer class
+[`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) hook exported by
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), or the
+[`withApis`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.withApis.html) HOC if you prefer class
 components. For example, the
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md) can be accessed like this:
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html) can be accessed like this:
 
 ```tsx
 import { useApi, errorApiRef } from '@backstage/core-plugin-api';
@@ -52,14 +52,14 @@ export const MyComponent = () => {
 ```
 
 Note that there is no explicit type given for
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md). This is because the
-[`errorApiRef`](../reference/frontend-plugin-api.errorapiref.md) has the type
-embedded, and [`useApi`](../reference/frontend-plugin-api.useapi.md) is able to infer
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html). This is because the
+[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) has the type
+embedded, and [`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) is able to infer
 the type.
 
 Also note that consuming Utility APIs is not limited to plugins; it can be done
 from any component inside Backstage, including the ones in
-[`@backstage/core-plugin-api`](../reference/core-plugin-api.md). The only
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). The only
 requirement is that they are beneath the `AppProvider` in the react tree.
 
 ## Supplying APIs
@@ -67,15 +67,15 @@ requirement is that they are beneath the `AppProvider` in the react tree.
 ### API Factories
 
 APIs are registered in the form of
-[`ApiFactory`](../reference/frontend-plugin-api.apifactory.md) instances, which encapsulate
+[`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) instances, which encapsulate
 the process of instantiating an API. It is a collection of three things: the
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md) of the API to instantiate, a
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) of the API to instantiate, a
 list of all required dependencies, and a factory function that returns a new API
 instance.
 
 For example, this is the default
-[`ApiFactory`](../reference/frontend-plugin-api.apifactory.md) for the
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md):
+[`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) for the
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html):
 
 ```ts
 createApiFactory({
@@ -89,25 +89,25 @@ createApiFactory({
 });
 ```
 
-In this example, the [`errorApiRef`](../reference/frontend-plugin-api.errorapiref.md)
+In this example, the [`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html)
 is our API, which encapsulates the
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md) type. The
-[`alertApiRef`](../reference/frontend-plugin-api.alertapiref.md) is our single
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html) type. The
+[`alertApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.alertApiRef.html) is our single
 dependency, which we give the name `alertApi`, and is then passed on to the
 factory function, which returns an implementation of the
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md).
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html).
 
-The [`createApiFactory`](../reference/frontend-plugin-api.createapifactory.md)
+The [`createApiFactory`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiFactory.html)
 function is a thin wrapper that enables TypeScript type inference. You may
 notice that there are no type annotations in the above example, and that is
 because we're able to infer all types from the
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md)s. TypeScript will make sure
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)s. TypeScript will make sure
 that the return value of the `factory` function matches the type embedded in
-`api`'s [`ApiRef`](../reference/frontend-plugin-api.apiref.md), in this case the
-[`ErrorApi`](../reference/frontend-plugin-api.errorapi.md). It will also match the
+`api`'s [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), in this case the
+[`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html). It will also match the
 types between the `deps` and the parameters of the `factory` function, again
 using the type embedded within the
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md)s.
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)s.
 
 ## Registering API Factories
 
@@ -119,13 +119,13 @@ app, and the app itself.
 
 Starting with the Backstage core library, it provides implementations for all of
 the core APIs. The core APIs are the ones exported by
-[`@backstage/core-plugin-api`](../reference/core-plugin-api.md), such as the
-[`errorApiRef`](../reference/frontend-plugin-api.errorapiref.md) and
-[`configApiRef`](../reference/frontend-plugin-api.configapiref.md).
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), such as the
+[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) and
+[`configApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.configApiRef.html).
 
 The core APIs are loaded for any app created with
-[`createApp`](../reference/app-defaults.createapp.md) from
-[`@backstage/core-plugin-api`](../reference/app-defaults.md), which means that
+[`createApp`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html) from
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html), which means that
 there is no step that needs to be taken to include these APIs in an app.
 
 ### Plugin APIs
@@ -133,13 +133,13 @@ there is no step that needs to be taken to include these APIs in an app.
 In addition to the core APIs, plugins can define and export their own APIs.
 While doing so, they should usually also provide default implementations of their
 own APIs; for example, the `catalog` plugin exports `catalogApiRef` and also
-supplies a default [`ApiFactory`](../reference/frontend-plugin-api.apifactory.md) of
+supplies a default [`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) of
 that API using the `CatalogClient`. There is one restriction to plugin-provided
 API Factories: plugins may not supply factories for core APIs; trying to do so
 will cause the app to refuse to start.
 
 Plugins supply their APIs through the `apis` option of
-[`createPlugin`](../reference/core-plugin-api.createplugin.md), for example:
+[`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html), for example:
 
 ```ts
 export const techdocsPlugin = createPlugin({
@@ -164,7 +164,7 @@ Lastly, the app itself is the final point where APIs can be added, and what has
 the final say in what APIs will be loaded at runtime? The app may override the
 factories for any of the core or plugin APIs, with the exception of the config,
 app theme, and identity APIs. These are static APIs that are tied into the
-[`createApp`](../reference/app-defaults.createapp.md) implementation and
+[`createApp`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html) implementation and
 therefore, not possible to override.
 
 Overriding APIs is useful for apps that want to switch out behavior to tailor it
@@ -227,33 +227,33 @@ const app = createApp({
 ```
 
 Note that the above line will cause an error if `IgnoreErrorApi` does not fully
-implement the [`ErrorApi`](../reference/frontend-plugin-api.errorapi.md), as it is
+implement the [`ErrorApi`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ErrorApi.html), as it is
 checked by the type embedded in the
-[`errorApiRef`](../reference/frontend-plugin-api.errorapiref.md) at compile time.
+[`errorApiRef`](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.errorApiRef.html) at compile time.
 
 ## Defining custom Utility APIs
 
 Plugins are free to define their own Utility APIs. Simply define the TypeScript
 interface for the API and create an
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md) using
-[`createApiRef`](../reference/frontend-plugin-api.createapiref.md) exported from
-[`@backstage/core-plugin-api`](../reference/core-plugin-api.md). Also, be sure to
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) using
+[`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html) exported from
+[`@backstage/core-plugin-api`](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.html). Also, be sure to
 provide at least one implementation of the API and to declare a default factory
-for the API in [`createPlugin`](../reference/core-plugin-api.createplugin.md).
+for the API in [`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html).
 
 Custom Utility APIs can be either public or private, which is up to the plugin to choose. Private APIs do not expose an external API surface, and it's therefore possible to make breaking changes to the API without affecting other users of the plugin. If an API is made public, however, it opens up for other plugins to make use of the API, and it also makes it possible for users for your plugin to override the API in the app. It is, however, important to maintain backward compatibility of public APIs, as you may otherwise break apps that are using your plugin.
 
 To make an API public, simply export the
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md) of the API, and any associated
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) of the API, and any associated
 types. To make an API private, just avoid exporting the
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md), but still be sure to supply a
-default factory to [`createPlugin`](../reference/core-plugin-api.createplugin.md).
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), but still be sure to supply a
+default factory to [`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html).
 
 Private APIs are useful for plugins that want to depend on other APIs outside of
 React components, but not have to expose an entire API surface to maintain. When
 using private APIs, it is fine to use the `typeof` of an implementing class as
 the type parameter passed to
-[`createApiRef`](../reference/frontend-plugin-api.createapiref.md), while public APIs
+[`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html), while public APIs
 should always define a separate TypeScript interface type.
 
 Plugins may depend on APIs from other plugins, both in React components and as
@@ -262,13 +262,13 @@ dependencies between plugins.
 
 ## Architecture
 
-The [`ApiRef`](../reference/frontend-plugin-api.apiref.md) instances mentioned above
+The [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html) instances mentioned above
 provide a point of indirection between consumers and producers of Utility APIs.
 It allows for plugins and components to depend on APIs in a type-safe way,
 without having a direct reference to a concrete implementation of the APIs. The
 Apps are also given a lot of flexibility in what implementations to provide. As
 long as they adhere to the contract established by an
-[`ApiRef`](../reference/frontend-plugin-api.apiref.md), they are free to choose any
+[`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html), they are free to choose any
 implementation they want.
 
 The figure below shows the relationship between
@@ -291,16 +291,16 @@ The indirection provided by Utility APIs also makes it straightforward to test
 components that depend on APIs, and to provide a standard common development
 environment for plugins. A proper test wrapper with mocked API implementations
 is not yet ready, but it will be provided as a part of
-[`@backstage/test-utils`](../reference/test-utils.md). It will provide mocked
+[`@backstage/test-utils`](https://backstage.io/api/stable/modules/_backstage_test-utils.html). It will provide mocked
 variants of APIs, with additional methods for asserting a component's
 interaction with the API.
 
 The common development environment for plugins is included in
-[`@backstage/dev-utils`](../reference/dev-utils.md), where the exported
-[`createDevApp`](../reference/dev-utils.createdevapp.md) function creates an
+[`@backstage/dev-utils`](https://backstage.io/api/stable/modules/_backstage_dev-utils.html), where the exported
+[`createDevApp`](https://backstage.io/api/stable/functions/_backstage_dev-utils.createDevApp.html) function creates an
 application with implementations for all core APIs already present. Contrary to
 the method for wiring up Utility API implementations in an app created with
-[`createApp`](../reference/app-defaults.createapp.md),
-[`createDevApp`](../reference/dev-utils.createdevapp.md) uses automatic dependency
+[`createApp`](https://backstage.io/api/stable/functions/_backstage_app-defaults.createApp.html),
+[`createDevApp`](https://backstage.io/api/stable/functions/_backstage_dev-utils.createDevApp.html) uses automatic dependency
 injection. This is to make it possible to replace any API implementation, and
 having that be reflected in dependents of that API.
diff --git a/docs/auth/index.md b/docs/auth/index.md
index a3141d0434..1d668f6961 100644
--- a/docs/auth/index.md
+++ b/docs/auth/index.md
@@ -340,7 +340,7 @@ The method with which frontend plugins request access to third-party services is
 through [Utility APIs](../api/utility-apis.md) for each service provider. These
 are all suffixed with `*AuthApiRef`, for example `githubAuthApiRef`. For a
 full list of providers, see the
-[@backstage/core-plugin-api](../reference/core-plugin-api.md#variables) reference.
+[@backstage/core-plugin-api](https://backstage.io/api/stable/modules/_backstage_core-plugin-api.index.html#alertapiref) reference.
 
 ## Custom Authentication Provider
 
diff --git a/docs/conf/reading.md b/docs/conf/reading.md
index a565f3a8a3..b6119b0da9 100644
--- a/docs/conf/reading.md
+++ b/docs/conf/reading.md
@@ -7,7 +7,7 @@ description: Documentation on Reading Backstage Configuration
 ## Config API
 
 There's a common configuration API for by both frontend and backend plugins. An
-API reference can be found [here](../reference/config.config.md).
+API reference can be found [here](https://backstage.io/api/stable/types/_backstage_config.Config.html).
 
 The configuration API is tailored towards failing fast in case of missing or bad
 config. That's because configuration errors can always be considered programming
@@ -115,7 +115,7 @@ example `getString`. These will throw an error if there is no value available.
 
 ## Accessing ConfigApi in Frontend Plugins
 
-The [ConfigApi](../reference/frontend-plugin-api.configapi.md) in the frontend is a
+The [ConfigApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ConfigApi.html) in the frontend is a
 [UtilityApi](../api/utility-apis.md). It's accessible as usual via the
 `configApiRef` exported from `@backstage/core-plugin-api`:
 
diff --git a/docs/deployment/scaling.md b/docs/deployment/scaling.md
index 2c3b687f67..dd765d3c1a 100644
--- a/docs/deployment/scaling.md
+++ b/docs/deployment/scaling.md
@@ -17,7 +17,7 @@ into multiple different services, each running a different set of plugins. This
 is a more advanced approach and requires you to be able to route requests to
 the appropriate backends based on the plugin ID. Both for ingress, but also
 internal traffic between Backstage backends, which is done by creating a custom
-implementation of the [DiscoveryService](../reference/backend-plugin-api.discoveryservice.md) interface. See the [backend system docs](../backend-system/building-backends/01-index.md#split-into-multiple-backends) for more details on how to separate your deployment into multiple backend instances.
+implementation of the [DiscoveryService](https://backstage.io/api/stable/interfaces/_backstage_backend-plugin-api.index.DiscoveryService.html) interface. See the [backend system docs](../backend-system/building-backends/01-index.md#split-into-multiple-backends) for more details on how to separate your deployment into multiple backend instances.
 
 Lastly, you can also replicate the Backstage deployments across multiple regions.
 This is not a pattern that there is built-in support for and typically only makes
diff --git a/docs/frontend-system/building-plugins/01-index.md b/docs/frontend-system/building-plugins/01-index.md
index 283c162fa7..fd88478b37 100644
--- a/docs/frontend-system/building-plugins/01-index.md
+++ b/docs/frontend-system/building-plugins/01-index.md
@@ -220,6 +220,6 @@ export const examplePlugin = createFrontendPlugin({
 });
 ```
 
-The `ExampleEntityContent` itself is again a regular React component where you can implement any functionality you want. To access the entity that the content is being rendered for, you can use the `useEntity` hook from `@backstage/plugin-catalog-react`. You can see a full list of APIs provided by the catalog React library in [the API reference](../../reference/plugin-catalog-react.md).
+The `ExampleEntityContent` itself is again a regular React component where you can implement any functionality you want. To access the entity that the content is being rendered for, you can use the `useEntity` hook from `@backstage/plugin-catalog-react`. You can see a full list of APIs provided by the catalog React library in [the API reference](https://backstage.io/api/stable/modules/_backstage_plugin-catalog-react.index.html).
 
 For a more complete list of the different kinds of extensions that you can create for your plugin, see the [extension blueprints](./03-common-extension-blueprints.md) section.
diff --git a/docs/frontend-system/building-plugins/03-common-extension-blueprints.md b/docs/frontend-system/building-plugins/03-common-extension-blueprints.md
index 71989e898f..abac1f03f5 100644
--- a/docs/frontend-system/building-plugins/03-common-extension-blueprints.md
+++ b/docs/frontend-system/building-plugins/03-common-extension-blueprints.md
@@ -11,35 +11,35 @@ This section covers many of the [extension blueprints](../architecture/23-extens
 
 These are the [extension blueprints](../architecture/23-extension-blueprints.md) provided by the Backstage frontend framework itself.
 
-### Api - [Reference](../../reference/frontend-plugin-api.apiblueprint.md)
+### Api - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.ApiBlueprint.html)
 
 An API extension is used to add or override [Utility API factories](../utility-apis/01-index.md) in the app. They are commonly used by plugins for both internal and shared APIs. There are also many built-in Api extensions provided by the framework that you are able to override.
 
-### NavItem - [Reference](../../reference/frontend-plugin-api.navitemblueprint.md)
+### NavItem - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.NavItemBlueprint.html)
 
 Navigation item extensions are used to provide menu items that link to different parts of the app. By default nav items are attached to the app nav extension, which by default is rendered as the left sidebar in the app.
 
-### Page - [Reference](../../reference/frontend-plugin-api.pageblueprint.md)
+### Page - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.PageBlueprint.html)
 
 Page extensions provide content for a particular route in the app. By default pages are attached to the app routes extensions, which renders the root routes.
 
-### SignInPage - [Reference](../../reference/frontend-plugin-api.signinpageblueprint.md)
+### SignInPage - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.SignInPageBlueprint.html)
 
 Sign-in page extension have a single purpose - to implement a custom sign-in page. They are always attached to the app root extension and are rendered before the rest of the app until the user is signed in.
 
-### SwappableComponent - [Reference](../../reference/frontend-plugin-api.swappablecomponentblueprint.md)
+### SwappableComponent - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.SwappableComponentBlueprint.html)
 
 Swappable Components are extensions that are used to replace the implementations of components in the app and plugins.
 
-### Theme - [Reference](../../reference/frontend-plugin-api.themeblueprint.md)
+### Theme - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.ThemeBlueprint.html)
 
 Theme extensions provide custom themes for the app. They are always attached to the app extension and you can have any number of themes extensions installed in an app at once, letting the user choose which theme to use.
 
-### Icons - [Reference](../../reference/frontend-plugin-api.iconbundleblueprint.md)
+### Icons - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.IconBundleBlueprint.html)
 
 Icon bundle extensions provide the ability to replace or provide new icons to the app. You can use the above blueprint to make new extension instances which can be installed into the app.
 
-### Translation - [Reference](../../reference/frontend-plugin-api.translationblueprint.md)
+### Translation - [Reference](https://backstage.io/api/stable/variables/_backstage_frontend-plugin-api.TranslationBlueprint.html)
 
 Translation extension provide custom translation messages for the app. They can be used both to override the default english messages to custom ones, as well as provide translations for additional languages.
 
diff --git a/docs/plugins/integrating-plugin-into-software-catalog.md b/docs/plugins/integrating-plugin-into-software-catalog.md
index ed2e25c601..3542e073cb 100644
--- a/docs/plugins/integrating-plugin-into-software-catalog.md
+++ b/docs/plugins/integrating-plugin-into-software-catalog.md
@@ -32,7 +32,7 @@ Creating the plugin...
 ### Reading entities from within your plugin
 
 You can access the currently selected entity using the backstage api
-[`useEntity`](../reference/plugin-catalog-react.useentity.md). For example,
+[`useEntity`](https://backstage.io/api/stable/functions/_backstage_plugin-catalog-react.index.useEntity.html). For example,
 
 ```tsx
 import { useEntity } from '@backstage/plugin-catalog-react';
diff --git a/docs/plugins/structure-of-a-plugin.md b/docs/plugins/structure-of-a-plugin.md
index 8412ead179..7cfaca4561 100644
--- a/docs/plugins/structure-of-a-plugin.md
+++ b/docs/plugins/structure-of-a-plugin.md
@@ -82,7 +82,7 @@ export const ExamplePage = examplePlugin.provide(
 
 This is where the plugin is created and where it creates and exports extensions
 that can be imported and used in the app. See reference docs for
-[`createPlugin`](../reference/core-plugin-api.createplugin.md) or introduction to
+[`createPlugin`](https://backstage.io/api/stable/functions/_backstage_core-plugin-api.index.createPlugin.html) or introduction to
 the new [Composability System](./composability.md).
 
 ## Components
diff --git a/docs/tutorials/using-backstage-proxy-within-plugin.md b/docs/tutorials/using-backstage-proxy-within-plugin.md
index 237a7207a1..bb416bf731 100644
--- a/docs/tutorials/using-backstage-proxy-within-plugin.md
+++ b/docs/tutorials/using-backstage-proxy-within-plugin.md
@@ -94,15 +94,15 @@ export const AwesomeUsersTable = () => {
 
 This section describes the steps to wrap your API client in a [Utility API](../api/utility-apis.md), which are:
 
-- use [`createApiRef`](../reference/frontend-plugin-api.createapiref.md) to create a
-  new [`ApiRef`](../reference/frontend-plugin-api.apiref.md)
-- register an [`ApiFactory`](../reference/frontend-plugin-api.apifactory.md) with
+- use [`createApiRef`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiRef.html) to create a
+  new [`ApiRef`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiRef.html)
+- register an [`ApiFactory`](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.ApiFactory.html) with
   your plugin using
-  [`createApiFactory`](../reference/frontend-plugin-api.createapifactory.md). This
+  [`createApiFactory`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.createApiFactory.html). This
   will wrap your API implementation, associate your `ApiRef` with your
   implementation and tell backstage how to instantiate it
 - finally, you can use your API in your components by calling
-  [`useApi`](../reference/frontend-plugin-api.useapi.md)
+  [`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html)
 
 ### Defining the API client interface
 
@@ -187,8 +187,8 @@ export class MyAwesomeApiClient implements MyAwesomeApi {
 ```
 
 > Check out the docs for more information on the
-> [DiscoveryApi](../reference/frontend-plugin-api.discoveryapi.md) or the
-> [FetchApi](../reference/frontend-plugin-api.fetchapi.md)
+> [DiscoveryApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.DiscoveryApi.html) or the
+> [FetchApi](https://backstage.io/api/stable/types/_backstage_frontend-plugin-api.FetchApi.html)
 
 ### Bundling your ApiRef with your plugin
 
@@ -233,7 +233,7 @@ export const myCustomPlugin = createPlugin({
 ### Using the API in your components
 
 Now you should be able to access your API using the backstage hook
-[`useApi`](../reference/frontend-plugin-api.useapi.md) from within your plugin code.
+[`useApi`](https://backstage.io/api/stable/functions/_backstage_frontend-plugin-api.useApi.html) from within your plugin code.
 
 ```ts title="plugins/my-awesome-plugin/src/components/AwesomeUsersTable.tsx"
 import { useApi } from '@backstage/core-plugin-api';