chore(docs): fix links for domain migration (#4831)

* chore(docs): fix links for domain migration

* try trailing slash for netlify

* trial

* fix typo

* test path

* try preview proxied

* test local proxy

* try to define the domain with redirect to /docs

* remove build commands

* debug netlify router and fix image link

* working config

* fix analytics

docs/docs/concepts/architecture/software.md

@@ -37,15 +37,15 @@ The http server is responsible for the following functions:
 
 The API layer consist of the multiple APIs provided by ZITADEL. Each serves a dedicated purpose.
 All APIs of ZITADEL are always available as gRCP, gRPC-web and REST service. 
-The only exception is the [OpenID Connect & OAuth](/docs/apis/openidoauth/endpoints) and [Asset API](/docs/apis/introduction#assets) due their unique nature.
+The only exception is the [OpenID Connect & OAuth](/apis/openidoauth/endpoints) and [Asset API](/apis/introduction#assets) due their unique nature.
 
-- [OpenID Connect & OAuth](/docs/apis/openidoauth/endpoints) - allows to request authentication and authorization of ZITADEL
-- [SAML](/docs/apis/saml/endpoints) - allows to request authentication and authorization of ZITADEL through the SAML standard
-- [Authentication API](/docs/apis/introduction#authentication) - allow a user to do operation in its own context
-- [Management API](/docs/apis/introduction#management) - allows an admin or machine to manage the ZITADEL resources on an organization level
-- [Administration API](/docs/apis/introduction#administration) - allows an admin or machine to manage the ZITADEL resources on an instance level
-- [System API](/docs/apis/introduction#system) - allows to create and change new ZITADEL instances
-- [Asset API](/docs/apis/introduction#assets) - is used to upload and download static assets
+- [OpenID Connect & OAuth](/apis/openidoauth/endpoints) - allows to request authentication and authorization of ZITADEL
+- [SAML](/apis/saml/endpoints) - allows to request authentication and authorization of ZITADEL through the SAML standard
+- [Authentication API](/apis/introduction#authentication) - allow a user to do operation in its own context
+- [Management API](/apis/introduction#management) - allows an admin or machine to manage the ZITADEL resources on an organization level
+- [Administration API](/apis/introduction#administration) - allows an admin or machine to manage the ZITADEL resources on an instance level
+- [System API](/apis/introduction#system) - allows to create and change new ZITADEL instances
+- [Asset API](/apis/introduction#assets) - is used to upload and download static assets
 
 ### Core Layer
 

docs/docs/concepts/features/selfservice.md

@@ -10,7 +10,7 @@ It is important to understand that, depending on your use case, there will exist
 - `Users` are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.
 - `Managers` are users with a [special manager role](../../guides/manage/console/managers) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
 
-All self-service interfaces are available in different [languages](/docs/guides/manage/customize/texts#internationalization).
+All self-service interfaces are available in different [languages](/guides/manage/customize/texts#internationalization).
 
 :::info
 ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Managers](#managers).
@@ -64,7 +64,7 @@ By default, the displayed branding is defined based on the user's domain. In cas
 
 ### Web, Mobile, and Single-Page Applications
 
-[This guide](/docs/guides/integrate/login-users) explains in more detail the login-flows for different application types.
+[This guide](/guides/integrate/login-users) explains in more detail the login-flows for different application types.
 Human users are redirected to ZITADEL's login page and complete sign-in with the interactive login flow.
 It is important to understand that ZITADEL provides a hosted login page and the device of the users opens this login page in a browser, even on Native/Mobile apps.
 
@@ -72,7 +72,7 @@ It is important to understand that ZITADEL provides a hosted login page and the
 
 Users are automatically prompted to provide a second factor, when
 
-- Instance or organization [login policy](/docs/concepts/structure/policies#login-policy) is set
+- Instance or organization [login policy](/concepts/structure/policies#login-policy) is set
 - Requested by the client
 - A multi-factor is setup for the user
 
@@ -104,7 +104,7 @@ Given an external identity provider is configured on the instance or on the orga
 ### Machines
 
 Machine accounts can't use an interactive login but require other means of authentication, such as privately-signed JWT or personal access tokens.
-Read more about [Service Users](/docs/guides/integrate/serviceusers) and recommended [OpenID Connect Flows](/docs/guides/integrate/oauth-recommended-flows#different-client-profiles).
+Read more about [Service Users](/guides/integrate/serviceusers) and recommended [OpenID Connect Flows](/guides/integrate/oauth-recommended-flows#different-client-profiles).
 
 ### Other Clients
 
@@ -119,7 +119,7 @@ The user can click the account in the list and does not need to type the usernam
 Users can still login with a different user that is not in the list.
 
 :::info
-This behavior can be changed with the authorization request. Please refer to our [guide](/docs/guides/integrate/login-users).
+This behavior can be changed with the authorization request. Please refer to our [guide](/guides/integrate/login-users).
 :::
 
 ### Password reset
@@ -133,7 +133,7 @@ Unauthenticated users can request a password reset after providing the loginname
 ## Logout
 
 Users can terminate the session for all their users (logout).
-A client can also implement this, by calling the [specific endpoint](/docs/apis/openidoauth/endpoints#end_session_endpoint).
+A client can also implement this, by calling the [specific endpoint](/apis/openidoauth/endpoints#end_session_endpoint).
 
 ## Profile
 
@@ -203,7 +203,7 @@ This could be permission to assign authorizations within this isolated organizat
 
 ### Managers in delegation
 
-In a setup like described in the [B2B Scenario](/docs/guides/solution-scenarios/b2b), there exists an organization of the project owner and a customer organization.
+In a setup like described in the [B2B Scenario](/guides/solution-scenarios/b2b), there exists an organization of the project owner and a customer organization.
 The project is granted to the customer organization, such that the customer can access the project and assign authorization to their users.
 
 Given such as setup the owner might want to give one administrative user of the customer organization the role `ORG_OWNER`.

docs/docs/concepts/structure/_org_description.mdx

@@ -1,6 +1,6 @@
 ZITADEL is organized around the idea that:
 
-* Multiple organizations can be managed within one [instance](/docs/concepts/structure/instance).
+* Multiple organizations can be managed within one [instance](/concepts/structure/instance).
 * organizations can grant each other rights to self-manage certain aspects of the IAM (eg, roles for access management)
 * organizations are vessels for users and projects
 

docs/docs/concepts/structure/instance.mdx

@@ -5,20 +5,20 @@ title: Instance
 ## Instance Structure
 
 An instance is the top node in ZITADEL's data hierarchy.
-Within an instance all the default [settings](/docs/concepts/structure/policies),
+Within an instance all the default [settings](/concepts/structure/policies),
 such as branding, login policy, password policy, etc. for the system can be configured.
 One instance normally runs on one domain and represents one issuer (e.g login.customer.com).
 
-One instance can contain multiple [organizations](/docs/concepts/structure/organizations),
+One instance can contain multiple [organizations](/concepts/structure/organizations),
 which in turn can represent your own company (e.g. departments), your business customers or a consumer organization.
 
-Read more about how to configure your instance in our [instance guide](/docs/guides/manage/console/instance-settings).
+Read more about how to configure your instance in our [instance guide](/guides/manage/console/instance-settings).
 
 ## Multiple Virtual Instances
 
 ZITADEL has the concept of virtual instances.
 When installing ZITADEL from scratch, one instance is always automatically created for you.
-Nevertheless, you can add more virtual instances via the [system API](/docs/apis/proto/system#addinstance).
+Nevertheless, you can add more virtual instances via the [system API](/apis/proto/system#addinstance).
 This is useful if you have business customers, which in turn have their business customers with self service and custom domain demands.
 By providing a virtual ZITADEL instances, your customers have all the customization options available in ZITADEL.
 Scaling ZITADEL instances virtually enables you to easily distribute your limited compute resources to all your customers.

docs/docs/concepts/structure/users.md

@@ -22,12 +22,12 @@ The main difference between human and machine users is the type of credentials t
 
 ### Managers
 
-Any user, human or service user, can be given a [Manager](/docs/concepts/structure/managers) role.
+Any user, human or service user, can be given a [Manager](/concepts/structure/managers) role.
 Given a manager role, a user is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.
 
 ## Constraints
 
-Users can only exist within one [organization](/docs/concepts/structure/organizations).
+Users can only exist within one [organization](/concepts/structure/organizations).
 It is currently not possible to move users between organizations.
 
 User accounts are uniquely identified by their `id` or `loginname` in combination of the `organization domain` (eg, `road.runner@acme.zitadel.local`).
@@ -35,7 +35,7 @@ You can use the same email address for different user accounts.
 
 ## Where to store users
 
-Depending on your [scenario](/docs/guides/solution-scenarios/introduction), you might want to store all users in one organization (CIAM / B2C) or create a new organization for each logical group of users, e.g. each business customer (B2B).
+Depending on your [scenario](/guides/solution-scenarios/introduction), you might want to store all users in one organization (CIAM / B2C) or create a new organization for each logical group of users, e.g. each business customer (B2B).
 With a project grant, you can delegate the access management of an organization's project to another organization.
 You can also create a user grant to allow single users to access projects from another organization.
 This is also an alternative to cases where you might want to move users between organizations.