chore: rename configuration to settings (#11568)

# Which Problems Are Solved naming inconsistencies: Configuration <-> Settings # How the Problems Are Solved # Additional Changes # Additional Context - Closes #11282
2026-08-17 16:35:14 -05:00 · 2026-02-18 14:25:42 +01:00
parent 64065bbe3c
commit 699ed17918
129 changed files with 359 additions and 359 deletions
@@ -39,7 +39,7 @@ ZITADEL follows a strict hierarchical containment model. When generating code, l
 - **System (Installation):** The entire ZITADEL deployment. Global settings are applied through runtime configuration files or environment variables. See `cmd/defaults.yaml`.
 - **Instance (The "Identity System"):**
  - **Definition:** A logical partition/virtual tenant. It is a "System inside a System."
-  - **Isolation:** Data and configurations are strictly isolated between instances.
+  - **Isolation:** Data and settings are strictly isolated between instances.
  - **Translation Rule:** NEVER translate as "Example" or "Case." Use technical terms like "Tenant," "Environment," or the local equivalent of "Logical System Entity."
 - **Organization:** A group within an Instance. It owns Users, Projects, and Roles.
 - **Project:** A collection of Applications and Auth Policies within an Org.
@@ -96,7 +96,7 @@ We will showcase the new Login UI, provide insights into the application's archi

 * **Architecture of the Login UI**: Explore how server-side and client-side components interact within the new Login UI and NextJS framework.
 * **Session API**: Understand the workings of the Session API
-* **OIDC middleware configuration**: Learn how OIDC functions with the new Login UI and the necessary steps for a complete flow.
+* **OIDC middleware settings**: Learn how OIDC functions with the new Login UI and the necessary steps for a complete flow.
 * **Customization Options / Settings**: Discover how to personalize the login and which ZITADEL settings are implemented.
 * **Outlook**: Gain insights into future features
 * **Q&A**
@@ -65,7 +65,7 @@ All documentation content is located in the `content` directory. Note that the s

 To add a new page:
 1.  Create a `.mdx` file in the appropriate subdirectory of [`content`](./content).
-2.  Register the new page in the sidebar configuration at [`lib/sidebar-data.ts`](./lib/sidebar-data.ts) to make it accessible in the navigation.
+2.  Register the new page in the sidebar settings at [`lib/sidebar-data.ts`](./lib/sidebar-data.ts) to make it accessible in the navigation.


 ### Pull Requests
@@ -184,7 +184,7 @@ This object represents [the claims](../openidoauth/claims) which will be written
 - `email_verified` *bool*
 - `updated_at` *Number*

-There could be 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)
+There could be additional fields depending on the settings of your [project](../../guides/manage/console/projects-overview#role-settings) and your [application](../../guides/manage/console/applications-overview#token-settings)

 ## user grant list

@@ -19,7 +19,7 @@ TODO: describe the outcome of the test?
 | ZITADEL location                      |       |
 | ZITADEL container specification       | vCPU: <br/> Memory: Gb <br/>Container count: |
 | ZITADEL Version                       |       |
-| ZITADEL Configuration                 |       |
+| ZITADEL Settings                 |       |
 | ZITADEL feature flags                 |       |
 | Database                              | type: psql<br />version: |
 | Database location                     |       |
@@ -146,7 +146,7 @@ In v2, we have unified these into a single set of endpoints for all application
 The biggest change is in how you create/update applications.
 Instead of calling a specific endpoint for each type (e.g., CreateOidcApp, CreateSamlApp), you will now use a single CreateApp endpoint.

-To specify the type of application, you will include its specific configuration object within the request body.
+To specify the type of application, you will include its specific settings object within the request body.
 For example, to create a OIDC app, you will provide an oidc object in the request.
 All properties that are common to every application, such as name, are now top-level fields in the request body, consistent across all types.

@@ -11,5 +11,5 @@ The metrics endpoint can be scrubbed by any tool of choice that supports the `ot

 For our [Kubernetes/Helm](/self-hosting/deploy/kubernetes) users, we provide an out-of-the-box support for the [ServiceMonitor](https://github.com/zitadel/zitadel-charts/blob/main/charts/zitadel/templates/servicemonitor.yaml) custom resource.

-By default, metrics are enabled but can be turned off through ZITADEL's [configuration](/self-hosting/manage/configure).
-The (default) configuration is located in the [defaults.yaml](https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml).
+By default, metrics are enabled but can be turned off through ZITADEL's [settings](/self-hosting/manage/configure).
+The (default) settings are located in the [defaults.yaml](https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml).
@@ -158,10 +158,10 @@ the error will be display directly to the user on the auth server

 #### Possible errors
 | error_type                | Possible reason                                                                                                                                                                                                                                                                                    |
-| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | invalid_request           | The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.                                                                                                                                                  |
 | invalid_scope             | The requested scope is invalid. Typically the required `openid` value is missing.                                                                                                                                                                                                                  |
-| unauthorized_client       | The client is not authorized to request an access_token using this method. Check in Management Console that the requested `response_type` is allowed in your application configuration.                                                                                                                       |
+| unauthorized_client       | The client is not authorized to request an access_token using this method. Check in Management Console that the requested `response_type` is allowed in your application settings.                                                                                                                 |
 | unsupported_response_type | The authorization server does not support the requested response_type.                                                                                                                                                                                                                             |
 | server_error              | The authorization server encountered an unexpected condition that prevented it from fulfilling the request.                                                                                                                                                                                        |
 | interaction_required      | The authorization server requires end-user interaction of some form to proceed. This error MAY be returned when the prompt parameter value in the Authentication Request is none, but the Authentication Request cannot be completed without displaying a user interface for end-user interaction. |
@@ -15,7 +15,7 @@ The base URL for the SCIM endpoint in Zitadel is: `https://${CUSTOM_DOMAIN}/scim

 | Endpoint                                                                | Remarks                                                    |
 |-------------------------------------------------------------------------|------------------------------------------------------------|
-| `GET /scim/v2/{orgId}/ServiceProviderConfig`                            | Retrieve the configuration of the Zitadel service provider |
+| `GET /scim/v2/{orgId}/ServiceProviderConfig`                            | Retrieve the settings of the Zitadel service provider |
 | `GET /scim/v2/{orgId}/Schemas`                                          | Retrieve all supported schemas                             |
 | `GET /scim/v2/{orgId}/Schemas/{id}`                                     | Retrieve a known supported schema                          |
 | `GET /scim/v2/{orgId}/ResourceTypes`                                    | Retrieve all supported resource types                      |
@@ -781,7 +781,7 @@ curl -X POST "https://${DOMAIN}/scim/v2/${ORG_ID}/Bulk" \
 </details>

 <details>
-<summary>`GET /ServiceProviderConfig`: Get service provider configuration</summary>
+<summary>`GET /ServiceProviderConfig`: Get service provider settings</summary>

 ```bash
 curl -G "https://${DOMAIN}/scim/v2/${ORG_ID}/ServiceProviderConfig" \
@@ -848,7 +848,7 @@ which aids pinpointing the source of the error in the system.

 ## Resources

- **[Zitadel SCIM Documentation](/guides/manage/user/scim2)**: Documentation of Zitadel's SCIM implementation, including configuration details and known limitations.
+- **[Zitadel SCIM Documentation](/guides/manage/user/scim2)**: Documentation of Zitadel's SCIM implementation, including settings and known limitations.
 - **[SCIM](https://scim.cloud/)**: The Webpage of SCIM.
 - **[RFC7643](https://tools.ietf.org/html/rfc7643) Core Schema**:
  The Core Schema provides a platform-neutral schema and extension model for representing users and groups.
@@ -87,7 +87,7 @@ This allows to increase cost along with growing computing power.
 ZITADEL allows to import user passwords from systems that use any of the above hashing algorithms.

 Note however that by default, only `bcrypt` is enabled.
-Further `Verifiers` must be enabled in the [configuration](/self-hosting/manage/configure) by the system administrator.
+Further `Verifiers` must be enabled in the [settings](/self-hosting/manage/configure) by the system administrator.
 </Callout>

 ### Encrypted Secrets
@@ -15,7 +15,7 @@ Each user in ZITADEL has one account for streamlined access management and a uni

 ### How it works

-Account linking is controlled by your organization and identity provider configuration.
+Account linking is controlled by your organization and identity provider settings.

 When external identity providers (such as social logins or enterprise SSO) are configured, a user account is created in ZITADEL, and the [external identity](/guides/manage/console/users-overview#federated-users) is linked to the ZITADEL account.

@@ -34,7 +34,7 @@ The schema is a very simplified version, but shows the essential steps for ident

 1. An unauthenticated user wants to use the alpha.com's application.
 2. The application redirects the user to alpha.com's identity provider (IdP).
-3. Based on the user's tenants configuration the IdP presents the configured identity providers, or redirects the user directly to the primary external IdP. The user authenticates with their external identity provider (eg, Entra ID).
+3. Based on the user's tenants settings the IdP presents the configured identity providers, or redirects the user directly to the primary external IdP. The user authenticates with their external identity provider (eg, Entra ID).
 4. After the authentication, the user is redirected back to alpha.com's identity provider. If the user doesn't exist in the IdP the user will be created just-in-time and linked to the external identity provider for future reference.
 5. As with a local authentication, the IdP issues a token to the user that can be used to access the application. The IdP redirects the user, which is now authenticated, eventually to the application.

@@ -66,7 +66,7 @@ Using an identity provider with strong multitenancy capabilities such as ZITADEL
 ZITADEL works with SAML, OpenID Connect, and LDAP external identity providers.

 For popular IdPs such as EntraID, Okta, Google, Facebook, and GitHub, ZITADEL [offers pre-configured templates](/guides/integrate/identity-providers/introduction).
-These templates expedite the configuration process, allowing organizations to quickly integrate these providers with minimal effort.
+These templates expedite the setup process, allowing organizations to quickly integrate these providers with minimal effort.

 ZITADEL recognizes that specific needs may extend beyond pre-built templates.
 To address this, ZITADEL provides generic templates that enable connection to virtually any IdP.  This ensures maximum flexibility and future-proofs login infrastructure, accommodating future integrations with ease.
@@ -9,7 +9,7 @@ For these tasks we either provide a user interface, or the tasks can be initiate
 It is important to understand that, depending on your use case, there will exist different user-types that want to perform different actions:

 - `Users` are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators, etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.
- `Administrators` are users with a [special administrator role](../../guides/manage/console/administrators) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
+- `Administrators` are users with a [special administrator role](../../guides/manage/console/administrators) within ZITADEL and can perform administrative actions such as organization settings or granting access rights to users.

 All self-service interfaces are available in different [languages](/guides/manage/customize/texts#internationalization-i-18-n).

@@ -8,5 +8,5 @@ Administrator permissions can be assigned to different levels in ZITADEL:
 - **Project Grant Administrators**: The project grant administrator manages [projects granted](/concepts/structure/granted_projects) by another organization.

 The scope of the administrators is restricted based on their level.
-Which means that an administrator, assigned to one organization, will have access only to the resources and configurations of that organization.
+Which means that an administrator, assigned to one organization, will have access only to the resources and settings of that organization.
 Only the Administrators on the instance level can view resources, such as users, across all organizations.
@@ -3,7 +3,7 @@ title: ZITADEL Settings and Policies
 sidebar_label: Setting and Policies
 ---

-Settings and policies are configurations of all the different parts of the instance or an organization. For all parts we have a suitable default in the instance.
-The default configuration can be overridden for each organization, some policies are currently only available on the instance level. Learn more about our different policies [here](/guides/manage/console/default-settings).
+Settings and policies control the behavior of all the different parts of the instance or an organization. For all parts we have a suitable default in the instance.
+The default settings can be overridden for each organization, some policies are currently only available on the instance level. Learn more about our different policies [here](/guides/manage/console/default-settings).

 API wise, settings are often called policies. You can read the proto and swagger definitions [here](../../apis/introduction).
@@ -8,7 +8,7 @@ title: OAuth 2.0 Proxy

 ### Setup Application and get Keys

-Before we can start building our application we have do do a few configuration steps in ZITADEL Console.
+Before we can start building our application we have to do a few setup steps in ZITADEL Console.
 You will need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your project and add a new application at the top of the page.
 Select Web Application and continue.
 We recommend that you use [Authorization Code](/apis/openidoauth/grant-types#authorization-code) for the OAuth 2.0 Proxy.
@@ -61,7 +61,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](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/apis/actions/complement-token) according to [this example](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/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](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/apis/actions/complement-token) according to [this example](/guides/manage/console/actions-overview) in ZITADEL to [complement the token](/apis/actions/complement-token) according to [this example](https://github.com/zitadel/actions/blob/main/examples/custom_roles.js) and add the following settings to the config:

 ```toml
 oidc_groups_claim = "{your_actions_group_key}"
@@ -10,7 +10,7 @@

 ![](../../../public/img/examples/secure-api/app-jwt/3.png)

-4. Now review your configuration and click **Create**.
+4. Now review your settings and click **Create**.

 ![](../../../public/img/examples/secure-api/app-jwt/4.png)

@@ -12,7 +12,7 @@ By the end of this guide, your application will have login functionality and wil

 ## Set up application and obtain keys

-Before we begin developing our application, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our application, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project, then add a new application at the top of the page.
 Select the **User Agent** application type and continue.
 We recommend that you use [Proof Key for Code Exchange (PKCE)](/apis/openidoauth/grant-types#proof-key-for-code-exchange) for all SPA applications.
@@ -146,7 +146,7 @@ https://github.com/zitadel/zitadel-angular/blob/main/src/app/components/user/use

 ### Refresh token

-If you want to add a refresh token to your application, navigate to the management console application and check the box in the configuration section.
+If you want to add a refresh token to your application, navigate to the management console application and check the box in the settings section.
 Then add `offline_access` to the scopes and add the following line:

 ```
@@ -159,7 +159,7 @@ This line automatically refreshes a token before it expires.

 Congratulations! You have successfully integrated your Angular application with ZITADEL!

-If you get stuck, consider checking out our [example](https://github.com/zitadel/zitadel-angular) application. This application includes all the functionalities mentioned in this quick-start. You can start by cloning the repository and replacing the _AuthConfig_ in the _AppModule_ with your own configuration. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel).
+If you get stuck, consider checking out our [example](https://github.com/zitadel/zitadel-angular) application. This application includes all the functionalities mentioned in this quick-start. You can start by cloning the repository and replacing the _AuthConfig_ in the _AppModule_ with your own settings. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel).

 ![App in management console](../../../public/img/angular/app-screen.png)

@@ -12,7 +12,7 @@ If you need any other information about Flutter, head over to the [documentation

 ## Setup Application

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Console.
 You will need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project, then add a new application at the top of the page.
 Select **Native** application type and continue.

@@ -17,7 +17,7 @@ By the end of this guide, your application will have login functionality and wil

 ## Set up application

-Before we begin developing our application, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our application, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project, then add a new application at the top of the page.
 Select the **Web** application type and continue.

@@ -152,4 +152,4 @@ Congratulations! You have successfully integrated your Go application with ZITAD

 If you get stuck, consider checking out our [example](https://github.com/zitadel/zitadel-go) application.
 This application includes all the functionalities mentioned in this quickstart.
-You can directly start it with your own configuration. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel-go/issues).
+You can directly start it with your own settings. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel-go/issues).
@@ -15,7 +15,7 @@ You can either create your own application or directly run the example by provid

 ## Set up application

-Before we begin developing our application, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our application, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project, then add a new application at the top of the page.
 Select the **Web** application type and continue.

@@ -73,7 +73,7 @@ https://github.com/zitadel/zitadel-java/blob/main/web/src/main/java/demo/support
 https://github.com/zitadel/zitadel-java/blob/main/web/src/main/java/demo/support/AccessTokenInterceptor.java
 ```

-### Application server configuration
+### Application server settings

 As we have now our support classes, we can now create and configure the application server (and API client) itself.

@@ -90,7 +90,7 @@ mapping the claims (using the ZitadelGrantedAuthoritiesMapper) and also provide
 https://github.com/zitadel/zitadel-java/blob/main/web/src/main/java/demo/config/WebSecurityConfig.java
 ```

-For the authentication (and the server in general) to work, the application needs some configuration, so please provide the following to your `application.yml` (resources folder):
+For the authentication (and the server in general) to work, the application needs some settings, so please provide the following to your `application.yml` (resources folder):

 ```yaml reference
 https://github.com/zitadel/zitadel-java/blob/main/web/src/main/resources/application.yml
@@ -173,4 +173,4 @@ Congratulations! You have successfully integrated your Spring Boot web applicati

 If you get stuck, consider checking out our [example](https://github.com/zitadel/zitadel-java) application.
 This application includes all the functionalities mentioned in this quickstart.
-You can directly start it with your own configuration. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel-java/issues).
+You can directly start it with your own settings. If you face issues, contact us or raise an issue on [GitHub](https://github.com/zitadel/zitadel-java/issues).
@@ -74,7 +74,7 @@ Make sure to select `Project Owner Viewer` as the management role.

 To show granted projects, go to the `Demo-Vendor` organization and add the Service Account as `Org Project Permission Editor` Manager.

-## Configuration
+## Setup

 Now clone this project and navigate to its root folder.
 Create a file `.env.local` and copy and paste the following:
@@ -102,7 +102,7 @@ Replace the values as follows

 `PROJECT_ID`: You can find `${PROJECT_ID}` by clicking on "Projects" in the navigation and select the Project `Portal`. `${PROJECT_ID}` is displayed on the top as "Resource ID".

-`ZITADEL_CLIENT_ID`: Having the project `Portal` selected, click on the Application `portal-web`. `${CLIENT_ID}` is displayed as a field in the OIDC configuration, labeled "Client ID" and has the format `12345678@portal`.
+`ZITADEL_CLIENT_ID`: Having the project `Portal` selected, click on the Application `portal-web`. `${CLIENT_ID}` is displayed as a field in the OIDC settings, labeled "Client ID" and has the format `12345678@portal`.

 `SERVICE_ACCOUNT_ACCESS_TOKEN`: Set up a service account, add a Personal Access Token, and copy the secret here (see below).

@@ -27,7 +27,7 @@ then open [http://localhost:3000](http://localhost:3000) with your browser to se

 ## Setup Application and Get Keys

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Console.
 You will need to provide some information about your app.

 Navigate to your Project, then add a new application at the top of the page.
@@ -54,10 +54,10 @@ After successful app creation, a pop-up will appear, showing the app's client ID

 Now that you have your web application configured on the ZITADEL side, you can go ahead and integrate your NextJS app.

-### Configuration
+### Setup

 NextAuth.js exposes a REST API which is used by your application.
-To setup your configuration, create a file called `src/lib/auth.ts`.
+To setup your auth, create a file called `src/lib/auth.ts`.
 You can directly import the ZITADEL provider from [next-auth](https://next-auth.js.org/providers/zitadel).

 ```ts reference
@@ -18,7 +18,7 @@ This documentation references our [example](https://github.com/zitadel/example-d

 ## ZITADEL setup

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Management Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Management Console.

 ### Project roles

@@ -83,7 +83,7 @@ The secret will not be displayed again, but you can regenerate one if you loose

 For this example we need the following dependencies:
 - `django`: to create an API with django
- `python-dotenv`: to use environment variables in the configuration
+- `python-dotenv`: to use environment variables in the settings
 - `mozilla-django-oidc`: client-side OIDC functionality

 For the dependencies we need a requirements.txt-file with the following content:
@@ -137,13 +137,13 @@ AUTHENTICATION_BACKENDS = (
 )
 ```

-Add configuration:
+Add settings:

 ```python reference
 https://github.com/zitadel/example-python-django-oidc/blob/main/mysite/settings.py#L130-L174
 ```

-and create a ".env"-file in the root folder with the configuration:
+and create a ".env"-file in the root folder with the settings:

 ```bash
 ZITADEL_PROJECT = "ID of the project you created the application in ZITADEL"
@@ -10,12 +10,12 @@ By the end of this guide, your application will have login functionality and wil

 <Callout>
 This documentation references our [example](https://github.com/zitadel/zitadel-react) on GitHub.
-It also uses the @zitadel/react package with its default configuration.
+It also uses the @zitadel/react package with its default settings.
 </Callout>

 ## Set up application and obtain keys

-Before we begin developing our application, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our application, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app.
 We recommend creating a new app to start from scratch.
 Navigate to your project, then add a new application at the top of the page.
@@ -14,7 +14,7 @@ This documentation references our [example](https://github.com/zitadel/example-s

 ## ZITADEL setup

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Console.

 ### Project roles

@@ -10,12 +10,12 @@ By the end of this guide, your application will have login functionality and wil

 <Callout title="">
 This documentation references our [example](https://github.com/zitadel/zitadel-vue) on GitHub.
-It also uses the @zitadel/vue package with its default configuration.
+It also uses the @zitadel/vue package with its default settings.
 </Callout>

 ## Set up application and obtain keys

-Before we begin developing our application, we need to perform a few configuration steps in the ZITADEL Management Console.
+Before we begin developing our application, we need to perform a few setup steps in the ZITADEL Management Console.
 You'll need to provide some information about your app.
 We recommend creating a new app to start from scratch.
 Navigate to your project, then add a new application at the top of the page.
@@ -21,7 +21,7 @@ All that is required, is to create your API, create a private key and a personal

 ### Set up application and obtain keys

-Before we begin developing our API, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our API, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app. We recommend creating a new app to start from scratch.

 Starting from the homepage of your management console, click on Create Application
@@ -15,7 +15,7 @@ You can either create your own application or directly run the example by provid

 ## Set up application

-Before we begin developing our API, we need to perform a few configuration steps in the ZITADEL Console.
+Before we begin developing our API, we need to perform a few setup steps in the ZITADEL Console.
 You'll need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project, then add a new application at the top of the page.
 Select the **API** application type and continue.

@@ -47,7 +47,7 @@ So in your application, create a `support/zitadel` package and in there the `Cus
 https://github.com/zitadel/zitadel-java/blob/main/api/src/main/java/demo/app/support/zitadel/CustomAuthorityOpaqueTokenIntrospector.java
 ```

-### Application server configuration
+### Application server settings

 As we have now our support class, we can now create and configure the application server itself.

@@ -59,7 +59,7 @@ It will also use the just created CustomAuthorityOpaqueTokenIntrospector for the
 https://github.com/zitadel/zitadel-java/blob/main/api/src/main/java/demo/app/config/WebSecurityConfig.java
 ```

-For the authorization (and the server in general) to work, the application needs some configuration, so please provide the following to your `application.yml` (resources folder):
+For the authorization (and the server in general) to work, the application needs some settings, so please provide the following to your `application.yml` (resources folder):

 ```yaml reference
 https://github.com/zitadel/zitadel-java/blob/main/api/src/main/resources/application.yml
@@ -23,7 +23,7 @@ The NestJS API includes a private endpoint `GET http://localhost:${APP_PORT}/api

 Make sure you have Node.js and npm installed on your machine.

-### ZITADEL Configuration for the API
+### ZITADEL Setup for the API

 1. Create a ZITADEL instance and a project by following the steps [here](/guides/start/quickstart#3-create-your-zitadel-instance).

@@ -14,7 +14,7 @@ By the end of this guide, your application will have three different endpoint wh

 ## ZITADEL setup

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Management Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Management Console.

 ### Create application

@@ -42,7 +42,7 @@ And the following from the Service Account:

 ## Setup new Pylon service

-Pylon allows you to create a new service using the `npm create pylon` command. This command creates a new Pylon project with a basic project structure and configuration.
+Pylon allows you to create a new service using the `npm create pylon` command. This command creates a new Pylon project with a basic project structure and settings.
 During the setup process, you can choose your preferred runtime, such as Bun, Node.js, or Cloudflare Workers.

 **This guide uses the Bun runtime.**
@@ -98,7 +98,7 @@ export default app;

 ### Add ZITADEL info to the service

-1. Create a `.env` file in the root folder of your project and add the following configuration:
+1. Create a `.env` file in the root folder of your project and add the following settings:

 ```bash
 AUTH_ISSUER='URL to the zitadel instance'
@@ -19,7 +19,7 @@ This documentation references our [example](https://github.com/zitadel/example-d

 ## ZITADEL setup

-Before we can start building our application, we have to do a few configuration steps in ZITADEL Management Console.
+Before we can start building our application, we have to do a few setup steps in ZITADEL Management Console.

 ### Create application

@@ -55,7 +55,7 @@ And the following from the Service Account:

 For this example we need the following dependencies:
 - `django`: to create an API with django
- `python-dotenv`: to use environment variables in the configuration
+- `python-dotenv`: to use environment variables in the settings
 - `authlib`: client-side OAuth functionality
 - `requests`: HTTP requests for the introspection

@@ -85,7 +85,7 @@ There is info needed for the introspection calls, which we put into the settings
 https://github.com/zitadel/example-python-django-oauth/blob/main/myapi/settings.py#L125-L133
 ```

-and create a ".env"-file in the root folder with the configuration as an example:
+and create a ".env"-file in the root folder with the settings as an example:
 ```bash
 ZITADEL_INTROSPECTION_URL = 'URL to the introspection endpoint to verify the provided token'
 ZITADEL_DOMAIN = 'Domain used as audience in the token verification'
@@ -23,7 +23,7 @@ In this example we will use a service account with a [personal access token](/gu

 In order to run the example you need to have `python3` and `pip3` installed.

-### ZITADEL configuration for the API
+### ZITADEL settings for the API

 ![](../../../public/img/python-flask/2.png)

@@ -174,7 +174,7 @@ class ZitadelIntrospectTokenValidator(IntrospectTokenValidator):
        return res
 ```

-3. Create a new file named ".env" in the directory. Copy the configuration in the [".env.example"](https://github.com/zitadel/example-api-python3-flask/blob/main/.env.example) file to the newly created .env file. Set the values with your Custom Domain/Issuer URL, Client ID, and Client Secret from the previous steps. Obtain your Issuer URL by following [these steps](/guides/start/quickstart#5-collect-your-integration-keys).
+3. Create a new file named ".env" in the directory. Copy the settings in the [".env.example"](https://github.com/zitadel/example-api-python3-flask/blob/main/.env.example) file to the newly created .env file. Set the values with your Custom Domain/Issuer URL, Client ID, and Client Secret from the previous steps. Obtain your Issuer URL by following [these steps](/guides/start/quickstart#5-collect-your-integration-keys).

 ```python
 ZITADEL_DOMAIN = "https://custom-domain-abcdef.zitadel.cloud"
@@ -182,7 +182,7 @@ CLIENT_ID = "197....@projectname"
 CLIENT_SECRET = "NVAp70IqiGmJldbS...."
 ```

-### ZITADEL configuration to create a service account
+### ZITADEL settings to create a service account

 ![](../../../public/img/python-flask/3.png)

@@ -32,7 +32,7 @@ Custom JavaScript code executed directly inside ZITADEL's process. For a complet

 - **Context:** Embedded goja JavaScript engine
 - **Risks:** Shared memory space; errors could affect core functionality
- **Constraints:** Bound to ZITADEL process resources; limited timeout configuration
+- **Constraints:** Bound to ZITADEL process resources; limited timeout settings
 - **V1 Triggers:** Pre-event hooks (fire before operation) and Post-event hooks (fire after success)

 ### Actions V2: The Webhook Model
@@ -37,7 +37,7 @@ export default function CreateApp(props) {
        redirectURI={props.redirectURI}
        postLogoutURI={props.postLogoutURI}
      />
-      <h3>Review your configuration</h3>
+      <h3>Review your settings</h3>
      <ReviewConfig components={props.components}  appType={props.appType} authType={props.authType} />
      <GenerateKey components={props.components}  appType={props.appType} authType={props.authType} />
    </div>
@@ -6,7 +6,7 @@ export default function GenerateKey(props) {
     <h3>Create key for private key JWT</h3>
      <p>
        After you successfully created your application with authentication type
-        JWT your can create keys in the Configuration section and Keys Card of
+        JWT you can create keys in the Settings section and Keys Card of
        the app details like following image shows:
      </p>
      <img
@@ -43,7 +43,7 @@ export default function RedirectURIs(props) {
      </Admonition>
      <img
        width="600px"
-        alt="Redirect URIs configuration"
+        alt="Redirect URIs settings"
        src={"/img/guides/application/redirect-uris.png"}
      />
    </div>
@@ -12,7 +12,7 @@ export default function ReviewConfig(props) {
    <div>
      <p>
        The last page of the stepper shows a summary of what will be created.
-        After you have reviewed the configuration you can create the
+        After you have reviewed the settings you can create the
        application.
      </p>
      <h3>Client information</h3>
@@ -7,7 +7,7 @@ This integration guide shows how you can embed authenticated MongoDB Charts in y

 ## Setup ZITADEL Application

-Before you can embed an authenticated chart in your application, you have to do a few configuration steps in ZITADEL Console.
+Before you can embed an authenticated chart in your application, you have to do a few setup steps in ZITADEL Console.
 You will need to provide some information about your app. We recommend creating a new app to start from scratch.

 1. Navigate to your Project
@@ -16,9 +16,9 @@ You will need to provide some information about your app. We recommend creating
 4. Use [Authorization Code](/apis/openidoauth/grant-types#authorization-code) in combination with [Proof Key for Code Exchange (PKCE)](/apis/openidoauth/grant-types#proof-key-for-code-exchange).
 5. Skip the redirect settings and confirm the app creation
 6. Copy the client ID, you will need to tell MongoDB Charts about it.
-7. When you created the app, expand its _OIDC Configuration_ section, change the _Auth Token Type_ to _JWT_ and save the change.
+7. When you created the app, expand its _OIDC Settings_ section, change the _Auth Token Type_ to JWT

-Your application configuration should now look similar to this:
+Your application settings should now look similar to this:

 ![Create app in management console](../../../public/img/integrations/mongodb-charts-app-create-light.png)

@@ -32,7 +32,7 @@ Configure the following values:
 - JWKS: https://$CUSTOM_DOMAIN/oauth/v2/keys
 - Audience: Your app's client ID which you copied when you created the ZITADEL app

-Your configuration should look similar to this:
+Your settings should look similar to this:

 ![](../../../public/img/integrations/mongodb-charts-auth-provider-light.png)

@@ -52,7 +52,7 @@ provides the possibility to match the exact SSO session, which was terminated.
 ### Client

 To enable the back-channel logout on an application, they simply need to register a `backchannel_logout_uri` as part of their
-configuration, e.g. [creating an OIDC application](/guides/manage/console/applications-overview).
+settings, e.g. [creating an OIDC application](/guides/manage/console/applications-overview).

 As soon as the URI is set, every new authorization request will register a back-channel notification to be sent once
 the session is terminated by a user sign out.
@@ -1,8 +1,8 @@
 When you use an LDAP provider in ZITADEL, this is the login process:

-1. ZITADEL tries to connect to the LDAP server with or without TLS depending on the configuration
+1. ZITADEL tries to connect to the LDAP server with or without TLS depending on the settings
 2. If the connection fails, the next server in the list will be used to try again.
 3. ZITADEL tries a bind with the BindDN and BindPassword to check if it's possible to proceed
-4. ZITADEL does a SearchQuery to find the UserDN with the provided configuration of base, filters and objectClasses
+4. ZITADEL does a SearchQuery to find the UserDN with the provided settings of base, filters and objectClasses
 5. ZITADEL tries a bind with the provided loginname and password
-6. LDAP attributes get mapped to ZITADEL attributes as provided by the configuration
+6. LDAP attributes get mapped to ZITADEL attributes as provided by the settings
@@ -1,5 +1,5 @@
 <p>You can use a ZITADEL action if you want to prefill the fields {props.fields} with {props.provider} data.</p>

 1. Go to the users target organizations settings page.
-2. Add a new action with the body below. Make sure the action name equals the scripts function name. Also change the id in the script to match your provider configurations id.
+2. Add a new action with the body below. Make sure the action name equals the scripts function name. Also change the id in the script to match your provider settings id.
 3. Add the action to the flow "External Authentication" and trigger it on "Post Authentication"
@@ -1,5 +1,5 @@
 ---
-title: Configure Apple as an Identity Provider in ZITADEL
+title: Set up Apple as an Identity Provider in ZITADEL
 sidebar_label: Apple
 ---

@@ -54,7 +54,7 @@ You will have to paste it in the Apple service later.
 5. Choose your app from the list
 6. Register the key and download it

-## ZITADEL Configuration
+## ZITADEL Setup

 Go back [to the Apple provider template you opened before in ZITADEL](#open-the-apple-identity-provider-template).

@@ -1,5 +1,5 @@
 ---
-title: Configure Entra ID as an Identity Provider in ZITADEL
+title: Set up Entra ID as an Identity Provider in ZITADEL
 sidebar_label: Entra ID
 ---

@@ -47,11 +47,11 @@ Generate a new client secret to authenticate your user.

 ![](../../../../public/img/guides/azure_client_secret.png)

-### Token configuration
+### Token settings

 To allow ZITADEL to get the information from the authenticating user you have to configure what kind of optional claims should be returned in the token.

-1. Click on Token configuration in the side menu
+1. Click on Token settings in the side menu
 2. Click on "+ Add optional claim"
 3. Add email, family_name (last name of the user), given_name (first name of the user) and preferred_username to the id token

@@ -67,7 +67,7 @@ To be able to get all the information that ZITADEL needs, you have to configure

 ![](../../../../public/img/guides/azure_api_permissions.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 Go back [to the Microsoft provider template you opened before in ZITADEL](#open-the-microsoft-identity-provider-template).
 Add the [client ID and secret created before on your Entra ID application](#add-client-secret).
@@ -89,7 +89,7 @@ In this case, configure "Accounts in any organizational directory and personal M
 - Organizations: Choose organization if you have Entra ID Tenants and no personal accounts. (You have configured either "Accounts in this organization" or "Accounts in any organizational directory" on your Azure APP)
 - Consumers: Choose this if you want to allow public accounts. (In your Entra ID App you have configured "Personal Microsoft accounts only")

-**Tenant ID**: If you have selected *Tenant ID* as *Tenant Type*, you have to enter the *Directory (Tenant) ID* into the *Tenant ID* field, copied previously from the Azure App configuration.
+**Tenant ID**: If you have selected *Tenant ID* as *Tenant Type*, you have to enter the *Directory (Tenant) ID* into the *Tenant ID* field, copied previously from the Azure App settings.

 <GeneralConfigDescription components={props.components}  provider_account="Microsoft account" />

@@ -1,5 +1,5 @@
 ---
-title: Configure Entra ID as a SAML Service Provider in ZITADEL
+title: Set up Entra ID as a SAML Service Provider in ZITADEL
 sidebar_label: Entra ID SAML
 ---

@@ -47,7 +47,7 @@ Configure the sign-on method of the app.

 ![](../../../../public/img/guides/azure_saml_overview.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 ### Go to the IdP Providers Overview

@@ -19,7 +19,7 @@ import TestSetup from './_test_setup.mdx';
 <IDPsOverview components={props.components} templates="Generic OIDC"/>

 Click on the ZITADEL Callback URL to copy it to your clipboard.
-You will have to paste this URL in your external OIDC provider's application configuration later.
+You will have to paste this URL in your external OIDC provider's application settings later.

 ![Generic OIDC Provider](../../../../public/img/guides/zitadel_generic_oidc_create_provider.png)

@@ -36,7 +36,7 @@ You will have to paste this URL in your external OIDC provider's application con

 > The exact steps and terminology may vary for each provider. Refer to your provider's documentation if you don't see these options.

-## ZITADEL Configuration
+## ZITADEL Setup

 1. Return to [the Generic OIDC Provider template in ZITADEL](#open-the-generic-oidc-provider-template).
 2. Enter the **Client ID** and **Client Secret** from your OIDC provider's application.
@@ -45,7 +45,7 @@ Make sure to save the secret, as you will not be able to show it again.

 ![](../../../../public/img/guides/github_oauth_client_id_secret.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 Go back [to the GitHub provider template you opened before in ZITADEL](#open-the-github-identity-provider-template).
 Add the [client ID and secret you created before when you registered your GitHub OAuth application](#client-id-and-secret).
@@ -43,7 +43,7 @@ Save the ID and the Secret, you will not be able to copy the secret again, if yo

 ![](../../../../public/img/guides/gitlab_app_id_secret.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 Go back [to the GitLab provider template you opened before in ZITADEL](#open-the-gitlab-identity-provider-template).
 Add the [client ID and secret you created before when you registered your GitLab application](#client-id-and-secret).
@@ -41,7 +41,7 @@ You will need the Client ID and Client secret to configure the Google Identity P

 ![](../../../../public/img/guides/google_client_id_secret.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 Go back [to the Google provider template you opened before in ZITADEL](#open-the-google-identity-provider-template).
 Add the [client ID and secret created before on your Google App](#client-id-and-client-secret).
@@ -19,7 +19,7 @@ ZITADEL positions itself as the central hub or the identity broker in the intera

 With ZITADEL, you can enhance your application's accessibility by integrating social login IdPs such as Google or other IdPs such as EntraID (formerly known as AzureAD) and Auth0. For organizations with bespoke identity solutions, ZITADEL supports integration with custom-built IdPs that adhere to OpenID Connect or SAML protocols. By default, ZITADEL can serve as the primary user store for your applications. This centralizes user management and simplifies the authentication process, allowing users to sign in with their email and password, or via the external IdPs you've integrated.

-ZITADEL excels in B2B scenarios by offering the flexibility to configure different IdPs for distinct customers, enhancing ease of use and customization. For instance, you could have Customer A utilize EntraID for authentication, while Customer B uses Okta. This versatility enables you to tailor authentication solutions to meet the specific needs of each customer, streamlining their access while maintaining a centralized management system.
+ZITADEL excels in B2B scenarios by offering the flexibility to set up different IdPs for distinct customers, enhancing ease of use and customization. For instance, you could have Customer A utilize EntraID for authentication, while Customer B uses Okta. This versatility enables you to tailor authentication solutions to meet the specific needs of each customer, streamlining their access while maintaining a centralized management system.

 ## The advantages of using ZITADEL

@@ -61,7 +61,7 @@ In ZITADEL, you have the flexibility to link an external Identity Provider (IdP)

 ### Adjusting the custom login policy

-The login policy can be set as a default at the instance level and can be customized for each organization. The configuration process varies slightly depending on your focus:
+The login policy can be set as a default at the instance level and can be customized for each organization. The setup process varies slightly depending on your focus:

 - **For default settings**, navigate to: `${CUSTOM_DOMAIN}/ui/console/instance?id=general`
 - **For specific organization settings**, select the organization from the menu and visit: `${CUSTOM_DOMAIN}/ui/console/org-settings?id=login`
@@ -71,17 +71,17 @@ Once in the settings:

 ![](../../../../public/img/guides/zitadel_allow_external_idp.png)

-### Configuring IdP Providers
+### Setting up IdP Providers

 Access the settings page of your instance or the specific organization and select **Identity Providers**.

-The ZITADEL Management Console will display a list of all the IdPs you've configured, along with available provider templates. Selecting any listed IdP will guide you through the process of configuring that specific Identity Provider.
+The ZITADEL Management Console will display a list of all the IdPs you've set up, along with available provider templates. Selecting any listed IdP will guide you through the process of setting up that specific Identity Provider.

 ![](../../../../public/img/guides/zitadel_identity_provider_overview.png)

 ## Available guides

-In the guides below, some of which utilize the Generic OIDC or SAML templates for configuration, you'll learn how to configure and set up your preferred external Identity Provider (IdP) in ZITADEL.
+In the guides below, some of which utilize the Generic OIDC or SAML templates for settings, you'll learn how to configure and set up your preferred external Identity Provider (IdP) in ZITADEL.

 - [Google](./google)
 - [Entra ID (OIDC)](./azure-ad-oidc)
@@ -99,7 +99,7 @@ In the guides below, some of which utilize the Generic OIDC or SAML templates fo

 ### Configuring IdPs without predefined templates

-If ZITADEL doesn't offer a specific template for your Identity Provider (IdP) and your IdP is fully compliant with OpenID Connect (OIDC), you have the option to use the generic OIDC provider configuration.
+If ZITADEL doesn't offer a specific template for your Identity Provider (IdP) and your IdP is fully compliant with OpenID Connect (OIDC), you have the option to use the generic OIDC provider settings.

 For those utilizing a SAML Service Provider, the SAML Service Provider option is available. You can learn how to set up a SAML Service Provider with our [MockSAML example](/guides/integrate/identity-providers/mocksaml).

@@ -157,5 +157,5 @@ Sample **JWT IdP Configuration**:

 When ZITADEL performs signature validation, it uses the Keys Endpoint to:
 - Verify the JWT’s signature
- Check the issuer matches the JWT IdP configuration
+- Check the issuer matches the JWT IdP settings
 - Ensure the JWT is not expired
@@ -36,7 +36,7 @@ You will have to paste it in the Keycloak Client later.
 ![](../../../../public/img/guides/keycloak_add_client.png)
 ![](../../../../public/img/guides/keycloak_client_secret.png)

-## ZITADEL configuration
+## ZITADEL settings

 1. Go back [to the Generic OIDC Provider template you opened before in ZITADEL](#open-the-generic-oidc-provider-template).
 2. Add the [client ID and secret created before on your Keycloak Client](#register-a-new-client).
@@ -18,7 +18,7 @@ import HowLDAPIDPWorks from './_how_ldap_idp_works.mdx'

 <HowLDAPIDPWorks components={props.components} />

-## ZITADEL Configuration
+## ZITADEL Setup

 ### Go to the IdP Providers Overview

@@ -1,5 +1,5 @@
 ---
-title: Configure LinkedIn as an OAuth Identity Provider in ZITADEL
+title: Set up LinkedIn as an OAuth Identity Provider in ZITADEL
 sidebar_label: LinkedIn generic OAuth
 id: linkedin-oauth
 ---
@@ -33,7 +33,7 @@ import TestSetup from './_test_setup.mdx';

 ![](../../../../public/img/guides/linkedin_add_app.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 ### Add custom login policy

@@ -18,11 +18,11 @@ These calls change the type of the provider and don't delete any linked users.

 ### Google Configuration

-The available configuration is described in [Google Configuration](./google).
+The available settings are described in [Google Configuration](./google).

 ### Entra ID Configuration

-The available configuration is described in [Entra ID Configuration](./azure-ad-oidc).
+The available settings are described in [Entra ID Configuration](./azure-ad-oidc).

 ## Migrate with Terraform

@@ -1,5 +1,5 @@
 ---
-title: Configure MockSAML as an Identity Provider in ZITADEL
+title: Set up MockSAML as an Identity Provider in ZITADEL
 sidebar_label: MockSAML
 id: mocksaml
 ---
@@ -25,7 +25,7 @@ MockSAML is not intended for any production environment, only for test purposes
 You can either download the metadata under [https://mocksaml.com/api/saml/metadata?download=true](https://mocksaml.com/api/saml/metadata?download=true) or skip this step and
 fill in the URL when creating the SAML Provider in ZITADEL.

-## ZITADEL configuration
+## ZITADEL settings

 ### Go to the IdP providers overview

@@ -35,7 +35,7 @@ fill in the URL when creating the SAML Provider in ZITADEL.

 The SAML provider template has everything you need preconfigured.
 Add the metadata.xml or the URL to the metadata which are accessible by you ZITADEL instance.
-All the necessary configuration is contained in the metadata which has to be exchanged by the ServiceProvider and the IdentityProvider.
+All the necessary settings are contained in the metadata which has to be exchanged by the ServiceProvider and the IdentityProvider.

 <GeneralConfigDescription components={props.components}  provider_account="SAML account" />

@@ -1,5 +1,5 @@
 ---
-title: Configure OKTA as an OIDC Identity Provider in ZITADEL
+title: Set up OKTA as an OIDC Identity Provider in ZITADEL
 sidebar_label: OKTA generic OIDC
 id: okta-oidc
 ---
@@ -35,7 +35,7 @@ You will have to paste it in the OKTA application later.

 ![](../../../../public/img/guides/okta_add_app.png)

-## ZITADEL Configuration
+## ZITADEL Setup

 1. Go back [to the Generic OIDC Provider template you opened before in ZITADEL](#open-the-generic-oidc-provider-template).
 2. Add the [client ID and secret created before on your Web application](#register-a-new-client).
@@ -1,5 +1,5 @@
 ---
-title: Configure OKTA as a SAML Identity Provider in ZITADEL
+title: Set up OKTA as a SAML Identity Provider in ZITADEL
 sidebar_label: OKTA SAML
 id: okta-saml
 ---
@@ -14,7 +14,7 @@ import TestSetup from './_test_setup.mdx';

 <Intro components={props.components}  provider="OKTA"/>

-## ZITADEL Configuration
+## ZITADEL Setup

 ### Go to the IdP Providers Overview

@@ -24,7 +24,7 @@ import TestSetup from './_test_setup.mdx';

 To be able to create the application in OKTA we need the provider id from ZITADEL.
 1. Create a new SAML Provider with a name and a random text in the Metadata Xml field.
-We will fill that as soon as we have done the configuration in OKTA.
+We will fill that as soon as we have done the settings in OKTA.
 2. Save Configuration

 As an alternative you can add the SAML identity provider through the API, either on the default settings or on a specific organization:
@@ -47,7 +47,7 @@ After you created the SAML Provider in ZITADEL, you can copy the URLs you need t
 4. Click on the ZITADEL URLs that your SAML IDP shows since you created it in ZITADEL and paste them accordingly:
 - **Single sign-on URL**: Paste the *ZITADEL ACS Login Form URL*.
 - **Audience URI (SP Entity ID)**: Paste the *ZITADEL Metadata URL*
-5. Save the configuration
+5. Save the settings
 6. Copy the metadata URL from the details

 ![](../../../../public/img/guides/okta_add_saml_app.png)
@@ -76,16 +76,16 @@ To allow users to authenticate with that app go to the "Assign" Tab.

 ![](../../../../public/img/guides/okta_assign_user_to_app.png)

-## Finish ZITADEL Configuration
+## Finish ZITADEL Setup

-You are now finished with the configuration in OKTA and you can switch back to your identity provider configuration in ZITADEL.
+You are now finished with the settings in OKTA and you can switch back to your identity provider settings in ZITADEL.

 ### Add Metadata Xml

 Add [the metadata URL you have saved before from OKTA](#register-a-new-client) to the Metadata URL.
 As soon as you have saved the provider, and you have a look at the detail you should now see the Metadata Xml field filled.

-If you prefer changing the configuration through the API you can update the SAML provider on the default settings or a specific organization:
+If you prefer changing the settings through the API you can update the SAML provider on the default settings or a specific organization:
 - [Update Default SAML Identity Provider](/reference/api/admin/zitadel.admin.v1.AdminService.UpdateSAMLProvider)
 - [Update SAML Identity Provider on Organization](/reference/api/management/zitadel.management.v1.ManagementService.UpdateSAMLProvider)

@@ -1,5 +1,5 @@
 ---
-title: Configure OneLogin as a SAML Identity Provider in ZITADEL
+title: Set up OneLogin as a SAML Identity Provider in ZITADEL
 sidebar_label: OneLogin SAML
 id: onelogin-saml
 ---
@@ -13,12 +13,12 @@ import TestSetup from './_test_setup.mdx';

 <Intro components={props.components} provider="OneLogin"/>

-## OneLogin SAML configuration
+## OneLogin SAML settings

 You need access to a OneLogin admin portal with permission to create and configure SAML applications.

 We’ll first configure OneLogin sufficiently to **export IdP metadata**, which we then import into ZITADEL.
-After the ZITADEL SAML provider exists, we’ll return to OneLogin and finish the SAML configuration using the ZITADEL URLs.
+After the ZITADEL SAML provider exists, we’ll return to OneLogin and finish the SAML settings using the ZITADEL URLs.

 ### Create a new SAML application for ZITADEL

@@ -51,9 +51,9 @@ Keep either:
 - the **IdP Metadata URL** (Issuer URL that returns XML), or
 - the **IdP metadata XML file**,

-ready for the ZITADEL configuration steps.
+ready for the ZITADEL setup steps.

-## ZITADEL configuration
+## ZITADEL settings

 ### Go to the IdP providers overview

@@ -63,7 +63,7 @@ ready for the ZITADEL configuration steps.

 The SAML provider template has everything you need preconfigured.
 Add the metadata XML or the URL to the metadata which is accessible by your ZITADEL instance.
-All the necessary configuration is contained in the metadata which has to be exchanged between the Service Provider and the Identity Provider.
+All the necessary settings are contained in the metadata which has to be exchanged between the Service Provider and the Identity Provider.

 <GeneralConfigDescription components={props.components} provider_account="OneLogin" />

@@ -89,7 +89,7 @@ You’ll need these URLs in the next step when finishing the OneLogin configurat
 Now that ZITADEL is configured, return to OneLogin and finish the SAML configuration of the ZITADEL app.

 1. In the OneLogin admin portal, open the **ZITADEL SAML** application.
-2. Go to the **Configuration** tab (or the section where SAML SP settings such as ACS and Audience are configured).
+2. Go to the **Settings** tab (or the section where SAML SP settings such as ACS and Audience are set up).
 3. Fill in the SAML settings using the values from the ZITADEL SAML provider:

   - **ACS (Consumer) URL / SAML Consumer URL**
@@ -1,5 +1,5 @@
 ---
-title: Configure Local OpenLDAP as an Identity Provider in ZITADEL
+title: Set up Local OpenLDAP as an Identity Provider in ZITADEL
 sidebar_label: Local OpenLDAP
 ---

@@ -20,7 +20,7 @@ The easiest way to do so is [by following the Docker Compose installation guide]
 </Callout>

 <Callout type="caution">
-Beware that this example configuration neither supports LDAPS nor StartTLS.
+Beware that these example settings neither supports LDAPS nor StartTLS.
 We highly recommend to enable LDAPS or StartTLS in your production setup.
 Otherwise, your users passwords are sent in clear text through the wire.
 </Callout>
@@ -33,7 +33,7 @@ Otherwise, your users passwords are sent in clear text through the wire.

 ## OpenLDAP Configuration

-### Basic configuration
+### Basic settings

 You can run OpenLdap via `docker-compose` using the following:
 ```
@@ -140,7 +140,7 @@ directory       /usr/local/var/openldap-data
 #index  objectClass     eq
 ```

-Which is the default configuration with an admin user under the DN `cn=admin,dc=example,dc=com` and password `Password1!`, BaseDN `"dc=example,dc=com` and database set to `ldif`.
+Which are the default settings with an admin user under the DN `cn=admin,dc=example,dc=com` and password `Password1!`, BaseDN `"dc=example,dc=com` and database set to `ldif`.
 In addition, there are some schemas included which can be used to create the users.

 ### Example users
@@ -177,7 +177,7 @@ The user can be applied after OpenLDAP is running with
 ldapadd -x -h localhost -D "cn=admin,dc=example,dc=com" -f example.ldif -w 'Password1!'
 ```

-## ZITADEL Configuration
+## ZITADEL Setup

 ### Go to the IdP Providers Overview

@@ -1,5 +1,5 @@
 ---
-title: Configure PingFederate as a SAML Identity Provider in ZITADEL
+title: Set up PingFederate as a SAML Identity Provider in ZITADEL
 sidebar_label: PingFederate SAML
 id: pingfederate-saml
 ---
@@ -13,12 +13,12 @@ import TestSetup from './_test_setup.mdx';

 <Intro components={props.components} provider="PingFederate"/>

-## PingFederate SAML configuration
+## PingFederate SAML settings

 You need access to a PingFederate administrative console with permission to create **SP Connections**.

 We’ll first configure PingFederate sufficiently to **export IdP metadata**, which we then import into ZITADEL.
-After the ZITADEL SAML provider exists, we’ll return to PingFederate and finish the SP configuration using the ZITADEL URLs.
+After the ZITADEL SAML provider exists, we’ll return to PingFederate and finish the SP settings using the ZITADEL URLs.

 ### Create a new SP Connection for ZITADEL

@@ -59,9 +59,9 @@ Keep either:
 - the **Metadata URL**, or
 - the **XML file** contents,

-ready for the ZITADEL configuration steps.
+ready for the ZITADEL setup steps.

-## ZITADEL configuration
+## ZITADEL settings

 ### Go to the IdP providers overview

@@ -71,7 +71,7 @@ ready for the ZITADEL configuration steps.

 The SAML provider template has everything you need preconfigured.
 Add the metadata.xml or the URL to the metadata which are accessible by your ZITADEL instance.
-All the necessary configuration is contained in the metadata which has to be exchanged by the ServiceProvider and the IdentityProvider.
+All the necessary settings are contained in the metadata which has to be exchanged by the ServiceProvider and the IdentityProvider.

 <GeneralConfigDescription components={props.components} provider_account="PingFederate" />

@@ -1,5 +1,5 @@
 Your user has successfully authenticated, and now you ask them if they want to set up MFA to have a more secure account.
-When the user starts the configuration, first you want to show them the possible methods.
+When the user starts the setup, first you want to show them the possible methods.
 You can either list it implicitly or call the settings service from ZITADEL to get what is configured on the login settings.

 More detailed information about the API: [Get Login Settings Documentation](/reference/api/settings/zitadel.settings.v2.SettingsService.GetLoginSettings)
@@ -32,7 +32,7 @@ ZITADEL supports different Methods:
 The user has selected to setup TOTP.
 To show the user the QR to register TOTP with his Authenticator App like Google/Microsoft Authenticator or Authy you have to start the registration on the ZITADEL API.
 Generate the QR Code with the URI from the response.
-For users that do not have a QR Code reader make sure to also show the secret, to enable manual configuration.
+For users that do not have a QR Code reader make sure to also show the secret, to enable manual setup.

 More detailed information about the API: [Start TOTP Registration Documentation](/reference/api/user/zitadel.user.v2.UserService.RegisterTOTP)

@@ -1,4 +1,4 @@
 <Callout type="warn" title="Don't Lock Yourself Out of Your Instance">
-    Before you change your Zitadel configuration, we highly recommend you to create a service account with a personal access token (PAT) and the IAM_OWNER role.
-    In case something breaks, you can use this PAT to revert your changes or fix the configuration so you can use a login UI again.
+    Before you change your Zitadel settings, we highly recommend you to create a service account with a personal access token (PAT) and the IAM_OWNER role.
+    In case something breaks, you can use this PAT to revert your changes or fix the settings so you can use a login UI again.
 </Callout>
@@ -62,8 +62,8 @@ ZITADEL simplifies multi-tenancy authentication by securely managing authenticat

 Key features include:

-1. **Secure Tenant Isolation**: Ensures robust security measures to prevent unauthorized access between tenants, maintaining data privacy and compliance. [Administrators](/concepts/structure/administrators) for an organization have only access to data and configuration within their Organization.
-2. **Custom Authentication Configurations**: Allows tailored [authentication settings](/guides/manage/console/default-settings#login-behavior-and-access), [branding](/guides/manage/customize/branding), and policies for each tenant.
+1. **Secure Tenant Isolation**: Ensures robust security measures to prevent unauthorized access between tenants, maintaining data privacy and compliance. [Administrators](/concepts/structure/administrators) for an organization have only access to data and settings within their Organization.
+2. **Custom Authentication Settings**: Allows tailored [authentication settings](/guides/manage/console/default-settings#login-behavior-and-access), [branding](/guides/manage/customize/branding), and policies for each tenant.
 3. **Centralized Management**: Provides [centralized administration](/guides/manage/console/administrators) for efficient management across all tenants.
 4. **Scalability and Flexibility**: Scales seamlessly to accommodate growing organizations of all sizes.
 5. **Domain Discovery**: Starting on a central login page, route users to their tenant based on their email address or other user attributes. Authentication settings will be applied automatically based on the organization's policies, this includes routing users seamlessly to third party identity providers like [Entra ID](/guides/integrate/identity-providers/azure-ad-oidc).
@@ -169,7 +169,7 @@ You can also activate the v2 login for your apps, so users are redirected to `/u

        To activate it to authenticate on your Zitadel Cloud apps, you can follow one of these steps:

-        1. Enable the new login on your application configuration. Leave the field **Custom base URL for the new Login UI** empty to use the default. With these settings, Zitadel will automatically redirect you to the new login if you call the old one.
+        1. Enable the new login on your application settings. Leave the field **Custom base URL for the new Login UI** empty to use the default. With these settings, Zitadel will automatically redirect you to the new login if you call the old one.
        ![](../../../../public/img/guides/integrate/login/login-v2-app-config.png)
        2. Enable the [loginV2 feature](/reference/api/feature/zitadel.feature.v2.FeatureService.SetInstanceFeatures) on the instance. Leave the base URI empty to use the default. If you enable this feature, the login will be used for every application configured in your Zitadel instance. (Example: https://your-zitadel-instance.zitadel.cloud/ui/v2/login)

@@ -189,7 +189,7 @@ You can also activate the v2 login for your apps, so users are redirected to `/u
        6. Use the new login in your application.
            <PreventLockout components={props.components} />
            You have three different options on how to achieve this:
-            1. Enable the new login on your application configuration and add the URL of your login UI. With these settings, Zitadel will automatically redirect you to the new login if you call the old one.
+            1. Enable the new login on your application settings and add the URL of your login UI. With these settings, Zitadel will automatically redirect you to the new login if you call the old one.
            ![](../../../../public/img/guides/integrate/login/login-v2-app-config.png)
            2. Enable the [loginV2 feature](/reference/api/feature/zitadel.feature.v2.FeatureService.SetInstanceFeatures) on the instance and add the URL of your login. If you enable this feature, the login will be used for every application configured in your Zitadel instance. (Example: https://my-new-zitadel-login.vercel.app)
            3. Change the issuer in the code of your application to the new domain of your login
@@ -37,7 +37,7 @@ Authentication with SAML (Security Assertion Markup Language) involves a series

 2. **Service Provider Redirects to Identity Provider**: The service provider (SP) detects that the user needs to be authenticated and redirects the user's browser to the designated identity provider (IdP) for authentication. This redirection often occurs via a SAML request, which includes information about the service provider and a request for authentication.

-3. **User Authenticates with Identity Provider**: The user is presented with the identity provider's login page, where they enter their credentials (username and password). Alternatively, depending on the IdP's configuration, the user might be authenticated using single sign-on (SSO) mechanisms such as a pre-existing session or multi-factor authentication.
+3. **User Authenticates with Identity Provider**: The user is presented with the identity provider's login page, where they enter their credentials (username and password). Alternatively, depending on the IdP's settings, the user might be authenticated using single sign-on (SSO) mechanisms such as a pre-existing session or multi-factor authentication.

 4. **Identity Provider Generates SAML Assertion**: Upon successful authentication, the identity provider creates a SAML assertion containing information about the user, such as their identity and attributes. This assertion is digitally signed by the identity provider to ensure its integrity and authenticity.

@@ -9,7 +9,7 @@ You're also allowed to use http://localhost, http://127.0.0.1 and http:[::1] wit
 After the application creation, you might want to set additional options like `refresh_token` and `additional origins`.

 If you want to request refresh_tokens and use them to renew the user's access_tokens without their interaction,
-enable them in the OIDC Configuration section by ticking the checkbox.
+enable them in the OIDC Settings section by ticking the checkbox.

 When calling the userinfo_endpoint or any ZITADEL API, we will check if an origin header is sent. This is automatically done
 by the user agent. If one is sent we will check if the origin is allowed for your application. By default, all computed
@@ -96,13 +96,13 @@ two web key pairs are created with one activated.
 ### Creation

 The web key [create](/apis/resources/webkey_service_v2/zitadel-webkey-v-2-web-key-service-create-web-key) endpoint generates a new web key pair,
-using the passed generator configuration from the request. This config is a one-of field of:
+using the passed generator settings from the request. This config is a one-of field of:

 - RSA
 - ECDSA
 - ED25519

-When the request does not contain any specific configuration,
+When the request does not contain any specific settings,
 [RSA](#rsa) is used as default with the default options as described below:

 ```bash
@@ -347,7 +347,7 @@ Cache-Control: max-age=300, must-revalidate
 ```

 Self-hosters can modify this setting through the `ZITADEL_OIDC_JWKSCACHECONTROLMAXAGE`
-environment variable or in the configuration yaml:
+environment variable or in the settings yaml:

 ```yaml
 OIDC:
@@ -30,7 +30,7 @@ The SAML ecosystem is mature, with extensive support from a wide range of enterp
 - **Assertion Consumer Service (ACS)**: The endpoint at the SP responsible for processing the SAML response.
 - **Attributes**: User information within the SAML response.
 - **Relay State**: A way for the IdP to remember where a user was before authentication.
- **SAML Trust**: The configuration between the identity provider and the service provider
+- **SAML Trust**: The settings between the identity provider and the service provider
 - **Metadata**: Trust information exchanged between the identity provider and service provider

 ## SAML explained
@@ -6,7 +6,7 @@ sidebar_label: Onboard B2B customer
 In this guide we will explain how you can create and set up new organizations in ZITADEL to help you with your onboarding flows.
 Creating a new organization is the best choice for multi-tenancy use cases that require separation of customers, teams, or groups of users.

-We will also explain how to leverage [Administrators](/guides/manage/console/administrators) to delegate self-service team management and configuration of policies to users of each organization.
+We will also explain how to leverage [Administrators](/guides/manage/console/administrators) to delegate self-service team management and setting up policies to users of each organization.

 When you want to build an onboarding process for your business customers you have to go through the following steps:

@@ -50,7 +50,7 @@ Click on the newly created organization in the list and you will switch your con

 ### Add First Administrator

-Create the first user for your customer and ensure the user has enough permissions to self-manage the needed configuration.
+Create the first user for your customer and ensure the user has enough permissions to self-manage the needed settings.

 #### Create User

@@ -102,13 +102,13 @@ This setting does generally allow users to authenticate with an external provide
 1. Go to the Settings Page
 2. Navigate to Identity Providers
   You might already see a list of activated providers here. If so, this is because some default providers are configured on the ZITADEL instances.
-3. Configure the identity provider you need.
-   Follow our detailed configuration description of the different providers we have: [Configure the needed identity provider](/guides/integrate/identity-providers/introduction)
+3. Set up the identity provider you need.
+   Follow our detailed setup description of the different providers we have: [Set up the needed identity provider](/guides/integrate/identity-providers/introduction)

 #### Auto-register users with SSO

 Let's assume you have configured Entra ID as an identity provider, and you want to allow all your employees to login with the corresponding user without having to register.
-This does need some specific configuration on your provider.
+This does need some specific settings on your provider.

 1. Go to the detail page of your configured identity provider (In this example Entra ID)
 2. Enable "Automatic creation" in the optional settings. Optionally, if you want to update the user information in ZITADEL, when they have changed in the Entra ID additionally enable "Automatic update"
@@ -98,12 +98,12 @@ You can only setup authentication with the built-in form.

 #### Registration with Social Login

-To allow your users to register with social logins you have to configure the external identity providers.
+To allow your users to register with social logins you have to set up the external identity providers.
 If you only need the social logins for your end users and you want to have them all in the organization, we recommend using the default organization for those users.
-In that case you can configure the identity providers on the default organization.
+In that case you can set up the identity providers on the default organization.
 If you want to have the social logins on different organizations you can configure the default on the instance, and enable it on the needed organizations.

-Please follow the configuration guides for the needed providers: [Let Users Login with Preferred Identity Provider in ZITADEL](/guides/integrate/identity-providers/introduction)
+Please follow the setup guides for the needed providers: [Let Users Login with Preferred Identity Provider in ZITADEL](/guides/integrate/identity-providers/introduction)

 The configured providers will be shown on the first login screen or when the users click on the registration button, they will be able to choose between local account or the social login.

@@ -114,10 +114,10 @@ The configured providers will be shown on the first login screen or when the use

 #### Registration with Organization External Identity Provider

-If your business customer already have an identity provider, and you want to allow SSO for them, you can configure their providers directly for their organization.
-Configure the needed provider such as Entra ID or OKTA.
+If your business customer already have an identity provider, and you want to allow SSO for them, you can set up their providers directly for their organization.
+Set up the needed provider such as Entra ID or OKTA.

-Please follow the configuration guides for the needed providers: [Let Users Login with Preferred Identity Provider in ZITADEL](/guides/integrate/identity-providers/introduction)
+Please follow the setup guides for the needed providers: [Let Users Login with Preferred Identity Provider in ZITADEL](/guides/integrate/identity-providers/introduction)

 <OrgLoginDescription components={props.components}  name="OrgLoginDescription" />

@@ -78,7 +78,7 @@ Like the example in the above image:

    * For **OAuth 2**, provide the client credentials (Client ID, Client Secret, token URL, authorization URL).

-12. Click **Test Connection Configuration** to verify the integration (optional but recommended), then click **Save**.
+12. Click **Test Connection Settings** to verify the integration (optional but recommended), then click **Save**.

 13. Under the **Provisioning to App** settings, enable:

@@ -85,7 +85,7 @@ Then check the box "Enforce single sign-on" and confirm by clicking "Update".
 Add members to your policy.
 ![](../../../../public/img/saml/atlassian/atlassian-06.png)

-## Verify configuration
+## Verify settings

 Now you should be all set to verify your setup:

@@ -31,7 +31,7 @@ In Authentication > Enterprise
 3. The issuer url is `https://${CUSTOM_DOMAIN}/.well-known/openid-configuration`
 4. Copy the callback URL (ending with `/login/callback`)

-The configuration should look like this:
+The settings should look like this:

 ![](../../../../public/img/oidc/auth0/auth0-init-app.png)

@@ -35,7 +35,7 @@ Cloudflare will return an error "User email was not returned. API permissions ar
 5. Add the following claims: "openid", "profile", "email"
 6. Test the connection

-### Example configuration
+### Example settings

 ```json
 {
@@ -26,7 +26,7 @@ Prerequisites:
 Please follow the instructions on [Gitlab docs](https://docs.gitlab.com/ee/user/group/saml_sso/index.html) to configure a SAML identity provider for SSO.
 The following instructions give you a quick overview of the most important steps.

-[Open the group](https://gitlab.com/dashboard/groups) to which you want to add the SSO configuration.
+[Open the group](https://gitlab.com/dashboard/groups) to which you want to add the SSO settings.
 Select on the menu Settings and then SAML SSO.
 Copy `GitLab metadata URL` for the next step.
 ![](../../../../public/img/saml/gitlab/gitlab-01.png)
@@ -47,9 +47,9 @@ Enter the URL from before, then click "Continue".
 Check your application, if everything is correct, press "Create".
 ![](../../../../public/img/saml/zitadel/application_saml_create.png)

-## **Gitlab**: Configuration
+## **Gitlab**: Setup

-Complete the configuration as follows:
+Complete the setup as follows:

 - `Identity provider single sign-on URL`: `${CUSTOM_DOMAIN}/saml/v2/SSO`
 - `Certificate fingerprint`: You need to download the certificate from \{your_instance_domain}/saml/v2/certificate and create a SHA1 fingerprint
@@ -58,9 +58,9 @@ Save the changes.

 ![](../../../../public/img/saml/gitlab/gitlab-02.png)

-## **Gitlab**: Verify SAML configuration
+## **Gitlab**: Verify SAML setup

-Once you saved the changes, click on the button "Verify SAML configuration".
+Once you saved the changes, click on the button "Verify SAML settings".

 You should be redirected to ZITADEL.
 Login with your user.
@@ -20,9 +20,9 @@ Prerequisites:

 <CreateApp components={props.components}  appType="web" authType="code" appName="Gitlab" redirectURI="https://<your_gitlab_url>/users/auth/openid_connect/callback"/>

-## Gitlab configuration
+## Gitlab settings

-Follow [this guide](https://docs.gitlab.com/ee/administration/auth/oidc.html) of gitlab to configure the omniauth provider. Following is an example configuration with redacted secrets.
+Follow [this guide](https://docs.gitlab.com/ee/administration/auth/oidc.html) of gitlab to configure the omniauth provider. Here are some example settings with redacted secrets.

 Replace the values of the following fields:

@@ -18,7 +18,7 @@ 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-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).
+- prerequisites on Google Cloud side [in the settings 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 Management Console and if
 > the headings start with "Google Cloud" please refer to the configuration guide on Google Cloud.
@@ -41,7 +41,7 @@ Download the public certificate from your ZITADEL instance by requesting `${CUST

 Always replace `${CUSTOM_DOMAIN}` with your Custom Domain.

-Use the following configuration
+Use the following settings

 | Setting | Value |
 | --- | --- |
@@ -127,7 +127,7 @@ Download the public certificate from your ZITADEL instance by requesting `${CUST

 Always replace `${CUSTOM_DOMAIN}` with your Custom Domain.

-Use the following configuration
+Use the following settings

 | Setting                  | Value                                              |
 |--------------------------|----------------------------------------------------|
@@ -33,7 +33,7 @@ This is a guide on how to secure your API using [Basic Authentication](/apis/ope
    alt="Register the API"
 />

-4. Now review your configuration and click **Create**.
+4. Now review your settings and click **Create**.

 <img
     src="/docs/img/guides/integrate/token-introspection-basic-auth-4.png"
@@ -15,7 +15,7 @@ Here's a breakdown of some key points about ZITADEL APIs:
 * **Auth API:** Used by authenticated users for tasks related to their accounts.
 * **Management API:** Used by organization administrators for administrative tasks.
 * **Admin API:** Used for administrative functions on the ZITADEL instance itself (may require separate user setup).
-* **System API:** For ZITADEL self-hosted deployments only, providing superordinate control (requires specific configuration).
+* **System API:** For ZITADEL self-hosted deployments only, providing superordinate control (requires specific settings).

 <Callout title="Resource-based APIs">
 ZITADEL is transitioning from a use-case based API structure to a resource-based one, aiming to simplify API usage.
@@ -43,7 +43,7 @@ Instead, you call the Auth API with the token of the user.
 ### Accessing System API

 With the System API developers can manage different ZITADEL instances.
-The System API can't be accessed by service accounts and requires a special configuration and authentication that can be found in our [guide to access ZITADEL's System API](./access-zitadel-system-api).
+The System API can't be accessed by service accounts and requires special settings and authentication that can be found in our [guide to access ZITADEL's System API](./access-zitadel-system-api).

 [Reference documentation for system API](/apis/introduction#system)

@@ -11,7 +11,7 @@ The ZITADEL System API is currently only available for ZITADEL Self-Hosted deplo
 ## System API User

 The System API works superordinate over all instances. Therefore, you need to define a separate users to get access to this API.
-You can do so by customizing the [runtime configuration](/self-hosting/manage/configure/configure#runtime-configuration-file).
+You can do so by customizing the [runtime settings](/self-hosting/manage/configure/configure#runtime-configuration-file).

 To authenticate the user a self-signed JWT will be created and utilized.

@@ -33,9 +33,9 @@ and export a public key from the newly created private key:
 openssl rsa -in system-user-1.pem -outform PEM -pubout -out system-user-1.pub
 ```

-## Runtime Configuration
+## Runtime Settings

-Provide the **public** key to the ZITADEL runtime configuration.
+Provide the **public** key to the ZITADEL runtime settings.

 Either with the path to the key:

@@ -179,7 +179,7 @@ You should get a successful response with a `totalResult` number of 1 and the de
 ## Summary

 * Create an RSA keypair
-* Provide the public key with a userID to ZITADEL using the runtime configuration
+* Provide the public key with a userID to ZITADEL using the runtime settings
 * Authorize the request with a JWT signed with your private key

 Where to go from here:
@@ -16,7 +16,7 @@ In this case please enable the Feature Flag "Use V2 Api in Management Console fo
        - **Setup authentication later for this user**: This flow might be useful if an employee starts at a later point but you already want to prepare the account. The user will not have an authentication method, before they will be able to login, they need to setup a method.
        - **Send an invitation E-Mail for authentication setup and E-Mail verification**: The user will receive an email and be able to setup an authentication method (e.g Password, Passkey, External SSO).
            - When using the [Zitadel Login V1](/guides/integrate/login/hosted-login) the user will be prompted to setup a password
-            - When using the [Zitadel Login V2](/guides/integrate/login/hosted-login#hosted-login-version-2) the user has the option to choose the authentication method (password, passkey, identity provider), based on the configuration of the organization
+            - When using the [Zitadel Login V2](/guides/integrate/login/hosted-login#hosted-login-version-2) the user has the option to choose the authentication method (password, passkey, identity provider), based on the settings of the organization
                <img src="/docs/img/guides/console/setupauthmethod.png" width="680px" alt="Invite Human - Setup authentication method" />
        - **Set an initial password for the user**: The user will receive an email and be able to setup an authentication method (e.g Password, Passkey, External SSO)

@@ -21,7 +21,7 @@ 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.
+3.  **Flow:** The settings that links an Action to a Trigger Type.

 ### The JavaScript Runtime

@@ -60,6 +60,6 @@ InternalAuthZ:

 # Administrator Permission Matrix

-This table is generated dynamically from our configuration file.
+This table is generated dynamically from our settings file.

 <PermissionTable data={permissionData} />
@@ -86,9 +86,9 @@ 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.
+You can find example settings for SAML 2.0 in our [integrate services](../../integrate/login/saml) guides.

-## Configuration
+## Settings

 ### Redirect URIs

@@ -134,15 +134,15 @@ 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`
 </Callout>

-### Review Configuration
+### Review Settings

 <ReviewConfig components={props.components} authType="code" />

 ## Application Settings

-After creating an application, you can modify its configuration.
+After creating an application, you can modify its settings.
 * **Auth Method:** You can switch authentication methods (e.g., from Basic to Private Key JWT) via the toggle or dropdowns.
-* **OIDC Compliance:** The Management Console checks if your configuration is OIDC compliant and shows tasks for completion if anything is missing.
+* **OIDC Compliance:** The Management Console checks if your settings are OIDC compliant and shows tasks for completion if anything is missing.

 <Callout type="caution">
 You **cannot** change the Application Type (e.g., from Web to Native) after creation. You must delete and recreate the application.
@@ -179,10 +179,10 @@ If your application makes requests from domains other than the Redirect URI (e.g

 ## Security Considerations

-Ensure the configuration of application settings is limited to authorized users only.
+Ensure the management of application settings is limited to authorized users only.

 * Use [Administrator roles](./administrators) to limit permissions for your users to make changes to your applications.
-* When [granting projects](../../../concepts/structure/granted_projects) to other organizations, the receiving organization **cannot** see or change the application configuration. They can only assign roles.
+* When [granting projects](../../../concepts/structure/granted_projects) to other organizations, the receiving organization **cannot** see or change the application settings. They can only assign roles.

 ## References

@@ -5,7 +5,7 @@ sidebar_label: Management Console

 ## Overview

-The ZITADEL Management 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 [Administrators](/concepts/structure/administrators) can perform tasks related to identity and access management, configure authentication methods, and manage the organization's infrastructure.
+The ZITADEL Management Console is the web-based Dashboard UI designed to facilitate the management and administration of ZITADEL resources and settings. It serves as a central hub where [Administrators](/concepts/structure/administrators) can perform tasks related to identity and access management, configure authentication methods, and manage the organization's infrastructure.

 While the Management 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](/guides/solution-scenarios/restrict-console) to build your own custom UI.

@@ -42,7 +42,7 @@ The Management Console enables administrators to perform the following critical
 4.  **Access Control:** Define and manage permissions. Administrators can assign [Roles](/guides/manage/console/roles) to users and configure fine-grained access controls for specific resources.
 5.  **Administrator Assignment:** Delegate administrative tasks by assigning **Administrator** 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](/guides/manage/customize/branding) to match your corporate identity.
-7.  **Audit Logging:** Access [Audit Logs](/concepts/features/audit-trail) to track user activity and configuration changes. This is essential for monitoring security events and maintaining regulatory compliance.
+7.  **Audit Logging:** Access [Audit Logs](/concepts/features/audit-trail) to track user activity and setting changes. This is essential for monitoring security events and maintaining regulatory compliance.

 ## Security and Restrictions

@@ -66,7 +66,7 @@ In the Branding settings, you can upload you Logo for the login interface, set y
 | Font              | Upload your custom font                                                                                                                                                                                                    |
 | Advanced Behavior | **Hide Loginname suffix**: If enabled, your loginname suffix (Domain) will not be shown in the login page. **Disable Watermark**: If you disable the watermark you will not see the "Powered by ZITADEL" in the login page |

-Make sure you click the "Apply configuration" button after you finish your configuration. This will ensure your design is visible for your customers.
+Make sure you click the "Apply settings" button after you finish your settings. This will ensure your design is visible for your customers.

 Branding settings applied on you instance act as a default for all your organizations. If you need custom branding on a organization take a look at our guide under [organization setting](./organizations-overview#organization-settings).

@@ -115,7 +115,7 @@ To configure your custom SMTP please fill the following fields:

 <img src="/docs/img/guides/console/smtp.png" alt="SMTP" width="800px" />

-While you create/update a SMTP provider you have the chance to test your SMTP configuration
+While you create/update a SMTP provider you have the chance to test your SMTP settings

 <img src="/docs/img/guides/console/smtp_test.png" alt="SMTP" width="800px" />

@@ -125,7 +125,7 @@ In the SMTP providers table you can hover on a provider row to show buttons that

 ### SMS

-No default provider is configured to send some SMS to your users. If you like to validate the phone numbers of your users make sure to add your twilio configuration by adding your Sid, Token and either a Sender Number or a Verification Service Sid.
+No default provider is configured to send some SMS to your users. If you like to validate the phone numbers of your users make sure to add your twilio settings by adding your Sid, Token and either a Sender Number or a Verification Service Sid.
 Setting a Verification Service Sid allows using the Twilio Verify Service instead of the Messages Service for verification.

 <img src="/docs/img/guides/console/twilio.png" alt="Twilio" />
@@ -155,7 +155,7 @@ The Login Policy defines how the login process should look like and which authen

 The Default Redirect URI will be used, if a user calls the login page directly.
 More specifically, typically an application will initiate login with an auth request.
-The auth request contains a client-id and a redirect uri, that must match the configuration in ZITADEL.
+The auth request contains a client-id and a redirect uri, that must match the settings in ZITADEL.
 If there is no [auth request](https://zitadel.com/playgrounds/oidc), users will be redirected to the Default Redirect URI, which is by default `https://${CUSTOM_DOMAIN}/ui/console/`

 Reasons why ZITADEL doesn't have a redirect URI:
@@ -208,10 +208,10 @@ Configure the different lifetimes checks for the login process:

 ## Identity Providers

-You can configure all kinds of external identity providers for identity brokering, which support OIDC (OpenID Connect).
+You can set up all kinds of external identity providers for identity brokering, which support OIDC (OpenID Connect).
 Create a new identity provider configuration and enable it in the list afterwards.

-For a detailed guide about how to configure a new identity provider for identity brokering have a look at our [identity provider guides](/guides/integrate/identity-providers/introduction).
+For a detailed guide about how to set up a new identity provider for identity brokering have a look at our [identity provider guides](/guides/integrate/identity-providers/introduction).

 ## Password Complexity

@@ -288,7 +288,7 @@ All usernames will then be globally unique within your instance.

 You can either set this attribute on your whole ZITADEL instance or just on some specific organizations.

-Please refer to the [configuration guide](/guides/solution-scenarios/configurations#use-email-to-login) for more information.
+Please refer to the [settings guide](/guides/solution-scenarios/configurations#use-email-to-login) for more information.

 ## External links

@@ -358,7 +358,7 @@ Choose a default language which acts as a fallback, if no language header is set

 ## OIDC token lifetimes and expiration

-Configure how long the different oidc tokens should life.
+Set up how long the different oidc tokens should live.
 You can set the following times:

 - Access Token Lifetime
@@ -375,8 +375,8 @@ You can set the following times:
 ## Secret generator

 ZITADEL has some different codes and secrets, that can be specified.
-You can configure what kind of characters should be included, how long the secret should be and the expiration.
-The following secrets can be configured:
+You can specify what kind of characters should be included, how long the secret should be and the expiration.
+The following secrets can be specified:

 - Initialization Mail Code
 - Email verification code
@@ -66,7 +66,7 @@ When no specific organization is selected (e.g., during an auth request or via [

 ## Usernames and Domains

-Each organization has its own pool of users, covering both users and service accounts. How these users authenticate depends on your domain configuration.
+Each organization has its own pool of users, covering both users and service accounts. How these users authenticate depends on your domain settings.

 ### Login Name Formats
 By default, if the setting **User Loginname must contain orgdomain** is **disabled**, usernames are unique across the entire instance.
@@ -131,7 +131,7 @@ Do not delete the DNS verification record after success. ZITADEL re-checks domai

 ## 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.
+Organizations can inherit settings 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.
@@ -3,7 +3,7 @@ title: Brand Customization
 ---

 ZITADEL offers various customization options for your projects brand design. The branding can be configured on two different levels.
-The configuration on the instance level will set the default settings, which are triggered for all users if not overwritten on an organization specifically.
+The settings on the instance level will set the default settings, which are triggered for all users if not overwritten on an organization specifically.
 The second possibility is to configure it on each organization. This guide will describe the second possibility.
 For this head over to the Branding Setting on your Organization Page.

@@ -11,7 +11,7 @@ For this head over to the Branding Setting on your Organization Page.

 You are able to customize the light and a dark mode separately.
 All your changes will be shown in the preview window on the right side.
-As soon as you are happy with your configuration click the "Apply configuration" button.
+As soon as you are happy with your settings click the "Apply settings" button.
 After this your settings will trigger in your system. The login and the emails will be sent with your branding.

 ## Settings
@@ -13,7 +13,7 @@ ZITADEL integrates with Twilio as SMS provider.

 ## SMTP providers

-For easy configuration, there are some integration templates available such as:
+For easy setup, there are some integration templates available such as:

 - Amazon SES
 - Mailgun
@@ -3,7 +3,7 @@ title: Feature Restrictions
 ---

 New self-hosted and [ZITADEL Cloud instances](https://zitadel.com/admin) are unrestricted by default.
-Self-hosters can change this default using the DefaultInstance.Restrictions configuration section.
+Self-hosters can change this default using the DefaultInstance.Restrictions settings section.
 Users with the role IAM_OWNER can change the restrictions of their instance using the [Feature Restrictions Admin API](/reference/api/admin).
 Currently, the following restrictions are available:

@@ -21,7 +21,7 @@ You can do so by using [Console](../console/users) or [setting user metadata](/r

 Most of the methods below require you to login with the correct user while setting some scopes.
 Make sure you pick the right user when logging into the test application.
-Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
+Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the settings of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.

 <Callout title="Getting a token">
 In case you want to test out different settings configure an application with code flow (PKCE).
@@ -149,7 +149,7 @@ You can use the authentication service to request and search for the user's meta
 The introspection endpoint and the token endpoint in the examples above do not require a special scope to access.
 Yet when accessing the authentication service, you need to pass the [reserved scope](/apis/openidoauth/scopes#reserved-scopes) `urn:zitadel:iam:org:project:id:zitadel:aud` along with the authentication request.
 This scope allows the user to access ZITADEL's APIs, specifically the authentication API that we need for this method.
-Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
+Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the settings of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.

 <Callout title="Invalid audience">
 If you get the error "invalid audience (APP-Zxfako)", then you need to add the reserved scope `urn:zitadel:iam:org:project:id:zitadel:aud` to your authentication request.
@@ -58,8 +58,8 @@ For more information about user metadata, see [here](../customize/user-metadata)
 | `timezone`             | `metadata[urn:zitadel:scim:timezone]`                                                                     |                                                                                                                                                                                                                                                |
 | `active`               | `state`                                                                                                   | `Initial` and `Active` are mapped to `active = true`, all other states are mapped to `active = false`.<br />The `active` value can only be updated if the user is in the state `Active` or `Inactive`.                                         |
 | `password`             | `password`                                                                                                |                                                                                                                                                                                                                                                |
-| `emails`               | `email`                                                                                                   | Only the `primary` email is stored in Zitadel, if there is no `primary` email, the first one is stored. By default emails from SCIM are considered verified, this can be adjusted in the [configuration](#configuration).                      |
-| `phoneNumbers`         | `phone`                                                                                                   | Only the `primary` phone number is stored in Zitadel, if there is no `primary` phone number, the first one is stored. By default phone numbers from SCIM are considered verified, this can be adjusted in the [configuration](#configuration). |
+| `emails`               | `email`                                                                                                   | Only the `primary` email is stored in Zitadel, if there is no `primary` email, the first one is stored. By default emails from SCIM are considered verified, this can be adjusted in the [settings](#settings).                      |
+| `phoneNumbers`         | `phone`                                                                                                   | Only the `primary` phone number is stored in Zitadel, if there is no `primary` phone number, the first one is stored. By default phone numbers from SCIM are considered verified, this can be adjusted in the [settings](#settings). |
 | `ims`                  | `metadata[urn:zitadel:scim:ims]`                                                                          | Serialized as JSON.                                                                                                                                                                                                                            |
 | `photos`               | `metadata[urn:zitadel:scim:photos]`                                                                       | Serialized as JSON.                                                                                                                                                                                                                            |
 | `addresses`            | `metadata[urn:zitadel:scim:addresses]`                                                                    | Serialized as JSON.                                                                                                                                                                                                                            |
@@ -67,9 +67,9 @@ For more information about user metadata, see [here](../customize/user-metadata)
 | `roles`                | `metadata[urn:zitadel:scim:roles]`                                                                        | Serialized as JSON.                                                                                                                                                                                                                            |
 | `externalId`           | `metadata[urn:zitadel:scim:externalId]`<br />`metadata[urn:zitadel:scim:{provisioningDomain}:externalId]` | See [provisioning domain](#provisioning-domain).                                                                                                                                                                                               |

-## Configuration
+## Settings

-This section provides details on the runtime configuration of the SCIM interface of Zitadel.
+This section provides details on the runtime settings of the SCIM interface of Zitadel.

 ### Defaults

@@ -78,7 +78,7 @@ This section provides details on the runtime configuration of the SCIM interface
 - Bulk SCIM operations can include up to **100 operations**
 - Maximum SCIM request body size is **1 MB**

-This behavior can be adjusted through the Zitadel runtime configuration settings:
+This behavior can be adjusted through the Zitadel runtime settings:

 ```yaml
 SCIM:
@@ -55,7 +55,7 @@ We provide some more information on migrating users and secrets in [this guide](

 ### Migrating clients / applications

-After you have set up or imported your applications to ZITADEL, you need to update your client's configurations, such as issuer, clientID or credentials.
+After you have set up or imported your applications to ZITADEL, you need to update your client's settings, such as issuer, clientID or credentials.
 It is not possible to create an application with a pre-defined clientID or import existing credentials.

 ## Technical considerations
@@ -90,7 +90,7 @@ curl  --request POST \
 ### Import from file

 <Callout>
-To import the exported data into you new instance, you have to have an already existing instance on a ZITADEL, with all desired configuration and global resources.
+To import the exported data into you new instance, you have to have an already existing instance on a ZITADEL, with all desired settings and global resources.
 </Callout>

 Then as an example you can use one request for the import:
@@ -161,7 +161,7 @@ data_orgsv1_gcs object:
 ### Import to GCS

 <Callout>
-To import the exported data into you new instance, you have to have an already existing instance on a ZITADEL, with all desired configuration and global resources.
+To import the exported data into you new instance, you have to have an already existing instance on a ZITADEL, with all desired settings and global resources.
 The used serviceaccount has to have at least the role "Storage Object Viewer" to read objects from GCS
 </Callout>

@@ -156,16 +156,16 @@ Essentially, a verifier ensures ZITADEL can work with passwords hashed using var
 </Callout>

 Regardless of the `passwordChangeRequired` setting, the password is rehashed using the configured hasher algorithm and stored.
-This ensures consistency and allows for automatic updates even when hasher configurations are changed, such as increasing salt cost for bcrypt.
+This ensures consistency and allows for automatic updates even when hasher settings are changed, such as increasing salt cost for bcrypt.

-To configure the default hasher for new user passwords, set the `Algorithm` of the `PasswordHasher` in the [runtime configuration file](/self-hosting/manage/configure/configure#runtime-configuration-file)
+To configure the default hasher for new user passwords, set the `Algorithm` of the `PasswordHasher` in the [runtime settings file](/self-hosting/manage/configure/configure#runtime-configuration-file)
 or by the environment variable `ZITADEL_SYSTEMDEFAULTS_PASSWORDHASHER_HASHER_ALGORITHM`, for example:

 ```
 ZITADEL_SYSTEMDEFAULTS_PASSWORDHASHER_HASHER_ALGORITHM='pbkdf2'
 ```

-Hasher configuration updates will automatically rehash existing passwords when they are validated or changed.
+Hasher settings updates will automatically rehash existing passwords when they are validated or changed.

 In case the hashes can't be transferred directly, you always have the option to create a user in ZITADEL without password and prompt users to create a new password.

@@ -1,9 +1,9 @@
 ---
-title: Configure ZITADEL for your Scenario
-sidebar_label: Common Configurations
+title: Set up ZITADEL for your Scenario
+sidebar_label: Common Settings
 ---

-Each customer does have different needs and use-cases. In ZITADEL you are able to configure your settings depending on your needs.
+Each customer does have different needs and use-cases. In ZITADEL you are able to adjust settings depending on your needs.
 In this section we show you the different use-cases we have already experienced, that could interest you.

 ## Automatically redirect users if the organization has only one identity provider
@@ -14,7 +14,7 @@ If a user of this organization wants to login, you don't want them to enter thei
 ### Settings

 1. Go to the "Identity Providers" Settings of the organization
-2. Configure the needed identity provider: Read this [guide](../integrate/identity-providers/introduction) if you don't know how
+2. Set up the needed identity provider: Read this [guide](../integrate/identity-providers/introduction) if you don't know how
 3. Go to the "Login Behavior and Security" settings of the organization
 4. Disable "Username Password Allowed" and enable "External IDP allowed" in the Advanced Section

@@ -7,7 +7,7 @@ This guide should explain how domain discovery works and how to configure it in

 ## Overview

-Domain discovery is typically used in [B2B](./b2b) or [SaaS](./saas) scenarios where you have users from different organizations and you want to route them according to their login methods, which could be a user name or, depending on your configuration, also an [email / phone number](./configurations#use-email-to-login).
+Domain discovery is typically used in [B2B](./b2b) or [SaaS](./saas) scenarios where you have users from different organizations and you want to route them according to their login methods, which could be a user name or, depending on your settings, also an [email / phone number](./configurations#use-email-to-login).

 ![](../../../public/img/guides/solution-scenarios/domain-discovery.png)

@@ -28,7 +28,7 @@ Follow this guide to configure your ZITADEL instance for this scenario.

 You will use the instance default settings for the login for the organization **CIAM**.
 When opening `login.mycompany.com` then the login policy of the instance will be applied.
-This means that you have to configure the [Login and Access](/guides/manage/console/default-settings#login-behavior-and-access) Policy and [Identity Providers](/guides/manage/console/default-settings#identity-providers) for the **CIAM** users on the instance itself.
+This means that you have to set up the [Login and Access](/guides/manage/console/default-settings#login-behavior-and-access) Policy and [Identity Providers](/guides/manage/console/default-settings#identity-providers) for the **CIAM** users on the instance itself.

 <Callout>
 You can also configure these settings on the default organization (see below) and send the scope `urn:zitadel:iam:org:id:{id}` with every [auth request](https://zitadel.com/playgrounds/oidc).
@@ -47,11 +47,11 @@ In the [Login Behavior and Security Settings](/guides/manage/console/default-set

 ### Configure login with email

-Follow this [configuration guide](/guides/solution-scenarios/configurations#use-email-to-login) to allow users to login with their email address.
+Follow this [settings guide](/guides/solution-scenarios/configurations#use-email-to-login) to allow users to login with their email address.

 ### Other considerations

-You can also have multiple Custom Domains pointing to the same instance as described in this [configuration guide](/guides/solution-scenarios/configurations#custom-application-domain-per-organization). In our example you could also use `alpha.mycompany.com` to show the login page of your instance.
+You can also have multiple Custom Domains pointing to the same instance as described in this [settings guide](/guides/solution-scenarios/configurations#custom-application-domain-per-organization). In our example you could also use `alpha.mycompany.com` to show the login page of your instance.

 The domain of your email notification can be changed by [setting up your SMTP](/guides/manage/console/default-settings#smtp).

@@ -64,14 +64,14 @@ Users of **Alpha** should only be allowed to authenticate with their company's i
 In the organization settings under Login Behavior and Access make sure the following settings are applied:

 - **Username Password allowed**: Disabled
- **Register allowed**: Disabled - we will configure this on the external identity provider
+- **Register allowed**: Disabled - we will set this up on the external identity provider
 - **External IDP allowed**: Enabled

-Now you can configure an [external identity provider](/guides/manage/console/default-settings#identity-providers).
+Now you can set up an [external identity provider](/guides/manage/console/default-settings#identity-providers).

 <Callout>
-Given you have only one external identity provider configured, when a user tries to login on that organization, then the user will be automatically redirected to the external identity provider.
-In case multiple providers are configured, then the user will be prompted to select an identity provider.
+Given you have only one external identity provider set up, when a user tries to login on that organization, then the user will be automatically redirected to the external identity provider.
+In case multiple providers are set up, then the user will be prompted to select an identity provider.
 </Callout>

 ### Beta organization
@@ -12,7 +12,7 @@ import { FileText, Folder, Link as LinkIcon } from 'lucide-react';

 <Cards>
    <Card title="B2b" href="/guides/solution-scenarios/b2b" icon={<FileText />} />
-    <Card title="Configurations" href="/guides/solution-scenarios/configurations" icon={<FileText />} />
+    <Card title="Common Settings" href="/guides/solution-scenarios/configurations" icon={<FileText />} />
    <Card title="Saas" href="/guides/solution-scenarios/saas" icon={<FileText />} />
    <Card title="B2c" href="/guides/solution-scenarios/b2c" icon={<FileText />} />
    <Card title="Frontend Calling Backend API" href="/guides/solution-scenarios/frontend-calling-backend-API" icon={<FileText />} />
--- a/Show More
+++ b/Show More