docs: structure update (#11275)

### **Restructure Docs Navigation & Consolidate Core Concepts** **Summary** This PR refactors the documentation navigation to follow a clearer **User Journey** and consolidates fragmented pages to reduce redundancy. **Key Changes** * **Sidebar:** * Replaced the legacy resource-based structure with user-journey-focused categories. **Proposed Structure:** ``` Get Started ├─ Overview │ └─ Guides Overview (Brief intro to docs, persona-aligned: "Get auth working in minutes for your B2B app.") ├─ Quickstart Guide │ └─ Quickstart (Step-by-step: Sign up, spin up instance, connect app, log in – mirrors brand's 4-step guide.) ├─ Authenticate Users │ ├─ Login with ZITADEL (OIDC) │ ├─ Get ID / Access Token │ └─ Logout ├─ Examples & SDKs │ ├─ SPA / Frontend │ ├─ Web Applications │ ├─ APIs / Backend Services │ ├─ Hybrid / Full-Stack │ └─ Sample Applications (Include community-contributed examples for openness.) ├─ Key Concepts │ ├─ Instances, Orgs, Projects, Apps │ ├─ Policies (Intro) │ └─ Users & Roles └─ Use Cases ├─ B2B Integration (Tailored to multi-tenant enterprise needs.) ├─ B2C Login ├─ Multi-Tenant / SaaS ├─ Branded Login & White-Label └─ Machine-to-Machine (M2M) Configure Identity & Policies ├─ Identity Providers │ ├─ External IDPs (e.g., Google, Azure) │ └─ Custom Providers ├─ Policies │ ├─ Password Policies │ ├─ Lockout Policies │ └─ Privacy Policies ├─ Roles & Permissions │ ├─ RBAC Setup │ └─ Custom Roles └─ Compliance & Security ├─ Audits & Logs └─ Certifications (Highlight trust through openness.) Integrate & Authenticate ├─ OIDC & OAuth Flows ├─ API Access │ ├─ gRPC APIs │ └─ REST APIs ├─ SDKs │ ├─ Go │ ├─ JavaScript/TypeScript │ ├─ Python │ └─ Others (Link to community SDKs.) └─ External Integrations ├─ SAML ├─ LDAP └─ Webhooks Test & Debug ├─ Testing Tools │ ├─ Console Testing │ └─ API Playground ├─ Common Issues │ ├─ Token Errors │ └─ Integration Failures └─ Debugging Guides ├─ Logs & Monitoring └─ Error Codes Reference Deploy & Operate ├─ Deployment Options │ ├─ Cloud (ZITADEL Cloud) │ ├─ Self-Hosted (Linux, MacOS) │ ├─ Docker Compose │ └─ Kubernetes ├─ Configuration │ ├─ Environment Variables │ └─ Advanced Settings ├─ Scaling & Performance │ ├─ High Availability │ └─ Backup & Restore └─ Monitoring & Maintenance ├─ Metrics └─ Upgrades Architecture & Concepts ├─ System Architecture │ ├─ Core Components │ └─ Data Flow Diagrams (Expressive visuals per brand.) ├─ Principles │ ├─ Multi-Tenancy │ └─ Open Standards (OIDC, SAML) └─ Advanced Topics ├─ Customization └─ Extensibility (Open-source contributions.) Product, Releases & Support ├─ Product Features │ ├─ Roadmap (Public, for transparency.) │ └─ Pricing & Tiers ├─ Releases │ ├─ Changelog │ └─ Upgrade Guides └─ Support Resources ├─ Community (Discord, GitHub – for community-led growth.) ├─ FAQ ├─ Contact Support └─ Contribute (Encourage feedback/shaping the product.) ``` **Content Consolidation:** * Merged separate "Concept" and "Console Guide" files into single, comprehensive **Overview** pages for core resources: * `Organizations`, `Projects`, `Applications`, `Users`, `Console`, and `Actions`. ``` concepts/structure/organizations + guides/manage/console/organizations -> guides/manage/console/organizations-overview concepts/structure/projects + guides/manage/console/projects -> guides/manage/console/projects-overview concepts/structure/applications + guides/manage/console/applications -> guides/manage/console/applications-overview concepts/structure/users + guides/manage/console/users -> guides/manage/console/users-overview guides/manage/console/actions + apis/actions/introduction -> guides/manage/console/actions-overview concepts/features/console + guides/manage/console/overview -> guides/manage/console/console-overview ``` **Redirects (`vercel.json`):** * Added permanent redirects for all the 6 legacy files mentioned above **No files were deleted** --------- Co-authored-by: Florian Forster <[email protected]>
2026-11-01 03:52:14 +00:00 · 2026-01-09 15:07:02 -03:00
parent 3afa6a2e81
commit 96f9bbc044
73 changed files with 1686 additions and 766 deletions
@@ -105,7 +105,7 @@ Yet it offers everything you need for a customer identity ([CIAM](https://zitade
 - [API-first approach](https://zitadel.com/docs/apis/introduction)
 - [Multi-tenancy](https://zitadel.com/docs/guides/solution-scenarios/b2b) authentication and access management
 - [Strong audit trail](https://zitadel.com/docs/concepts/features/audit-trail) thanks to [event sourcing](https://zitadel.com/docs/concepts/eventstore/overview) as storage pattern
- [Actions](https://zitadel.com/docs/apis/actions/introduction) to react on events with custom code and extended ZITADEL for you needs
+- [Actions](https://zitadel.com/docs/guides/manage/console/actions-overview) to react on events with custom code and extended ZITADEL for you needs
 - [Branding](https://zitadel.com/docs/guides/manage/customize/branding) for a uniform user experience across multiple organizations
 - [Self-service](https://zitadel.com/docs/concepts/features/selfservice) for end-users, business customers, and administrators
 - [Postgres](https://www.postgresql.org/) database as reliable and widespread storage option
@@ -132,13 +132,13 @@ Multi-Tenancy

 - [Identity Brokering](https://zitadel.com/docs/guides/integrate/identity-brokering) with templates for popular identity providers
 - [Customizable onboarding](https://zitadel.com/docs/guides/solution-scenarios/onboarding) for B2B and their users
- [Delegate role management to third-parties](https://zitadel.com/docs/guides/manage/console/projects)
+- [Delegate role management to third-parties](https://zitadel.com/docs/guides/manage/console/projects-overview)
 - [Domain discovery](https://zitadel.com/docs/guides/solution-scenarios/domain-discovery)

 Integration

 - [GRPC and REST APIs](https://zitadel.com/docs/apis/introduction) for every functionality and resource
- [Actions](https://zitadel.com/docs/apis/actions/introduction) to call any API, send webhooks, adjust workflows, or customize tokens
+- [Actions](https://zitadel.com/docs/guides/manage/console/actions-overview) to call any API, send webhooks, adjust workflows, or customize tokens
 - [Role Based Access Control (RBAC)](https://zitadel.com/docs/guides/integrate/retrieve-user-roles)
 - [SCIM 2.0 Server](https://zitadel.com/docs/apis/scim2)
 - [Examples and SDKs](https://zitadel.com/docs/sdk-examples/introduction)
@@ -149,7 +149,7 @@ Integration
 Self-Service
 - [Self-registration](https://zitadel.com/docs/concepts/features/selfservice#registration) including verification
 - [Self-service](https://zitadel.com/docs/concepts/features/selfservice) for end-users, business customers, and administrators
- [Administration UI (Console)](https://zitadel.com/docs/guides/manage/console/overview)
+- [Administration UI (Console)](https://zitadel.com/docs/guides/manage/console/console-overview)

 Deployment
 - [Postgres](https://zitadel.com/docs/self-hosting/manage/database#postgres) (version >= 14)
@@ -187,7 +187,7 @@ Use our Login widget to allow easy and secure access to your applications and en

 ### Admin Console

-Use [Console](https://zitadel.com/docs/guides/manage/console/overview) or our [APIs](https://zitadel.com/docs/apis/introduction) to setup organizations, projects and applications.
+Use [Console](https://zitadel.com/docs/guides/manage/console/console-overview) or our [APIs](https://zitadel.com/docs/apis/introduction) to setup organizations, projects and applications.

 [![Console Showcase](https://user-images.githubusercontent.com/1366906/223663344-67038d5f-4415-4285-ab20-9a4d397e2138.gif)](http://www.youtube.com/watch?v=RPpHktAcCtk "Console Showcase")

@@ -1,7 +1,7 @@
 <cnsl-top-view
  title="{{ app?.name }}"
  [hasActions]="!isZitadel && (['project.app.write:' + projectId, 'project.app.write'] | hasRole | async)"
-  docLink="https://zitadel.com/docs/guides/manage/console/projects"
+  docLink="https://zitadel.com/docs/guides/manage/console/projects-overview"
  [sub]="app?.oidcConfig ? ('APP.OIDC.APPTYPE.' + app?.oidcConfig?.appType | translate) : app?.apiConfig ? 'API' : 'SAML'"
  [isActive]="app?.state === AppState.APP_STATE_ACTIVE"
  [isInactive]="app?.state === AppState.APP_STATE_INACTIVE"
@@ -1,7 +1,7 @@
 <cnsl-top-view
  title="{{ project?.projectName }}"
  [hasActions]="false"
-  docLink="https://zitadel.com/docs/guides/manage/console/projects#what-is-a-granted-project"
+  docLink="https://zitadel.com/docs/guides/manage/console/projects-overview#granted-projects-b2b"
  sub="{{ 'PROJECT.PAGES.TYPE.GRANTED_SINGULAR' | translate: { name: project?.projectOwnerName } }}"
  [isActive]="project?.state === ProjectGrantState.PROJECT_GRANT_STATE_ACTIVE"
  [isInactive]="project?.state === ProjectGrantState.PROJECT_GRANT_STATE_INACTIVE"
@@ -1,6 +1,6 @@
 <cnsl-top-view
  title="{{ project?.name }}"
-  docLink="https://zitadel.com/docs/guides/manage/console/projects"
+  docLink="https://zitadel.com/docs/guides/manage/console/projects-overview"
  sub="{{ 'PROJECT.PAGES.TYPE.OWNED_SINGULAR' | translate }}"
  [isActive]="project?.state === ProjectState.PROJECT_STATE_ACTIVE"
  [isInactive]="project?.state === ProjectState.PROJECT_STATE_INACTIVE"
@@ -1,7 +1,11 @@
 <cnsl-detail-layout [hasBackButton]="true" title="{{ 'PROJECT.GRANT.DETAIL.TITLE' | translate }}">
  <p class="subinfo" sub>
    <span class="cnsl-secondary-text">{{ 'PROJECT.GRANT.DETAIL.DESC' | translate }}</span>
-    <a mat-icon-button href="https://zitadel.com/docs/concepts/structure/projects#granted-organizations" target="_blank">
+    <a
+      mat-icon-button
+      href="https://zitadel.com/docs/guides/manage/console/organizations-overview#organization-grants"
+      target="_blank"
+    >
      <mat-icon class="icon">info_outline</mat-icon>
    </a>
  </p>
@@ -2,7 +2,12 @@
  <div class="enlarged-container">
    <div class="project-title-row">
      <h1>{{ 'DESCRIPTIONS.PROJECTS.TITLE' | translate }}</h1>
-      <a mat-icon-button href="https://zitadel.com/docs/concepts/structure/projects" rel="noreferrer" target="_blank">
+      <a
+        mat-icon-button
+        href="https://zitadel.com/docs/guides/manage/console/projects-overview"
+        rel="noreferrer"
+        target="_blank"
+      >
        <mat-icon class="icon">info_outline</mat-icon>
      </a>
    </div>
@@ -2,7 +2,7 @@
  <cnsl-top-view
    *ngIf="(userQuery.state === 'success' || userQuery.state === 'loading') && userQuery.value as user"
    title="{{ user.type.case === 'human' ? user.type.value.profile?.displayName : user.type.value?.name }}"
-    docLink="https://zitadel.com/docs/guides/manage/console/users"
+    docLink="https://zitadel.com/docs/guides/manage/console/users-overview"
    sub="{{ user.preferredLoginName }}"
    [isActive]="user.state === UserState.ACTIVE"
    [isInactive]="user.state === UserState.INACTIVE"
@@ -2,7 +2,12 @@
  <div class="enlarged-container">
    <div class="users-title-row">
      <h1>{{ 'DESCRIPTIONS.USERS.TITLE' | translate }}</h1>
-      <a mat-icon-button href="https://zitadel.com/docs/concepts/structure/users" rel="noreferrer" target="_blank">
+      <a
+        mat-icon-button
+        href="https://zitadel.com/docs/guides/manage/console/users-overview"
+        rel="noreferrer"
+        target="_blank"
+      >
        <mat-icon class="icon">info_outline</mat-icon>
      </a>
    </div>
@@ -182,7 +182,7 @@ This object represents [the claims](../openidoauth/claims) which will be written
 - `email_verified` *bool*
 - `updated_at` *Number*

-Additionally there could additional fields depending on the configuration of your [project](../../guides/manage/console/projects#role-settings) and your [application](../../guides/manage/console/applications#token-settings)
+Additionally there could additional fields depending on the configuration of your [project](../../guides/manage/console/projects-overview#role-settings) and your [application](../../guides/manage/console/applications-overview#token-settings)

 ## user grant list

@@ -10,7 +10,7 @@ ZITADEL exposes all features via different gRPC and REST APIs and provides SDKs

 The [OpenID Connect & OAuth endpoints](/docs/apis/openidoauth/endpoints) and [SAML 2.0 endpoints](/docs/apis/saml/endpoints) are implemented and exposed according to the specific standards. Managing resources such as users, organizations, instances, or settings must be done with the different [ZITADEL APIs](#zitadel-apis-resource-based).

-[Actions](/docs/apis/actions/introduction) allow to extend ZITADEL with custom code to change default behaviors or calling external systems.
+[Actions](/docs/guides/manage/console/actions-overview) allow to extend ZITADEL with custom code to change default behaviors or calling external systems.

 ## Authentication & authorization

@@ -78,7 +78,7 @@ Please check below the matrix for an overview where which scope is asserted.
 Custom claims are being inserted into user tokens in addition to the standard claims.
 Your app can use custom claims to handle more complex scenarios, such as restricting access based on these claims.

-You can add custom claims using the [complement token flow](/docs/apis/actions/complement-token) of the [actions feature](/docs/apis/actions/introduction).
+You can add custom claims using the [complement token flow](/docs/apis/actions/complement-token) of the [actions feature](/docs/guides/manage/console/actions-overview).

 Multiple examples of Actions that result in custom claims can be found in our [Marketplace for ZITADEL Actions](https://github.com/zitadel/actions).

@@ -115,8 +115,8 @@ As per [OpenID Connect Core 1.0, Section 3.1.2.1](https://openid.net/specs/openi

 | Response Mode | Description                                                                                                                                                                                                                                                                                                                     |
 | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| query         | Encode the returned parameters in the URL query string. This is the default when the Response type is `code`, for example [Web applications](/docs/guides/manage/console/applications#web).                                                                                                                                     |
-| fragment      | Encode the returned parameters in the URL fragment. This is the default when the Response Type is `id_token`, for example implicit [User Agent apps](/docs/guides/manage/console/applications#user-agent). This mode will not work for server-side applications, because fragments are never sent by the browser to the server. |
+| query         | Encode the returned parameters in the URL query string. This is the default when the Response type is `code`, for example [Web applications](/docs/guides/manage/console/applications-overview#web).                                                                                                                                     |
+| fragment      | Encode the returned parameters in the URL fragment. This is the default when the Response Type is `id_token`, for example implicit [User Agent apps](/docs/guides/manage/console/applications-overview#user-agent). This mode will not work for server-side applications, because fragments are never sent by the browser to the server. |
 | form_post[^1] | ZITADEL serves a small JavaScript to the browser which will send the returned parameters to the `redirect_uri` using HTTP POST. This mode only works for server-side applications and user agents which support / allow JavaScript.                                                                                             |

 [^1]: Implements [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html)
@@ -64,6 +64,6 @@ spec** [Assertions and Protocols for the OASIS Security Assertion Markup Languag
 Custom attributes are being inserted into SAML response if not already present.
 Your app can use custom claims to handle more complex scenarios, such as restricting access based on these claims.

-You can add custom attributes using the [complement SAMLresponse](/docs/apis/actions/customize-samlresponse) of the [actions feature](/docs/apis/actions/introduction).
+You can add custom attributes using the [complement SAMLresponse](/docs/apis/actions/customize-samlresponse) of the [actions feature](/docs/guides/manage/console/actions-overview).

 Examples of Actions that result in custom attributes can be found in our [Marketplace for ZITADEL Actions](https://github.com/zitadel/actions).
@@ -34,6 +34,6 @@ Within the JavaScript code, you can read and manipulate the state.
 ## Further reading

 - [Assign users a role after they register using an external identity provider](/guides/manage/customize/behavior)
- [Actions reference](/apis/actions/introduction#action)
+- [Actions reference](/guides/manage/console/actions-overview#action)
 - [Actions Marketplace: Find example actions to use in ZITADEL](https://github.com/zitadel/actions)
 - [Example use cases](/apis/actions/code-examples)
@@ -27,15 +27,15 @@ There will be three major areas for future development on the audit data

 ### Last changes of an object

-You can check the last changes of most objects in the [Console](/docs/guides/manage/console/overview).
-In the following screenshot you can see an example of last changes on an [user](/docs/guides/manage/console/users).
+You can check the last changes of most objects in the [Console](/docs/guides/manage/console/console-overview).
+In the following screenshot you can see an example of last changes on an [user](/docs/guides/manage/console/users-overview).
 The same view is available on several other objects such as organization or project.

 ![Profile Self Manage](/img/guides/console/myprofile.png)

 ### Event View

-Administrators can see all events across an instance and filter them directly in [Console](/docs/guides/manage/console/overview).
+Administrators can see all events across an instance and filter them directly in [Console](/docs/guides/manage/console/console-overview).
 Go to your default settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM-DOMAIN/ui/console/events

 ![Event viewer](/img/concepts/audit-trail/event-viewer.png)
@@ -29,5 +29,5 @@ Overall, the ZITADEL console serves as a comprehensive tool for administrators t

 Notes:

- Detailed guide on [using the console](/docs/guides/manage/console/overview)
+- Detailed guide on [using the console](/docs/guides/manage/console/console-overview)
 - [Restrict access](/docs/guides/solution-scenarios/restrict-console) to the console
@@ -1,10 +1,10 @@
-Managers are [human users or service users](/docs/concepts/structure/users) who have permission to manage resources within ZITADEL.
+Managers are [human users or service users](/docs/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.

 Manager permissions can be assigned to different levels in ZITADEL:

 - **IAM Managers**: This is the highest level. Users with IAM Manager roles are able to manage the whole [Instance](/docs/concepts/structure/instance).
- **Org Managers**: Managers in the Organization Level are able to view or manage everything, according to their permissions, within the granted [Organization](/docs/concepts/structure/organizations).
- **Project Mangers**: In this level the user is able to manage a [project](/docs/concepts/structure/projects).
+- **Org Managers**: Managers in the Organization Level are able to view or manage everything, according to their permissions, within the granted [Organization](/docs/guides/manage/console/organizations-overview).
+- **Project Mangers**: In this level the user is able to manage a [project](/docs/guides/manage/console/projects-overview).
 - **Project Grant Manager**: The project grant manager is for [granted projects](/docs/concepts/structure/granted_projects) by another organization.

 Scope of the managers is restricted based on their level.
@@ -24,5 +24,5 @@ Ensure the configuration of application settings is limited to authorized users

 ## References

- [Configure Applications in the Console](../../guides/manage/console/applications)
+- [Configure Applications in the Console](../../guides/manage/console/applications-overview)
 - [ZITADEL API: Applications](/docs/apis/resources/mgmt/applications)
@@ -11,4 +11,4 @@ With ZITADEL you can grant selected roles within your project to an organization

 An example could be a service provider that offers a SaaS solution that has different permissions for employees working in Sales and Accounting. As soon as a new client purchases the service, the provider could grant the roles ‘sales’ and ‘accounting’ to that organization, allowing them to self-manage how they want to allocate the roles to their users.

-To learn more about how to setup Project grants, read this guide [here](../../guides/manage/console/projects#grant-a-project)
+To learn more about how to setup Project grants, read this guide [here](../../guides/manage/console/projects-overview#granted-projects-b2b)
@@ -11,7 +11,7 @@ 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](/concepts/structure/organizations),
+One instance can contain multiple [organizations](/guides/manage/console/organizations-overview),
 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](/guides/manage/console/default-settings).
@@ -8,4 +8,4 @@ import OrgDescription from './_org_description.mdx';

 <OrgDescription name="OrgDescription" />

-More about how to configure your organization read our [organization guide](../../guides/manage/console/organizations).
+More about how to configure your organization read our [organization guide](../../guides/manage/console/organizations-overview).
@@ -8,7 +8,7 @@ import ProjectDescription from './\_project_description.mdx';

 <ProjectDescription name="ProjectDescription" />

-To learn how to set up a project read this console guide [here](../../guides/manage/console/projects.mdx).
+To learn how to set up a project read this console guide [here](../../guides/manage/console/projects-overview.mdx).

 ## Applications

@@ -47,7 +47,7 @@ These invited users are called external users.

 ### Uniqueness of users

-Users can only exist within one [organization](/concepts/structure/organizations).
+Users can only exist within one [organization](/guides/manage/console/organizations-overview).
 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, `[email protected]`).
@@ -77,6 +77,6 @@ You can use organization metadata or your own business logic to describe a hiera

 ## References

- [Manage users in the Console](../../guides/manage/console/users)
+- [Manage users in the Console](../../guides/manage/console/users-overview)
 - [ZITADEL APIs: Users](/docs/apis/resources/mgmt/users)
 - [User onboarding and registration](/docs/guides/integrate/onboarding)
@@ -63,7 +63,7 @@ http_address = "127.0.0.1:4180" #localdev only

 ### Check for groups

-If you want oauth2-proxy to check for roles in the tokens you have to add an [action](/docs/apis/actions/introduction) in ZITADEL to [complement the token](/docs/apis/actions/complement-token) according to [this example](https://github.com/zitadel/actions/blob/main/examples/custom_roles.js) and add the following configuration to the config:
+If you want oauth2-proxy to check for roles in the tokens you have to add an [action](/docs/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/docs/apis/actions/complement-token) according to [this example](https://github.com/zitadel/actions/blob/main/examples/custom_roles.js) and add the following configuration to the config:

 ```toml
 oidc_groups_claim = "{your_actions_group_key}"
@@ -135,7 +135,7 @@ Let's call this new organization `Demo-Customer`.

 ### Users

-Now switch back to the organization `Demo-Customer` and [create a new user](/guides/manage/console/users#create-user) in this organization.
+Now switch back to the organization `Demo-Customer` and [create a new user](/guides/manage/console/users-overview#create-user) in this organization.
 Let's call the first user `Alice Admin`. Create a second user called `Eric Employee`.

 ### Manager Role
@@ -152,7 +152,7 @@ Login with your user on the customer organization to validate the setup.
 ### Organization Grant

 Switch to the `Demo-Vendor` organization, select Projects in the navigation, and click on `Portal` and then `Grants`.
-[Grant all roles of the Project](/guides/manage/console/projects#grant-a-project) to the organization `demo-customer.{YourDomain}.zitadel.cloud`.
+[Grant all roles of the Project](/guides/manage/console/projects-overview#granted-projects-b2b) to the organization `demo-customer.{YourDomain}.zitadel.cloud`.

 ### Authorization

@@ -102,7 +102,7 @@ composer require drenso/symfony-oidc-bundle

 First, we need to create a User class for the database, so we can persist user info between requests. In this case you don't need password authentication.
 Email addresses are not unique for ZITADEL users. There can be multiple user accounts with the same email address.
-See [User Constraints](/docs/concepts/structure/users#constraints) for more details.
+See [User Constraints](/docs/guides/manage/console/users-overview#considerations) for more details.
 We will use the User Info `sub` claim as unique "display" name for the user. `sub` equals the unique User ID from ZITADEL.
 This creates a User Repository and Entity that implements the `UserInterface`:

@@ -33,7 +33,7 @@ You need to setup a couple of things in ZITADEL.

 1. If you don't have an instance yet, please go ahead and create an instance as explained [here](/docs/guides/start/quickstart#2-create-your-first-instance). Also, create a new project by following the steps [here](/docs/guides/start/quickstart#2-create-your-first-instance).

-2. You must create an API application in your project. Follow [this guide](/docs/guides/manage/console/applications) to create a new application of type "API" with authentication method "Basic". Save both the ClientID and ClientSecret after you create the application. 
+2. You must create an API application in your project. Follow [this guide](/docs/guides/manage/console/applications-overview) to create a new application of type "API" with authentication method "Basic". Save both the ClientID and ClientSecret after you create the application. 

 ### Create the API

@@ -2,7 +2,7 @@
 title: Migrate from Actions v1 to v2
 ---

-In this guide, you will have all necessary information to migrate from Actions v1 to Actions v2 with all currently [available Flow Types](/apis/actions/introduction#available-flow-types).
+In this guide, you will have all necessary information to migrate from Actions v1 to Actions v2 with all currently [available Flow Types](/guides/manage/console/actions-overview#available-flow-types).

 ## Internal Authentication

@@ -60,7 +60,7 @@ ZITADEL offers various [identity provider templates](/docs/guides/integrate/iden

 ### Multi-tenancy authentication

-ZITADEL simplifies multi-tenancy authentication by securely managing authentication for multiple tenants, called [Organizations](/docs/concepts/structure/organizations), within a single [instance](/docs/concepts/structure/instance).
+ZITADEL simplifies multi-tenancy authentication by securely managing authentication for multiple tenants, called [Organizations](/docs/guides/manage/console/organizations-overview), within a single [instance](/docs/concepts/structure/instance).

 Key features include:

@@ -124,4 +124,4 @@ Main reasons why developers might want to build their own login UI include:

 - Learn how to [register and onboard users](/docs/guides/integrate/onboarding)
 - Learn how to [build your own login UI](/docs/guides/integrate/login-ui) based on ZITADEL
- Learn how to [configure ZITADEL](/docs/guides/manage/console/overview) through the Console
+- Learn how to [configure ZITADEL](/docs/guides/manage/console/console-overview) through the Console
@@ -1,6 +1,6 @@
 ---
 title: Integrating Your Application with ZITADEL using RFC 8628 OAuth 2.0 Device Authorization Flow
-sidebar_label: Device Authorization
+sidebar_label: Device Authorization Flow
 ---

 ZITADEL implements device authorization as per [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628). This document demonstrates its use.
@@ -1,6 +1,6 @@
 ---
 title: Authenticate users with OpenID Connect
-sidebar_label: Login
+sidebar_label: OIDC Code Flow + PKCE
 ---

 import Tabs from "@theme/Tabs";
@@ -25,7 +25,7 @@ ZITADEL does have multiple possibilities to achieve that process.

 ## Onboard customers through the ZITADEL Management Console

-Each ZITADEL instance does automatically bring a management console with it. The [console](/docs/guides/manage/console/overview) can be used to manage all your resources through a UI.
+Each ZITADEL instance does automatically bring a management console with it. The [console](/docs/guides/manage/console/console-overview) can be used to manage all your resources through a UI.
 You can access it by calling the following URL: `${CUSTOM-DOMAIN}/ui/`
 Make sure that your admins have a [Manager role](/docs/guides/manage/console/managers) with permissions on an instance level such as "INSTANCE_OWNER"

@@ -18,7 +18,7 @@ SCIM provisioning in ZITADEL is accomplished by authenticating a Service User wi

 1. **Create a Service User**:

-   * Follow [this guide](https://zitadel.com/docs/guides/manage/console/users) to create a Service User within your ZITADEL Organization.
+   * Follow [this guide](https://zitadel.com/docs/guides/manage/console/users-overview) to create a Service User within your ZITADEL Organization.

 2. **Assign the Role**:

@@ -111,7 +111,7 @@ Review and adjust attribute mappings in Okta as needed:

 * [Authenticate users with SAML](https://zitadel.com/docs/guides/integrate/login/saml)

-* [ZITADEL: Creating Service Users](https://zitadel.com/docs/guides/manage/console/users)
+* [ZITADEL: Creating Service Users](https://zitadel.com/docs/guides/manage/console/users-overview)

 * [ZITADEL: Service User Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users)

@@ -4,7 +4,7 @@ sidebar_label: Client credential authentication
 sidebar_position: 3
 ---

-This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service users](/concepts/structure/users) and client applications within ZITADEL.
+This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service users](/guides/manage/console/users-overview#service-users-machine-accounts) and client applications within ZITADEL.

 In ZITADEL, the Client Credentials Flow can be used for this [non-interactive authentication](authenticate-service-users) as alternative to the [JWT profile authentication](../service-users/authenticate-service-users).

@@ -13,8 +13,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - existing Atlassian Access setup, including verified domain

 > We have to switch between ZITADEL and Atlassian. If the headings begin with "ZITADEL" switch to the ZITADEL
@@ -15,8 +15,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)

 > We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Console and if the headings start with "Auth0" please switch to the Auth0 GUI.
@@ -13,8 +13,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)

 > We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Console and
@@ -13,8 +13,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - prerequisites on AWS side [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereqs.html).
 - enabled AWS SSO [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html?icmpid=docs_sso_console)

@@ -13,8 +13,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - existing Gitlab SaaS Setup in the premium tier

 > We have to switch between ZITADEL and Gitlab. If the headings begin with "ZITADEL" switch to the ZITADEL
@@ -15,8 +15,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - running Gitlab instance see [installation guide](https://docs.gitlab.com/ee/install/)

 <CreateApp appType="web" authType="code" appName="Gitlab" redirectURI="https://<your_gitlab_url>/users/auth/openid_connect/callback"/>
@@ -16,8 +16,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - prerequisites on Google Cloud side [in the configuration guide](https://cloud.google.com/iam/docs/configuring-workforce-identity-federation).

 > We have to switch between ZITADEL and a Google Cloud. If the headings begin with "ZITADEL" switch to the ZITADEL Console and if
@@ -84,7 +84,7 @@ Go to your project and create roles according to the Groups in Google Cloud.
 Authorize a test user by assigning roles in ZITADEL.

 Google Cloud expects some claims, including groups, in a specific format as [described here](https://cloud.google.com/iam/docs/workforce-identity-federation#attribute-mappings).
-Claims can be transformed in ZITADEL with [Actions](/apis/actions/introduction).
+Claims can be transformed in ZITADEL with [Actions](/guides/manage/console/actions-overview).

 Create an Action with the following code to flatten the roles and include the claim for the users' display name.

@@ -13,8 +13,8 @@ It covers how to:
 Prerequisites:

 - existing ZITADEL Instance, if not present follow [this guide](/guides/start/quickstart)
- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations)
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects)
+- existing ZITADEL Organization, if not present follow [this guide](/guides/manage/console/organizations-overview)
+- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
 - existing Pingidentity environment [here](https://docs.pingidentity.com/bundle/pingone/page/wqe1564020490538.html)

 > We have to switch between ZITADEL and Ping Identity. If the headings begin with "ZITADEL" switch to the ZITADEL
@@ -24,7 +24,7 @@ If you have an API that behaves as an OAuth resource server that can be accessed

 ## Service users

-If there are client APIs or systems that need to access other protected APIs, these APIs or systems must be declared as [service users](/docs/concepts/structure/users).
+If there are client APIs or systems that need to access other protected APIs, these APIs or systems must be declared as [service users](/docs/guides/manage/console/users-overview).
 A service user is not considered an application type in ZITADEL.
 Read the introduction on how to [authenticate service users](../service-users/authenticate-service-users.md).

@@ -1,6 +1,6 @@
 ---
 title: ZITADEL Support
-sidebar_label: Support
+sidebar_label: Customer Support
 ---

 :::note
@@ -0,0 +1,102 @@
+---
+title: Actions
+sidebar_label: Overview
+---
+
+## Overview
+
+An Identity and Access Management system is a highly interactive environment. ZITADEL includes a powerful feature called **Actions**, which allows you to programmatically react to specific events within the system.
+
+Actions allow you to define custom scripts (JavaScript) that are executed based on specific triggers (Flows). This enables advanced customization, such as modifying tokens, calling external APIs during login, or customizing authentication flows.
+
+<img
+  src="/docs/img/guides/console/actionsmenu.png"
+  width="700px"
+  alt="Actions menu"
+/>
+
+## How Actions Work
+
+The Actions architecture consists of three main components:
+
+1.  **Action:** The JavaScript code containing your business logic.
+2.  **Trigger Type:** The specific event in ZITADEL (e.g., "Post Authentication") where code execution is allowed.
+3.  **Flow:** The configuration that links an Action to a Trigger Type.
+
+### The JavaScript Runtime
+
+ZITADEL interprets your Action scripts as JavaScript.
+
+* **Compliance:** Scripts must be **ECMAScript 5.1(+)** compliant.
+* **Engine:** The underlying engine is [goja](https://github.com/dop251/goja). Refer to their documentation for detailed references about the underlying library features and limitations.
+
+### Structure of an Action Script
+
+The script of an action must contain a function that matches the Action's name. ZITADEL calls this function at runtime.
+
+The function receives two primary objects:
+
+* `ctx` (Context): Provides **readable** information about the current request (User, Request Info, etc.).
+* `api` (API): Provides **methods** to mutate state (Set Claims, Deny Access, etc.).
+
+**Example:**
+If your action is named **doSomething**, your script must look like this:
+
+```js
+function doSomething(ctx, api){
+    // read from ctx and manipulate with api
+}
+```
+
+### Available Modules
+
+You can use the following built-in modules inside your JavaScript code:
+
+* [**HTTP module**](../../../apis/actions/modules#http): To call external APIs / Webhooks.
+* [**Logging module**](../../../apis/actions/modules#log): To log information to stdout (useful for debugging).
+* [**UUID module**](../../../apis/actions/modules#uuid): To generate UUIDs.
+
+Stuck customizing ZITADEL actions? Find samples for setting OIDC claims, SAML attributes, extending JIT provisioning data, calling external APIs, and more in [this repository](https://github.com/zitadel/actions).
+
+## Managing Actions in Console
+
+### 1. Create an Action
+
+To add an action, navigate to your Organization's top navigation and select **Actions**. Click the **New** button and provide:
+
+* **Name:** Must match the function name in your script.
+* **Script:** Your JavaScript code.
+* **Timeout:** How long the script is allowed to run before being terminated.
+* **Allowed to Fail:** If checked, the flow will continue even if the script throws an error.
+
+<img src="/docs/img/guides/console/action.png" alt="Create Action" width="450px" />
+
+### 2. Create a Flow (Link Action to Trigger)
+
+Merely creating an Action does not run it. You must create a **Flow** to define *when* it runs.
+
+1.  Select the **Flow Type** (e.g., External Authentication).
+2.  Select the **Trigger** (e.g., Post Authentication).
+3.  Add your Action to the list of executed scripts.
+
+<img src="/docs/img/guides/console/flow.png" alt="Flow" width="400px" />
+
+**Example Scenario:**
+You create an **External Authentication** Flow with a **Post Authentication** trigger. Now, whenever a user authenticates via an external IDP (like Google or Azure AD), your Action is triggered immediately after the authentication step but before the session is finalized.
+
+## Available Flow Types
+
+Trigger types define the point during the execution of a request. Each trigger defines which readable information (`ctx`) and mutable properties (`api`) are passed into the called function.
+
+Currently, ZITADEL supports the following flows:
+
+* [**Internal Authentication**](../../../apis/actions/internal-authentication): Triggers during login with ZITADEL (username/password).
+* [**External Authentication**](../../../apis/actions/external-authentication): Triggers during login with an external Identity Provider.
+* [**Complement Token**](../../../apis/actions/complement-token): Triggers when tokens (ID Token / Access Token) are created, allowing you to add custom claims.
+* [**Customize SAML Response**](../../../apis/actions/customize-samlresponse): Triggers when a SAML response is generated.
+
+## References
+
+* [Guide: Customize Behavior with Actions](/guides/manage/customize/behavior)
+* [ZITADEL Roadmap](https://zitadel.com/roadmap)
+
@@ -0,0 +1,186 @@
+---
+title: Applications
+sidebar_label: Applications
+sidebar_position: 5
+---
+
+import ThemedImage from "@theme/ThemedImage";
+import AuthType from "../../integrate/application/_auth-type.mdx";
+import ReviewConfig from "../../integrate/application/_review-config.mdx";
+import AppType from "./_application-types.mdx";
+
+## What is an application?
+
+Applications are the entry point to your [Project](projects-overview.mdx). Users either login into one of your clients (Frontend) and interact with them directly, or use one of your APIs (Backend).
+
+All applications within a project share the same **Roles** and **Authorizations**. This means you define a role once (e.g., `admin`) on the Project level, and it applies across all your web, mobile, and API applications.
+
+To access your applications, navigate to your Project in the Console and select your application.
+
+<img
+  alt="Granted project"
+  src="/docs/img/guides/console/applications.png"
+  width="750px"
+/>
+
+## Create an Application
+
+To add an application to your project, click on the **New** button and select your application type.
+
+<img
+  alt="Add application"
+  src="/docs/img/guides/console/addapplication.png"
+  width="120px"
+/>
+
+## Application Types
+
+ZITADEL offers five client types to cover different architectural patterns:
+
+<AppType />
+
+The first three options (Web, Native, and User Agent) require user interaction. The fourth option (API) is for machine-to-machine communication without direct user interaction.
+
+Depending on the app type, there are small differences in the possible settings. To get a good understanding about user profiles and recommended flows, read the [Recommended Flows Guide](../../integrate/login/oidc/oauth-recommended-flows.md#different-client-profiles).
+
+### Web
+
+Web applications are **server-side rendered** applications that users interact with.
+* **Examples:** Applications using Java (Spring/Thymeleaf), .NET (Razor), PHP, Python (Django/Flask), or enabling SSO in tools like GitLab.
+* **NextJS:** A NextJS app is typically a Web Application because it can execute server-side code (SSR/API routes) to keep secrets safe.
+* **Authentication:** Uses Authorization Code Flow (PKCE recommended) with a Client Secret.
+
+<AuthType appType="web" />
+
+### Native
+
+Native Applications are installed on a thin client, such as a smartphone or desktop computer.
+* **Examples:** Android Apps, iOS Apps, Desktop Apps (Electron, Tauri).
+* **Authentication:** Uses the Key file generated by ZITADEL to authenticate or Authorization Code Flow with PKCE (for user login).
+
+<AuthType appType="native" />
+
+### User Agent
+
+User Agent Applications are executed entirely in the web browser (Client-Side).
+* **Examples:** Single Page Applications (SPA) built with React, Angular, Vue, or Svelte that do not have a backend server.
+* **Authentication:** Uses Authorization Code Flow with PKCE (implicit flow is supported but not recommended).
+
+<AuthType appType="user-agent" />
+
+### API
+
+These are applications without human interaction, accessed by other applications or services (Machine-to-Machine).
+* **Examples:** Background workers, CLIs, Daemons, Microservices.
+* **Authentication:** Uses Client Credentials (JWT Profile or Basic Auth) or Private Key JWT.
+
+<AuthType appType="api" />
+
+### SAML
+
+If your application doesn't support the OIDC standard but supports SAML 2.0, choose this type. SAML is an XML-based open standard for exchanging authentication and authorization data.
+
+After creating a SAML app, you can either:
+1.  Add a link to a SAML metadata file.
+2.  Upload the metadata XML file directly.
+
+You can find example configurations for SAML 2.0 in our [integrate services](../../integrate/login/saml) guides.
+
+## Configuration
+
+### Redirect URIs
+
+App Types with user interaction (Web, Native, and User Agent) require Redirect URIs. These are the allowed URLs where ZITADEL sends the user after a successful login.
+
+* **Security:** ZITADEL strictly checks these URIs during the login process. They must match exactly what is defined in your application code.
+* **Protocols:** Native applications can use custom protocols (e.g., `myapp://`) instead of `http/https`.
+
+<img
+  alt="Redirect URIs"
+  src="/docs/img/guides/console/redirecturis.png"
+  width="600px"
+/>
+
+### Development Mode
+
+If you are developing locally or need to redirect users to a non-secure protocol (other than `https://`), you must enable **Development mode**.
+When disabled, ZITADEL enforces strict security and only allows `https`.
+
+<img
+  alt="Development mode"
+  src="/docs/img/guides/console/developmentmode.png"
+  width="600px"
+/>
+
+**Glob Patterns:**
+Development mode allows the use of glob patterns in Redirect URIs for flexibility:
+
+| Special Terms | Meaning |
+| :--- | :--- |
+| `*` | Matches any sequence of **non-path-separators**. |
+| `/**/` | Matches zero or more directories. |
+| `?` | Matches any single non-path-separator character. |
+| `[class]` | Matches any single character against a class of characters (e.g., `[a-z]`). |
+| `{alt1,...}` | Matches a sequence if one of the comma-separated alternatives matches. |
+
+:::note
+Double stars (`**`) should appear surrounded by path separators (e.g., `/**/`). A pattern like `path/to/**.txt` is invalid; use `path/to/**/*.txt`.
+:::
+
+:::tip IPv6
+When IPv6 URIs are used as redirects in development mode, square brackets must be escaped as they are special terms for globs. Example: `http://\[::1\]:80`
+:::
+
+### Review Configuration
+
+<ReviewConfig authType="code" />
+
+## Application Settings
+
+After creating an application, you can modify its configuration.
+* **Auth Method:** You can switch authentication methods (e.g., from Basic to Private Key JWT) via the toggle or dropdowns.
+* **OIDC Compliance:** The Console checks if your configuration is OIDC compliant and shows tasks for completion if anything is missing.
+
+:::caution
+You **cannot** change the Application Type (e.g., from Web to Native) after creation. You must delete and recreate the application.
+:::
+
+<img
+  alt="Application Settings"
+  src="/docs/img/guides/console/application.png"
+  width="800px"
+/>
+
+### Token Settings
+
+In the **Token Settings** section, you can customize the tokens issued for this application:
+* **Token Type:** Switch between **Bearer Token** (Opaque) and **JWT**.
+* **Content:** Check options to include User Roles and User Information inside the ID Token.
+* **ClockSkew:** Optionally set a time buffer added to the expiration time of the issued token to handle server time differences.
+
+<img
+  alt="Token settings"
+  src="/docs/img/guides/console/app-token-settings.png"
+  width="600px"
+/>
+
+### Additional Origins
+
+If your application makes requests from domains other than the Redirect URI (e.g., a Javascript app fetching data from an API on a different domain), you can specify them here to configure CORS (Cross-Origin Resource Sharing).
+
+<img
+  alt="Additional origins"
+  src="/docs/img/guides/console/additional-origins.png"
+  width="500px"
+/>
+
+## Security Considerations
+
+Ensure the configuration of application settings is limited to authorized users only.
+
+* Use [Manager roles](./managers) to limit permissions for your users to make changes to your applications.
+* When [granting projects](../../../concepts/structure/granted_projects.md) to other organizations, the receiving organization **cannot** see or change the application configuration. They can only assign roles.
+
+## References
+
+- [Recommended OIDC Flows](../../integrate/login/oidc/oauth-recommended-flows.md)
@@ -0,0 +1,57 @@
+---
+title: Console
+sidebar_label: Console
+---
+
+## Overview
+
+The ZITADEL Console is the web-based Dashboard UI designed to facilitate the management and administration of ZITADEL resources and configurations. It serves as a central hub where [Managers](/docs/concepts/structure/managers) can perform tasks related to identity and access management, configure authentication methods, and manage the organization's infrastructure.
+
+While the Console is primarily a tool for administrators, it can also be accessed by end-users to manage their own profiles (e.g., password reset, MFA setup), unless you [restrict access](/docs/guides/solution-scenarios/restrict-console) to build your own custom UI.
+
+## Accessing the Console
+
+The console is available by navigating to the [custom domain](/docs/concepts/features/custom-domain) of your instance and appending the path `/ui/console`.
+
+## Navigation and Context
+
+When logged in, you are greeted by the home page, which allows you to set shortcuts to frequently used settings and projects.
+
+### Context Switcher
+ZITADEL is a multi-tenant system. The Console features a **Context Switcher** in the **top-left** corner. This allows you to switch between the different **Organizations** you manage.
+
+Depending on your use case:
+* **B2C:** You might stick to your global organization.
+* **B2B:** You will frequently switch between multiple organizations to manage specific customer settings.
+
+<img
+  src="/docs/img/guides/console/contextswitcher.png"
+  alt="Context switcher"
+  width="400px"
+/>
+
+To understand how to structure your organizations, read our [Solution Scenario](/docs/guides/solution-scenarios/configurations) guides.
+
+## Key Capabilities
+
+The Console enables administrators to perform the following critical tasks:
+
+1.  **Default Settings:** Managers can configure global system defaults. This includes authentication methods, security policies (like password complexity or lockout policies), and other system-wide parameters.
+2.  **Resource Management:** Create, update, and delete essential resources such as [Organizations](./organizations-overview), [Projects](./projects-overview), and [Applications](./applications-overview).
+3.  **User Management:** Manage the lifecycle of [User accounts](./users-overview). This includes creating new users, updating profiles, resetting passwords, and deactivating accounts.
+4.  **Access Control:** Define and manage permissions. Administrators can assign [Roles](/docs/guides/manage/console/roles) to users and configure fine-grained access controls for specific resources.
+5.  **Manager Assignment:** Delegate administrative tasks by assigning **Manager** roles (e.g., Org Owner, Project Owner) to specific users, ensuring proper oversight and segregation of duties.
+6.  **Customization and Branding:** Customize the look and feel of ZITADEL. You can upload custom logos, select color schemes, and apply [branding](/docs/guides/manage/customize/branding) to match your corporate identity.
+7.  **Audit Logging:** Access [Audit Logs](/docs/concepts/features/audit-trail) to track user activity and configuration changes. This is essential for monitoring security events and maintaining regulatory compliance.
+
+## Security and Restrictions
+
+### Prevent Console Access
+In many implementations, specifically white-label B2C scenarios, you may want to prevent end-users from accessing the generic ZITADEL Console entirely.
+
+Administrators can restrict access to the console, forcing users to interact only with your own applications or custom user interfaces.
+Please follow the [Restrict Console Access guide](/docs/guides/solution-scenarios/restrict-console) to achieve this.
+
+## References
+
+* [Manager Roles Concept](/docs/concepts/structure/managers)
@@ -0,0 +1,155 @@
+---
+title: Organizations
+sidebar_label: Organizations
+---
+
+## Overview
+
+ZITADEL is organized around the idea of multi-tenancy. An **Organization** is the vessel where your projects and users live. It is comparable to a tenant in a SaaS system or an organizational unit (OU) in a directory-based system.
+
+Key characteristics of Organizations in ZITADEL include:
+
+* **Multi-tenancy:** Multiple organizations can be managed within one [instance](/concepts/structure/instance).
+* **Isolation:** Users and data from one organization are separated from others.
+* **Delegation:** Organizations can grant each other rights to self-manage certain aspects of the IAM (e.g., roles for access management).
+
+In a B2B use case, an organization typically represents a business partner who requires their own branding, specific access settings, or distinct federated login providers.
+
+![Overview ZITADEL Organizations](/img/concepts/objects/organization.png)
+
+## Structure and Delegation
+
+### Projects within Organizations
+You can use **Projects** within your organization to manage the security context of closely related components, such as roles, grants, and authorizations for multiple clients. You can set up multiple projects within a single organization.
+
+### Organization Grants
+ZITADEL allows you to give *other* organizations permission to manage certain aspects of a project within *your* organization.
+
+For example, you could set up a project with roles that define access to your software, but allow a partner organization to allocate those roles to their own users independently. As a service provider, this allows you to establish a self-service culture for your business customers.
+
+![Organization Grant](/img/concepts/objects/organization_grants.png)
+
+## Managing Organizations
+
+### Create a new organization
+
+To create a new organization, click on the organizations dropdown in the Console and select **New organization**.
+
+You have two options regarding the initial administrator:
+1.  **Current User:** Create the organization with your currently logged-in user as the organization manager. A membership for the new organization will be added to your account.
+2.  **New Account:** Directly create a new account to manage the organization.
+
+<img
+  width="400px"
+  src="/docs/img/console_org_select.png"
+  alt="Select Organization"
+/>
+
+### Self-Service Registration
+If you want to enable your customers to create organizations themselves, ZITADEL provides a built-in registration form at:
+`https://$CUSTOM-DOMAIN/ui/login/register/org`
+
+The customer simply fills in the organization name and contact details to get started.
+
+<img
+  width="400px"
+  src="/docs/img/console_org_register.png"
+  alt="Register new organization"
+/>
+
+### Default Organization
+On the **Default settings** page (`${CUSTOM_DOMAIN}`/ui/console/orgs), you can designate a specific organization as the "Default".
+* Click the **...** on the right-hand side of the table and select **Set as default organization**.
+* The current default is marked by a "Default" label.
+
+When no specific organization is selected (e.g., during an auth request or via [Domain Discovery](/docs/guides/solution-scenarios/domain-discovery)), users are directed to this default organization for login and self-registration.
+
+## Usernames and Domains
+
+Each organization has its own pool of users, covering both human and service users. How these users authenticate depends on your domain configuration.
+
+### Login Name Formats
+By default, if the setting **User Loginname must contain orgdomain** is **disabled**, usernames are unique across the entire instance.
+
+If you require usernames to be scoped to the organization (common in multi-tenant setups), you can enable **User Loginname must contain orgdomain** in your [Domain settings](./default-settings#domain-settings). Login names will then follow the format:
+
+`{username}@{domainname}.{zitadeldomain}`
+
+**Example:**
+If a user has the username `john.doe` in an organization with the domain `acme`, the generated login name is:
+`[email protected]`
+
+### Custom Domain Names
+You can verify your own domain names (e.g., `acme.ch`) to simplify the user experience. Once verified:
+1.  ZITADEL generates additional login names for users.
+2.  The user `john.doe` can log in via `[email protected]` OR `[email protected]`.
+
+:::info
+Only one user with the username `john.doe` can exist within the organization `ACME`, regardless of which domain suffix they use to log in.
+:::
+
+### Primary Domain
+An organization can have multiple domain names, but only one is **Primary**. The primary domain determines:
+* Which login name is displayed to the user in the UI.
+* What information is asserted in `access_tokens` (specifically the `preferred_username` claim).
+
+:::caution
+Setting a Primary Domain affects users.
+If a user `coyote` exists in the global organization with the login name `[email protected]`, and you subsequently verify `acme.ch` for a specific organization, the global user's login name will be replaced with `coyote@{randomvalue.tld}`. ZITADEL will notify users affected by this change.
+:::
+
+## Domain Verification Guide
+
+If the **validate org domains** setting in [Domain Settings](./default-settings#domain-settings) is set to `true`, you must prove ownership of your domain via DNS or HTTP challenge.
+
+:::info
+You can disable domain verification requirements in the [default settings](/docs/guides/manage/console/default-settings#domain-settings) if you are running a self-hosted instance and do not require strict validation.
+:::
+
+1.  Navigate to your **Organization Settings**.
+2.  Select the menu entry **Verified domains**.
+3.  Click on the domain name you wish to verify. A dialog will appear offering DNS or HTTP challenge methods.
+
+<img
+  width="400px"
+  src="/docs/img/console_verify_domain.png"
+  alt="Verify Domain Dialog"
+/>
+
+4.  **DNS Challenge Example:** Create a TXT record with your DNS provider using the value provided by ZITADEL.
+    * [Cloudflare Guide](https://www.zoho.com/mail/help/adminconsole/cloudflare.html#alink1)
+    * [Squarespace Guide](https://support.squarespace.com/hc/en-us/articles/205812388-Domain-verification-with-a-TXT-Record-alternative-method-)
+    * [Name.com Guide](https://www.name.com/support/articles/115004972547-adding-a-txt-record)
+    * [EasyDNS Guide](https://kb.easydns.com/knowledge/how-to-make-a-dns-entry/)
+
+5.  Once verified, click **Verify**.
+6.  (Optional) Click **Set as primary** to make this the default domain for user login names.
+
+:::caution
+Do not delete the DNS verification record after success. ZITADEL re-checks domain ownership periodically.
+:::
+
+## Organization Settings
+
+Organizations can inherit configuration from the instance defaults or override them with specific policies. Settings configured at the Organization level take priority over Default settings.
+
+* [**Login Behavior and Access**](./default-settings#login-behavior-and-access): MFA options, passwordless authentication rules, and session lifetimes.
+* [**Identity Providers**](./default-settings#identity-providers): Configure IDPs available specifically for this organization.
+* [**Password Complexity**](./default-settings#password-complexity): Specific requirements for passwords (length, symbols, etc.).
+* [**Lockout**](./default-settings#lockout): Max login attempts before an account is locked.
+* [**Branding**](./default-settings#branding): Custom appearance for the login interface.
+* [**Message Texts**](./default-settings#message-texts): Custom text and internationalization for emails.
+* [**Login Interface Texts**](./default-settings#login-interface-texts): Custom text for the login UI.
+* [**External Links**](./default-settings#external-links): Links to your specific Terms of Service, Privacy Policy, and Support.
+
+### Applying Custom Branding
+To apply a custom design (e.g., for a specific B2B customer):
+1.  Navigate to the Organization settings.
+2.  Configure the **Branding** section.
+3.  Ensure the **Login Behavior** on your **Project** is configured to allow organization-specific branding. Read more about project branding [here](./projects-overview#branding).
+
+### Triggering Organization Context
+By default, the ZITADEL Login uses the instance default settings. To trigger the specific settings (and branding) of an organization, you must provide the organization scope in your authentication request:
+
+```bash
+urn:zitadel:iam:org:id:{id}
@@ -0,0 +1,138 @@
+---
+title: Organize applications, services, and roles with projects
+sidebar_label: Projects
+sidebar_position: 4
+---
+
+import ProjectDescription from "../../../concepts/structure/_project_description.mdx";
+
+## What is a project?
+
+<ProjectDescription name="ProjectDescription" />
+
+A Project is the vessel that holds your Applications and Roles. It defines the security context for a specific software solution.
+
+### Example Scenario
+Imagine you are building a **Point of Sales (POS)** platform. In ZITADEL, you would create one Project (e.g., named `POS`).
+* **Applications:** Your web portal for administration, your iOS app, and your Android app would all be defined as **Applications** within this single Project.
+* **Roles:** You would create **Roles** (e.g., `admin`, `cashier`, `viewer`) inside this Project.
+* **Authorization:** All applications in this project share these roles, allowing you to create unified authorizations for your users across all platforms.
+
+![POS Project](/img/guides/console/posproject.png)
+
+## Core Components
+
+### Applications
+Applications define the different clients (web apps, native mobile apps, server-side APIs) that share the same roles and security context.
+At the moment, we support OIDC and almost every OAuth2 client. We'll be expanding this with SAML shortly.
+Go to [Applications](./applications-overview) for more details.
+
+### Roles
+A role consists of different attributes, but only the **Key** is relevant to the authorization and must be unique within the project.
+* **Key:** The identifier used in code (e.g., `role.admin`).
+* **Display Name:** A human-readable name for the UI.
+* **Group:** Enables better handling in the ZITADEL console (e.g., giving a user all roles of a specific group).
+
+Read more about managing roles [here](./roles).
+
+## The Default Project
+When creating a new ZITADEL instance, you will find an automatically created project in the first organization.
+This **Default Project** (named "ZITADEL") protects the ZITADEL Management Console and APIs.
+
+:::caution
+We do not recommend changing any settings in the Default Project or using it for your own applications, as this could influence the behavior of ZITADEL itself.
+:::
+
+![Default Project](/img/guides/solution-scenarios/console-default-project.png)
+
+## Create a Project
+
+To create a project:
+1.  Navigate to your Organization in the Console.
+2.  Go to **Projects** (or visit `https://${CUSTOM_DOMAIN}.zitadel.cloud/ui/console/projects`).
+3.  Click the **Create New Project** button.
+
+<img
+  alt="Empty Project"
+  src="/docs/img/console_projects_empty.png"
+  width="270px"
+/>
+
+4.  Enter your project name and continue.
+
+## Granted Projects (B2B)
+
+A powerful feature of ZITADEL is the ability to **Grant** a project to other organizations. This is essential for B2B scenarios where you sell your software to business partners.
+
+* **The Concept:** You enable another organization to use your Project.
+* **Delegation:** The granted organization can manage the authorizations of *their own users* for your project. They can assign the roles you defined to their employees without your intervention.
+* **Isolation:** You can select specifically which roles are available to the granted organization. This allows you to restrict features (e.g., "Premium" roles) per customer.
+
+Using the POS example above: You could grant the `POS` project to a partner organization. That partner can then log in with their own domain, use their own branding, and manage their own cashier users, all while using your underlying application structure.
+
+<img
+  alt="Granted project"
+  src="/docs/img/guides/console/grantedprojectgrid.png"
+  width="320px"
+/>
+
+### How to Grant a Project
+
+1.  Navigate to the Project you want to share (e.g., `POS`).
+2.  In the **Grants** section, click **New**.
+
+<img src="/docs/img/guides/console/grantsmenu.png" alt="Grants" width="170px" />
+
+3.  Enter the **Domain** of the partner organization you want to grant access to.
+    * *Tip: If you don't know the domain, navigate to the Organization detail page to find it.*
+4.  Search and select the organization.
+5.  Select the **Roles** you want to grant to this organization and click **Save**.
+
+## Project Settings
+
+You can customize the behavior of your project, particularly regarding how login screens look and how tokens are issued.
+
+### Branding
+If you have different designs for your organizations (Private Labeling), you can define the login behavior on the project detail page.
+
+<img
+  src="/docs/img/guides/console/projectbranding.png"
+  alt="Project branding"
+  width="400px"
+/>
+
+| Setting | Description |
+| :--- | :--- |
+| **Unspecified** | If nothing is specified, the system default settings will trigger. |
+| **Enforce project's policy** | This forces the branding of the organization that *owns* the project throughout the entire login process. Useful if you want your users to always see *your* brand, even if they belong to a partner org. |
+| **Allow login user policy** | The login starts with the project's branding. However, as soon as the user is identified (e.g., by entering their email), the branding switches to match the user's organization. |
+
+In a B2B use case, you would typically use **Allow login user policy**. If you want to skip the detection step, you can preselect an organization using the [primary domain scope](/apis/openidoauth/scopes#reserved-scopes) (e.g., `urn:zitadel:iam:org:domain:primary:{domainname}`).
+
+### Role Settings
+You can configure strict security checks regarding roles during authentication.
+
+<img
+  src="/docs/img/guides/console/rolesettings.png"
+  width="700px"
+  alt="Role settings"
+/>
+
+* **Assert Roles on Authentication:** Role information is sent from the Userinfo endpoint (and in tokens, depending on app settings).
+* **Check authorization on Authentication:** Users are **only** allowed to login if they have at least one role assigned for this project. If they have no roles, access is denied immediately.
+* **Check for Project on Authentication:** Checks if the user's organization actually has a grant for this project. If not, the user cannot be authenticated.
+
+### Roles in Tokens
+If you want roles to appear directly inside your Access or ID Tokens (to avoid calling the Userinfo endpoint), you must enable this per application.
+
+1.  Navigate to your **Application**.
+2.  Open **Token Settings**.
+3.  Check **Assert Roles on Authentication**.
+
+<img
+  src="/docs/img/guides/console/tokenroles.png"
+  width="700px"
+  alt="Roles in token"
+/>
+
+You can learn more about Application and Token settings [here](./applications-overview).
@@ -0,0 +1,107 @@
+---
+title: Users
+sidebar_label: Users
+sidebar_position: 3
+---
+
+import CreateUser from './_create-user.mdx';
+
+## Overview
+
+ZITADEL supports authentication and authorization for different user types. We mainly differentiate between **Human Users** (interactive) and **Service Users** (machine-to-machine).
+
+<img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />
+
+## Types of Users
+
+### Human Users
+Human users represent actual people who log in via an interactive interface (e.g., a login page).
+* **Profile:** Has an email address, password, and optional profile data (phone, nickname, gender, language).
+* **Authentication:** Can authenticate via password, multiple factors (MFA), or passwordless authentication (Passkeys).
+* **Flow:** The application redirects the user to ZITADEL, which handles the credentials and issues a token to the application.
+
+Read more on how to [login users with ZITADEL](/docs/guides/integrate/login/login-users).
+
+### Service Users (Machine Accounts)
+Service users represent machines, backend services, or IoT devices requiring non-interactive access.
+* **Profile:** Only has a name, description, and username.
+* **Authentication:** Authenticates via **JWT Profile** or **Personal Access Tokens (PAT)**. Both methods support expiration settings.
+* **Usage:** Primarily used to gain access to the ZITADEL Management API or to secure backend-to-backend communication.
+
+To see how service users are utilized in practice, check out our [NextJS B2B Demo application](https://github.com/zitadel/zitadel-nextjs-b2b).
+
+### Federated Users
+Federated users are identities managed by a third-party Identity Provider (IdP) such as Google, Azure AD, or GitHub.
+* **Identity Brokering:** Users log in via the external IdP ("Single Sign-On").
+* **Account Linking:** Federated identities are [linked](../../../concepts/features/account-linking) to internal ZITADEL users to facilitate role assignment and audit trails.
+
+### External Users
+In a multi-tenancy architecture, users are typically isolated within [Organizations](./organizations-overview).
+However, using [External User Grants](../../../concepts/features/external-user-grant), an organization can invite users from *another* organization to access their projects. These invited users are referred to as **External Users** within the context of the inviting organization.
+
+### Managers
+Any user—whether Human or Service User—can be assigned a [Manager Role](/concepts/structure/managers).
+A user with a manager role is not just an end-user of your application but also has permissions to manage specific aspects of the ZITADEL instance, organization, or project (e.g., `ORG_OWNER`, `PROJECT_OWNER`).
+
+## Considerations
+
+### Uniqueness of Users
+* **Scope:** Users exist strictly within **one** [Organization](./organizations-overview). It is currently not possible to move users between organizations.
+* **Identifier:** User accounts are uniquely identified by their `id` or their `loginname` combined with the `organization domain` (e.g., `[email protected]`).
+* **Emails:** You can reuse the same email address for different user accounts across organizations.
+
+### Structuring User Pools
+How you organize users depends on your scenario:
+
+* **B2B / Multi-Tenancy:** We recommend creating separate organizations for each business customer (e.g., based on their domain). Grant your projects to these organizations so they can manage their own users.
+* **B2C / CIAM:** You might want to store all users in a single organization and enable a specific set of social logins for that organization.
+
+:::info
+You can only verify a domain (e.g., `acme.com`) on **one** organization. If multiple teams share the same email domain but need separate management, they might need to be consolidated into a single organization.
+:::
+
+### Hierarchy
+ZITADEL does not enforce a native hierarchy or inheritance for users or organizations. We recommend structuring users along the smallest unit of groups (Organizations). You can use organization metadata or your own business logic to map complex hierarchies if needed.
+
+## Managing Users
+
+### Create User
+
+<CreateUser/>
+
+### Metadata
+ZITADEL provides a key-value storage system for users, which is essential for building complex applications.
+
+**Example Use Case:**
+In a Point of Sales application, you could add a `stripeCustomerId` as a metadata key to a user. Your client application can then read this metadata to fetch payment details directly from the Stripe API.
+
+<img
+  width="460px"
+  src="/docs/img/guides/console/usermetadata.png"
+  alt="User Metadata"
+/>
+
+**Accessing Metadata:**
+Metadata can be requested via the Auth and Management APIs, the Userinfo endpoint, or asserted directly into the ID Token.
+
+1.  **Userinfo Endpoint:** Add the scope `urn:zitadel:iam:user:metadata` to your authentication request.
+2.  **ID Token:** To include metadata in the token, navigate to your **Application Settings** and toggle **User Info inside ID Token**.
+
+<img
+  src="/docs/img/guides/console/appidtokensettings.png"
+  width="650px"
+  alt="ID Token settings"
+/>
+
+### Authorizations
+User authorizations (roles) are displayed on user profile pages.
+
+To access these roles in your application:
+* **Userinfo Endpoint:** Check the **Assert roles on authentication** box in your [Project Settings](./roles#authorizations).
+* **ID Token:** Toggle **User roles inside ID Token** in your [Application Settings](./applications-overview).
+
+## References
+
+- [Manage users in the Console](./users-overview#managing-users)
+- [Migrate to ZITADEL](/docs/guides/migrate/introduction)
+- [User onboarding and registration](/docs/guides/integrate/onboarding)
@@ -50,4 +50,4 @@ New users automatically are assigned a role now if they register by authenticati
 ## What's next?

 - [Read more about the concepts around actions](/concepts/features/actions)
- [Read more about all the options you have with actions](/apis/actions/introduction)
+- [Read more about all the options you have with actions](/guides/manage/console/actions-overview)
@@ -12,7 +12,7 @@ You can read more about the basic structure and important concepts of ZITADEL in

 ## Multi-tenancy architecture

-Multi-tenancy in ZITADEL can be achieved through either [Instances](/docs/concepts/structure/instance) or [Organizations](/docs/concepts/structure/organizations).
+Multi-tenancy in ZITADEL can be achieved through either [Instances](/docs/concepts/structure/instance) or [Organizations](/docs/guides/manage/console/organizations-overview).
 Where instances represent isolated ZITADEL instances, Organizations provide a more permeable approach to multi-tenancy.

 In most cases, when you want to achieve multi-tenancy, you use Organizations. Each organization can have their own set of Settings (eg, Security Policies, IDPs, Branding), Managers, and Users.
@@ -23,14 +23,14 @@ Please also consult our guide on [Solution Scenarios](/docs/guides/solution-scen
 Some solutions, that offer multi-tenancy, require you to copy applications and settings to each tenant and manage changes individually.
 ZITADEL works differently by using [Granted Projects](/docs/concepts/structure/granted_projects).

-Projects can be granted to [Organization](/docs/concepts/structure/projects#granted-organizations) or even to individual users.
+Projects can be granted to [Organization](/docs/guides/manage/console/organizations-overview#organization-grants) or even to individual users.
 You can think of it as a logical link to a Project, which can be used by the receiving Organization or User as if it was their own project, except privileges to modify the Project itself.

 Delegated access management is a great way of keeping the management overhead low and enabling [self-service](/docs/concepts/features/selfservice#managers-in-delegation) for Organizations to manage their own Settings and Authorizations.

 ## Actions

-ZITADEL [Actions](/docs/apis/actions/introduction) is the key feature to customize and create workflows and change the default behavior of the platform.
+ZITADEL [Actions](/docs/guides/manage/console/actions-overview) is the key feature to customize and create workflows and change the default behavior of the platform.

 You define custom code that should be run on a specific Trigger.
 A trigger could be the creation of a new user, getting profile information about a user, or a login attempt.
@@ -69,7 +69,7 @@ See the [User guide](./users.md) for batch migration of users.

 In case all your applications depend on ZITADEL after the migration date, and ZITADEL is able to retrieve the required user information, including secrets, from the legacy system, then the recommended way is to let **ZITADEL orchestrate the user migration just-in-time**:

- Create a pre-authentication [Action](/docs/apis/actions/introduction) to request user data from the legacy system and create a new user in ZITADEL.
+- Create a pre-authentication [Action](/docs/guides/manage/console/actions-overview) to request user data from the legacy system and create a new user in ZITADEL.
 - Optionally, create a post-authentication Action to flag successfully migrated users in your legacy system

 For all other cases, we recommend that the **legacy system orchestrates the migration** of users to ZITADEL for more flexibility:
@@ -24,7 +24,7 @@ The migration tool is written in Go. Download and install the latest version of
 You'll need a target organization in ZITADEL to import your users. You can create a new organization or use an existing one.  

 If you don't have a ZITADEL instance, you can [sign up for free here](https://zitadel.com) to create a new one for you.  
-See: [Managing Organizations in ZITADEL](https://zitadel.com/docs/guides/manage/console/organizations).
+See: [Managing Organizations in ZITADEL](https://zitadel.com/docs/guides/manage/console/organizations-overview).

 > **Note:** Copy your Organization ID (Resource ID) since you will use the id in the later steps.

@@ -28,7 +28,7 @@ The migration tool is written in Go. Download and install the latest version of
 You'll need a target organization in ZITADEL to import your users. You can create a new organization or use an existing one.

 If you don't have a ZITADEL instance, you can [sign up for free here](https://zitadel.com) to create a new one for you.
-See: [Managing Organizations in ZITADEL](https://zitadel.com/docs/guides/manage/console/organizations).
+See: [Managing Organizations in ZITADEL](https://zitadel.com/docs/guides/manage/console/organizations-overview).

 > **Note:** Copy your Organization ID (Resource ID) since you will use the id in the later steps.

@@ -9,7 +9,7 @@ import { B2B } from "../../../src/components/b2b";

 B2B describes the situation where an organization interacts with other organizations.
 This **multi-tenancy architecture** usually adds some form of complexity to an Identity and Access Management System.
-In ZITADEL an [organization](/docs/concepts/structure/organizations) can represent a business partner or partner who typically has its own branding and has different access settings like an additional federated login for its users.
+In ZITADEL an [organization](/docs/guides/manage/console/organizations-overview) can represent a business partner or partner who typically has its own branding and has different access settings like an additional federated login for its users.

 B2B can be a simple scenario where an organization only shares one of its projects with another organization or have a more complex case where an organization is offering a portal application to all its partners with included (self)administration.

@@ -42,7 +42,7 @@ In order to define the need of the **Portal Application** some planning consider
 ### Login

 You can decide whether a organization is preselected for the login or if the user is redirected to the default login screen. Using OpenID Connect, you can send the user to a specific organization by defining the organization in a [reserved scope](/docs/apis/openidoauth/scopes#reserved-scopes) (primary domain).
-Settings to the branding or the login options of the organization can be made from the organization section in [Console](/docs/concepts/features/console).
+Settings to the branding or the login options of the organization can be made from the organization section in [Console](/docs/guides/manage/console/console-overview).
 The behavior of the login branding can be set in your projects detail page. You can choose the branding of the selected organization, the user's organization, or the project's organization.

 ### Organizations
@@ -27,13 +27,13 @@ Read more about how to set the default redirect URI: [Settings - Default Redirec

 ### Restricting Console in default-project

-With this workaround, you will limit users from accessing the [default-project](/docs/concepts/structure/projects#default-project), if they are not explicitly granted to use this project.
+With this workaround, you will limit users from accessing the [default-project](/docs/guides/manage/console/projects-overview#the-default-project), if they are not explicitly granted to use this project.
 When setting the "Check for Project on Authentication" setting on a project, only users of organizations with a grant to that project can access it.
 By default, this setting is disabled, so all users can access the project.

 ![Project Settings: Check for Project on authentication](/img/guides/solution-scenarios/console-check-project-auth.png)

-Start by granting the organization of your managers, that should be able to access the Console, the [default project](/docs/concepts/structure/projects#default-project):
+Start by granting the organization of your managers, that should be able to access the Console, the [default project](/docs/guides/manage/console/projects-overview#the-default-project):

 1. Click on the default-project > Grants > New +
   ![Project Settings: Default Project - Grants](/img/guides/solution-scenarios/console-zitadel-project-grants.png)
@@ -44,7 +44,7 @@ Start by granting the organization of your managers, that should be able to acce
 3. You can skip the screen with the role selection, and click save
 4. Make sure the grant is in now in the overview and marked as active.

-To avoid accidental lock-out, the [default project](/docs/concepts/structure/projects#default-project) hides the checkbox "Check Project on Authentication" in the Console:
+To avoid accidental lock-out, the [default project](/docs/guides/manage/console/projects-overview#the-default-project) hides the checkbox "Check Project on Authentication" in the Console:
 ![Default Project](/img/guides/solution-scenarios/console-default-project.png)

 You need to use the [update project API call](/docs/apis/resources/mgmt/management-service-update-project) to set the configuration on the project.
@@ -33,22 +33,22 @@ The application includes complete [logout functionality](https://zitadel.com/doc

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:4321/api/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:4321/api/auth/logout/callback`)
 5. Copy your **Client ID** from the application details

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/):

 1. Clone the [repository](https://github.com/zitadel/example-auth-astro).
-2. Create a `.env` file based on `.env.example` and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). Use these environment variable names exactly as shown:
+2. Create a `.env` file based on `.env.example` and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). Use these environment variable names exactly as shown:
   ```
   PORT=4321
   SESSION_DURATION=3600
@@ -33,22 +33,22 @@ Sign-out functionality implements **[federated logout](https://zitadel.com/docs/

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/overview)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/console-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/):

 1. Clone the [repository](https://github.com/zitadel/example-auth-express).
-2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). Use the exact environment variable names from the repository:
+2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). Use the exact environment variable names from the repository:
   ```
   NODE_ENV=development
   PORT=3000
@@ -33,23 +33,23 @@ The application also demonstrates proper **[federated logout](https://zitadel.co

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [ZITADEL Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [ZITADEL Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [ZITADEL project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [ZITADEL project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000`)
 5. Copy your **Client ID** for use in the next steps
 6. Optionally enable [refresh tokens](https://zitadel.com/docs/concepts/tokens) in Token Settings for long-lived sessions

-> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [ZITADEL application](https://zitadel.com/docs/guides/integrate/login/oidc/) configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-fastify).
-2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [ZITADEL application](https://zitadel.com/docs/guides/manage/console/overview). **Use these exact environment variable names:**
+2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [ZITADEL application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use these exact environment variable names:**
   ```
   NODE_ENV=development
   PORT=3000
@@ -63,7 +63,7 @@ Once you have your [ZITADEL application](https://zitadel.com/docs/guides/integra
   ZITADEL_POST_LOGOUT_URL=http://localhost:3000
   ```
   Replace these values with:
-	- Your actual [ZITADEL instance URL](https://zitadel.com/docs/guides/manage/console/overview) for `ZITADEL_DOMAIN` (the issuer)
+	- Your actual [ZITADEL instance URL](https://zitadel.com/docs/guides/manage/console/console-overview) for `ZITADEL_DOMAIN` (the issuer)
 	- The **Client ID** you copied when creating the application for `ZITADEL_CLIENT_ID`
 	- The **redirect URI** you configured in the PKCE setup for `ZITADEL_CALLBACK_URL` (must match exactly)
 	- The **post-logout redirect URI** for `ZITADEL_POST_LOGOUT_URL`
@@ -31,22 +31,22 @@ The implementation uses [Handlebars templates](https://handlebarsjs.com/) for se

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your Zitadel application configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-hono).
-2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). **Use the exact environment variable names from the repository:**
+2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use the exact environment variable names from the repository:**
   ```
   NODE_ENV=development
   PORT=3000
@@ -35,7 +35,7 @@ All protected routes are secured using the [@mridang/nestjs-auth global guard](h

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

 1. Create a new Web application in your Zitadel project
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
@@ -50,7 +50,7 @@ Before running this example, you need to create and configure a PKCE application
 Once you have your Zitadel application configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-nestjs).
-2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). **Use the exact environment variable names from the repository:**
+2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use the exact environment variable names from the repository:**
   ```
   NODE_ENV=development
   PORT=3000
@@ -31,9 +31,9 @@ The example implements secure [session management](https://zitadel.com/docs/conc

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/api/auth/callback/zitadel` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/`)
@@ -46,7 +46,7 @@ Before running this example, you need to create and configure a PKCE application
 Once you have your Zitadel application configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-nuxtjs).
-2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). **Use these exact environment variable names:**
+2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use these exact environment variable names:**
 ```
   PORT=3000
   SESSION_DURATION=3600
@@ -59,7 +59,7 @@ Once you have your Zitadel application configured:
   AUTH_ORIGIN=http://localhost:3000
 ```
 Replace these values with:
-   - Your actual Zitadel instance URL (the **Issuer** from your [ZITADEL instance settings](https://zitadel.com/docs/guides/manage/console/overview))
+   - Your actual Zitadel instance URL (the **Issuer** from your [ZITADEL instance settings](https://zitadel.com/docs/guides/manage/console/console-overview))
   - The **Client ID** you copied when creating the application
   - A randomly generated **NUXT_AUTH_SECRET** for session encryption (generate using: `node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"`)
   - The **callback URI** you configured in the PKCE setup (must match exactly)
@@ -23,7 +23,7 @@ This example uses **[@auth/qwik](https://www.npmjs.com/package/@auth/qwik)**, a

 This [Qwik](https://qwik.dev) application showcases a complete authentication implementation using [ZITADEL](https://zitadel.com/docs) with the [Authorization Code Flow with PKCE](/docs/concepts/pkce). The example includes secure sign-in functionality that redirects users to ZITADEL's hosted login page, handles the OAuth callback to exchange authorization codes for [access tokens](https://zitadel.com/docs/concepts/tokens), and manages [sessions](https://zitadel.com/docs/concepts/sessions) with [JWT tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#json-web-token-jwt-profile) stored in encrypted server-side cookies.

-Route protection is implemented using [Qwik City's](https://qwik.dev/docs/qwikcity) `onRequest` handler, which performs server-side authentication checks before rendering protected pages. Unauthenticated users attempting to access secured routes are automatically redirected to the login page with a callback URL to return them to their intended destination after successful authentication. The application displays comprehensive user profile information including standard [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name and email, as well as ZITADEL-specific claims such as [organization membership](https://zitadel.com/docs/guides/manage/console/organizations) and [project roles](https://zitadel.com/docs/guides/manage/console/projects).
+Route protection is implemented using [Qwik City's](https://qwik.dev/docs/qwikcity) `onRequest` handler, which performs server-side authentication checks before rendering protected pages. Unauthenticated users attempting to access secured routes are automatically redirected to the login page with a callback URL to return them to their intended destination after successful authentication. The application displays comprehensive user profile information including standard [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name and email, as well as ZITADEL-specific claims such as [organization membership](https://zitadel.com/docs/guides/manage/console/organizations-overview) and [project roles](https://zitadel.com/docs/guides/manage/console/projects-overview).

 Sign-out functionality implements **[federated logout](https://zitadel.com/docs/guides/integrate/login/oidc/logout)** through ZITADEL's end-session endpoint, ensuring that users are logged out from both the application and ZITADEL's [single sign-on session](https://zitadel.com/docs/concepts/sessions). The logout process includes [CSRF protection](https://zitadel.com/docs/guides/integrate/login/oidc/logout#csrf-protection) using state parameters validated through secure cookies, followed by proper cleanup of session data and redirection back to the application.

@@ -33,22 +33,22 @@ Sign-out functionality implements **[federated logout](https://zitadel.com/docs/

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [Zitadel application](https://zitadel.com/docs/guides/integrate/login/oidc/) configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-qwik).
-2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview):
+2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview):
   ```
   VITE_PORT=3000
   VITE_SESSION_SECRET=your-very-secret-and-strong-session-key
@@ -33,7 +33,7 @@ The example leverages [React Router](https://reactrouter.com) for client-side na

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

 1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/integrate/login/oidc/)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
@@ -41,14 +41,14 @@ Before running this example, you need to create and configure a PKCE application
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your Zitadel application configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-react).
-2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). **Use these exact environment variable names:**
+2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use these exact environment variable names:**
 ```
 VITE_ZITADEL_DOMAIN=https://your-instance.zitadel.cloud
 VITE_ZITADEL_CLIENT_ID=your_client_id_from_console
@@ -11,17 +11,17 @@ status: stable

 ## Overview

-[SolidStart](https://start.solidjs.com) is a full-stack web framework built on top of [SolidJS](https://solidjs.com) that enables you to create performant web applications with a modern development experience. This example demonstrates how to integrate **[Zitadel](https://zitadel.com/docs)** using the **[OAuth 2.0 PKCE flow](/docs/concepts/pkce)** to authenticate users securely and maintain [sessions](https://zitadel.com/docs/concepts/structure/users#sessions) across the app.
+[SolidStart](https://start.solidjs.com) is a full-stack web framework built on top of [SolidJS](https://solidjs.com) that enables you to create performant web applications with a modern development experience. This example demonstrates how to integrate **[Zitadel](https://zitadel.com/docs)** using the **[OAuth 2.0 PKCE flow](/docs/concepts/pkce)** to authenticate users securely and maintain [sessions](https://zitadel.com/docs/guides/manage/console/default-settings#login-lifetimes) across the app.

 #### Auth library

-This example uses **[@auth/solid-start](https://www.npmjs.com/package/@auth/solid-start)**, the SolidStart adapter for [Auth.js](https://authjs.dev), which builds on **[@auth/core](https://www.npmjs.com/package/@auth/core)**. Auth.js implements the [OpenID Connect (OIDC)](https://zitadel.com/docs/apis/openidoauth/endpoints) flow, manages [PKCE](/docs/concepts/pkce), performs [token exchange](https://zitadel.com/docs/apis/openidoauth/grant-types), and exposes helpers for [session state](https://zitadel.com/docs/concepts/structure/users#sessions). The example also uses **[openid-client](https://www.npmjs.com/package/openid-client)** ([GitHub](https://github.com/panva/node-openid-client)) for manual token refresh operations and logout URL construction.
+This example uses **[@auth/solid-start](https://www.npmjs.com/package/@auth/solid-start)**, the SolidStart adapter for [Auth.js](https://authjs.dev), which builds on **[@auth/core](https://www.npmjs.com/package/@auth/core)**. Auth.js implements the [OpenID Connect (OIDC)](https://zitadel.com/docs/apis/openidoauth/endpoints) flow, manages [PKCE](/docs/concepts/pkce), performs [token exchange](https://zitadel.com/docs/apis/openidoauth/grant-types), and exposes helpers for [session state](https://zitadel.com/docs/guides/manage/console/default-settings#login-lifetimes). The example also uses **[openid-client](https://www.npmjs.com/package/openid-client)** ([GitHub](https://github.com/panva/node-openid-client)) for manual token refresh operations and logout URL construction.

 ---

 ## What this example demonstrates

-This example shows a complete authentication implementation using [SolidStart](https://start.solidjs.com) with [Zitadel](https://zitadel.com/docs). Users start on a public landing page and click a login button to authenticate with Zitadel using the secure **[PKCE flow](/docs/concepts/pkce)**. The [Auth.js](https://authjs.dev) library handles the [OAuth 2.0](https://zitadel.com/docs/guides/integrate/login/oidc/oauth-recommended-flows) authorization code exchange and manages secure [session storage](https://zitadel.com/docs/concepts/structure/users#sessions) using encrypted [JWT tokens](https://zitadel.com/docs/concepts/tokens). After successful authentication, users are redirected to a protected profile page displaying their user information including [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name, email, and custom [Zitadel metadata](https://zitadel.com/docs/apis/openidoauth/claims#reserved-claims).
+This example shows a complete authentication implementation using [SolidStart](https://start.solidjs.com) with [Zitadel](https://zitadel.com/docs). Users start on a public landing page and click a login button to authenticate with Zitadel using the secure **[PKCE flow](/docs/concepts/pkce)**. The [Auth.js](https://authjs.dev) library handles the [OAuth 2.0](https://zitadel.com/docs/guides/integrate/login/oidc/oauth-recommended-flows) authorization code exchange and manages secure [session storage](https://zitadel.com/docs/guides/manage/console/default-settings#login-lifetimes) using encrypted [JWT tokens](https://zitadel.com/docs/concepts/tokens). After successful authentication, users are redirected to a protected profile page displaying their user information including [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name, email, and custom [Zitadel metadata](https://zitadel.com/docs/apis/openidoauth/claims#reserved-claims).

 The application implements automatic [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) to maintain long-lived sessions without requiring users to re-authenticate. When an [access token](https://zitadel.com/docs/concepts/tokens) expires, the refresh logic seamlessly exchanges the [refresh token](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) for new tokens in the background. [Route protection](https://start.solidjs.com/api/createAsync) is implemented using [SolidStart's server functions](https://start.solidjs.com/api/server$), ensuring only authenticated users can access sensitive areas. The logout flow implements [federated logout](https://zitadel.com/docs/guides/integrate/login/oidc/logout) with CSRF protection using state parameters, properly terminating both the local session and the Zitadel session before redirecting users back to the application.

@@ -31,22 +31,22 @@ The application implements automatic [token refresh](https://zitadel.com/docs/ap

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [Zitadel application](https://zitadel.com/docs/guides/integrate/login/oidc/) configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-solidstart).
-2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). Use the exact environment variable names from the repository:
+2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). Use the exact environment variable names from the repository:
   ```
   NODE_ENV=development
   PORT=3000
@@ -33,22 +33,22 @@ The logout flow implements **[federated logout](https://zitadel.com/docs/guides/

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`)
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your Zitadel application configured:

 1. Clone the [repository](https://github.com/zitadel/example-auth-sveltekit).
-2. Create a `.env.local` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview). **Use these exact environment variable names:**
+2. Create a `.env.local` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview). **Use these exact environment variable names:**
   ```
   SESSION_SECRET=your-very-secret-and-strong-session-key
   SESSION_DURATION=3600
@@ -33,22 +33,22 @@ The example includes secure sign-out functionality implementing **[federated log

 ### Prerequisites

-Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:
+Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the **[PKCE Application Setup guide](/docs/guides/integrate/login/oidc/pkce-setup)** to:

-1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/overview)
+1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/console-overview)
 2. Configure it to use the [PKCE authentication method](/docs/concepts/pkce)
 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development)
 4. Configure post-logout redirect URIs
 5. Copy your **Client ID** for use in the next steps

-> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.
+> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode.

 ### Run the example

 Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/), follow these steps:

 1. Clone the [repository](https://github.com/zitadel/example-auth-vuejs).
-2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/overview):
+2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/console-overview):
 ```
 VITE_ZITADEL_DOMAIN=https://your-instance.zitadel.cloud
 VITE_ZITADEL_CLIENT_ID=your_client_id_from_console
@@ -171,7 +171,7 @@ These settings typically change infrequently in production. ***Every*** request

 ### Milestones

-Milestones are used to track the administrator's progress in setting up their instance. Milestones are used to render *your next steps* in the [console](/docs/guides/manage/console/overview) landing page.
+Milestones are used to track the administrator's progress in setting up their instance. Milestones are used to render *your next steps* in the [console](/docs/guides/manage/console/console-overview) landing page.
 Milestones are reached upon the first time a certain action is performed. For example the first application created or the first human login. In order to push a "reached" event only once, ZITADEL must keep track of the current state of milestones by an eventstore query every time an eligible action is performed. This can cause an unwanted overhead on production servers, therefore they are cached.

 As an extra optimization, once all milestones are reached by the instance, an in-memory flag is set and the milestone state is never queried again from the database nor cache.
@@ -179,7 +179,7 @@ For single instance setups which fulfilled all milestone (*your next steps* in c

 ### Organization

-Most resources like users, project and applications are part of an [organization](/docs/concepts/structure/organizations). Therefore many parts of the ZITADEL logic search for an organization by ID or by their primary domain.
+Most resources like users, project and applications are part of an [organization](/docs/guides/manage/console/organizations-overview). Therefore many parts of the ZITADEL logic search for an organization by ID or by their primary domain.
 Organization objects are quite small and receive infrequent updates after they are created:

 - Change of organization name
@@ -227,7 +227,7 @@ DefaultInstance:
 ```

 - If you don't want to use the DefaultInstance configuration for the first instance that ZITADEL automatically creates for you during the [setup phase](/self-hosting/manage/configure#database-initialization), you can provide a FirstInstance YAML section using the --steps argument.
- Learn how to configure ZITADEL via the [Console user interface](/guides/manage/console/overview).
+- Learn how to configure ZITADEL via the [Console user interface](/guides/manage/console/console-overview).
 - Probably, you also want to [apply your custom branding](/guides/manage/customize/branding), [hook into certain events](/guides/manage/customize/behavior), [customize texts](/guides/manage/customize/texts) or [add metadata to your users](/guides/manage/customize/user-metadata).
 - If you want to automatically create ZITADEL resources, you can use the [ZITADEL Terraform Provider](/guides/manage/terraform-provider).

@@ -49,7 +49,7 @@ const features = [
              description=""
            />
            <ListElement
-              link="/docs/guides/manage/console/overview"
+              link="/docs/guides/manage/console/console-overview"
              type={ICONTYPE.LOGIN}
              title="Manage"
              description="All about Console"
@@ -183,7 +183,7 @@ const features = [
            description=""
          />
          <ListElement
-            link="/docs/apis/actions/introduction"
+            link="/docs/guides/manage/console/actions-overview"
            type={ICONTYPE.APIS}
            title="Actions"
            description="Customize and integrate ZITADEL into your landscape"
@@ -20,7 +20,10 @@
    }
  ],
  "redirects": [
-    { "source": "/", "destination": "/docs" },
+    {
+      "source": "/",
+      "destination": "/docs"
+    },
    {
      "source": "/docs/category/apis/:slug*",
      "destination": "/docs/apis/:slug*",
@@ -230,6 +233,66 @@
      "source": "/docs/legal/service-description/billing",
      "destination": "https://help.zitadel.com/pricing-and-billing-of-zitadel-services",
      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/overview",
+      "destination": "/docs/guides/manage/console/console-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/organizations",
+      "destination": "/docs/guides/manage/console/organizations-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/concepts/structure/organizations",
+      "destination": "/docs/guides/manage/console/organizations-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/projects",
+      "destination": "/docs/guides/manage/console/projects-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/concepts/structure/projects",
+      "destination": "/docs/guides/manage/console/projects-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/applications",
+      "destination": "/docs/guides/manage/console/applications-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/concepts/structure/applications",
+      "destination": "/docs/guides/manage/console/applications-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/users",
+      "destination": "/docs/guides/manage/console/users-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/concepts/structure/users",
+      "destination": "/docs/guides/manage/console/users-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/guides/manage/console/actions",
+      "destination": "/docs/guides/manage/console/actions-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/apis/actions/introduction",
+      "destination": "/docs/guides/manage/console/actions-overview",
+      "permanent": true
+    },
+    {
+      "source": "/docs/concepts/features/console",
+      "destination": "/docs/guides/manage/console/console-overview",
+      "permanent": true
    }
  ]
-}
+}