chore(docs): User (Human) naming consistency (#11512)

# Which Problems Are Solved Naming inconsistencies - User (Human) # How the Problems Are Solved Most of the occurrences have not been changed. `User (Human)` was mostly changed when talking about code objects and where I felt it was necessary to distinguish them from machine users. When both human and machine user occurrences were found, the machine user has been changed to service account (see https://github.com/zitadel/zitadel/issues/11285) # Additional Context - Closes #11284 --------- Co-authored-by: Wim Van Laer <[email protected]>
2026-10-18 05:52:51 +00:00 · 2026-02-06 09:46:24 +00:00
parent 21723df541
commit 1f0d54a978
91 changed files with 178 additions and 179 deletions
@@ -124,7 +124,7 @@ Authentication
 - [OpenID Connect certified](https://openid.net/certification/#OPs) => [OIDC Endpoints](https://zitadel.com/docs/apis/openidoauth/endpoints)
 - [SAML 2.0](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) => [SAML Endpoints](https://zitadel.com/docs/apis/saml/endpoints)
 - [Custom sessions](https://zitadel.com/docs/guides/integrate/login-ui/username-password) if you need to go beyond OIDC or SAML 
- [Machine-to-machine](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users) with JWT profile, Personal Access Tokens (PAT), and Client Credentials
+- [Machine-to-machine](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts) with JWT profile, Personal Access Tokens (PAT), and Client Credentials
 - [Token exchange and impersonation](https://zitadel.com/docs/guides/integrate/token-exchange)
 - [Beta: Hosted Login V2](https://zitadel.com/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta) our new Login version 2.0

@@ -77,7 +77,7 @@ The trigger is represented by the following Ids in the API: `TRIGGER_TYPE_PRE_CR
 - `ctx`
  The first parameter contains the following fields
  - `v1`
-    - `user` [*human*](./objects#human-user)
+    - `user` [*(human)*](./objects#human-user)
    - `authRequest` [*auth request*](/apis/actions/objects#auth-request)
    - `httpRequest` [*http request*](/apis/actions/objects#http-request)
    - `org`
@@ -64,7 +64,7 @@ title: Objects
 - `loginNames` Array of *string*
 - `preferredLoginName` *string*
 - `human`  
-  Set if the user is human
+  Set if User (Human)
  - `firstName` *string*
  - `lastName` *string*
  - `nickName` *string*
@@ -14,7 +14,7 @@ The [OpenID Connect & OAuth endpoints](/apis/openidoauth/endpoints) and [SAML 2.

 ## Authentication & authorization

-### Authentication for human users (interactive)
+### Authentication for users (interactive)

 ZITADEL implements industry standards such as OpenID Connect, OAuth 2.0, or SAML for authentication.
 Please refer to our guides how to [authenticate users](/guides/integrate/login/login-users) through an interactive authentication process.
@@ -23,10 +23,10 @@ For user authentication on devices with limited accessibility (eg, SmartTV, Smar

 Additionally, you can use the [session API](/reference/api/session) to authenticate users, for example by building a [custom login UI](/guides/integrate/login-ui).

-### Authenticate service users and machines
+### Authenticate service accounts

 Service users allow for machine-to-machine (M2M) communication.
-Follow the guides to learn how to [authenticate service users](/guides/integrate/service-users/authenticate-service-users).
+Follow the guides to learn how to [authenticate service accounts](/guides/integrate/service-accounts/authenticate-service-accounts).

 Accessing the ZITADEL APIs through a service user might require additional steps, please follow the guide on how to [access ZITADEL APIs](../guides/integrate/zitadel-apis/access-zitadel-apis) to include the correct audience scope in your requests.

@@ -98,8 +98,8 @@ No major changes have been made to the organization requests.
 When migrating your user management from v1 to v2, the most significant updates involve user states and the initial onboarding process:

 - **Unified User Creation Endpoint**:
-  - A significant simplification in v2 is the consolidation of user creation. There is now one primary endpoint for creating users, regardless of whether they are human or machine users.
-  - You can use this single endpoint to provision both human users (individuals interacting with your application) and machine users (e.g., service accounts, API clients), typically by specifying the user type in the request payload.
+  - A significant simplification in v2 is the consolidation of user creation. There is now one primary endpoint for creating users, regardless of whether they are User (Human) or machine users.
+  - You can use this single endpoint to provision both users (individuals interacting with your application) and service accounts (i.e. API clients), typically by specifying the user type in the request payload.
 - **No More "Initial" State**:
  - In v1, new users without a password or verified email were automatically assigned an initial state. This default assumption wasn't always ideal.
  - In v2, this initial state has been removed. All newly created users are now active by default, regardless of their initial attributes.
@@ -31,7 +31,7 @@ The base URL for the SCIM endpoint in Zitadel is: `https://${CUSTOM_DOMAIN}/scim
 ## Authentication

 The SCIM interface adheres to Zitadel's standard API authentication methods.
-For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Users Guide](/guides/integrate/service-users/authenticate-service-users).
+For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Users Guide](/guides/integrate/service-accounts/authenticate-service-accounts).

 ## Query

@@ -826,7 +826,7 @@ curl -G "https://${DOMAIN}/scim/v2/${ORG_ID}/ServiceProviderConfig" \
      "name": "Zitadel authentication token",
      "description": "Authentication scheme using the OAuth Bearer Token Standard",
      "specUri": "https://www.rfc-editor.org/info/rfc6750",
-      "documentationUri": "https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users",
+      "documentationUri": "https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts",
      "type": "oauthbearertoken",
      "primary": false
    }
@@ -62,14 +62,14 @@ The Command Side has some unique requirements, these include:
 ##### Command Handler

 The command handler receives all operations who alter a resource managed by Zitadel.
-For example if a user changes his name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
+For example if a user changes their name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
 The command handler is then responsible of creating the necessary commands.
 After creating the commands the command hand them down to the command validation.

 ##### Command Validation

 With the received commands the command validation will execute the business logic to verify if a certain action can take place.
-For example if the user really can change his name is verified in the command validation.
+For example if the user can really change their name is verified in the command validation.
 If this succeeds the command validation will create the events that reflect the changes.
 These events now are being handed down to the storage layer for storage.

@@ -47,7 +47,7 @@ Since everything that is available in Management Console can also be called with
 - [Event API Guide](/guides/integrate/zitadel-apis/event-api)
 - [API Documentation](/reference/api/admin)

-Access to the API is possible with a [Service User](/guides/integrate/service-users/authenticate-service-users) account, allowing you to integrate the events with your own business logic.
+Access to the API is possible with a [Service User](/guides/integrate/service-accounts/authenticate-service-accounts) account, allowing you to integrate the events with your own business logic.

 ## Using logs in external systems

@@ -68,7 +68,7 @@ Given an external identity provider is configured on the instance or on the orga
 ### Machines

 Machine accounts can't use an interactive login but require other means of authentication, such as privately signed JWT or personal access tokens.
-Read more about [Service Users](/guides/integrate/service-users/authenticate-service-users) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).
+Read more about [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).

 ## Logout

@@ -1,4 +1,4 @@
-Managers are [human users or service users](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
+Managers are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.

 Manager permissions can be assigned to different levels in ZITADEL:

@@ -14,4 +14,4 @@ ZITADEL allows you to give other organizations permission to manage certain aspe

 ![Project Grant](../../../public/img/concepts/objects/project_grants.png)

-Each organization has its own pool of usernames, which includes human and service users, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
+Each organization has its own pool of usernames, which includes users and service accounts, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
@@ -6,12 +6,12 @@ sidebar_label: Users
 ## Types of users

 ZITADEL supports authentication and authorization for different user types.
-We can mainly differentiate between Human Users and Machine Users.
+We can mainly differentiate between Users and Service Accounts.
 We typically call human users simply "Users" and machine users "Service Users".

-### Human users
+### Users

-Human users typically logon with an interactive login.
+Users typically logon with an interactive login.
 This means that an application redirects a user to a website ("login page") where the user can provide the credentials.
 ZITADEL handles the authentication and provides the application with a token that verifies the authentication process.

@@ -21,13 +21,13 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use

 Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
 For example in ZITADEL you would require an authenticated Service User to access the Management API.
-The main difference between human and machine users is the type of credentials that can be used for authentication: Human users typically logon via an login prompt, but Machine users require a non-interactive logon process.
+The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.

-Learn how to [use service users](/guides/integrate/service-users/authenticate-service-users) with ZITADEL.
+Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.

 ### Managers

-Any user, human or service user, can be given a [Manager](/concepts/structure/managers) role.
+Any user or service account can be given a [Manager](/concepts/structure/managers) role.
 A user with an administrator role is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.

 ### Federated users
@@ -263,7 +263,7 @@ To call the API you need an access token, which is then verified by ZITADEL.
 Please follow [this guide here](/guides/integrate/token-introspection/private-key-jwt), ignoring the first step as we already have the `.json`-key-file from the serviceaccount.

 <Callout>
-You can also create a PAT for the serviceuser and use it to test the API. For this, follow [this guide](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat).
+You can also create a PAT for the serviceuser and use it to test the API. For this, follow [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat).
 </Callout>

 Optionally set the token as an environment variable:
@@ -15,7 +15,7 @@ The API will validate the access token on the [introspect endpoint](/apis/openid

 The API application uses [Client Secret Basic](/apis/openidoauth/authn-methods#client-secret-basic) to authenticate against ZITADEL and access the introspection endpoint.
 You can use any valid access_token from a user or service account to send requests to the example API.
-In this example we will use a service account with a [personal access token](/guides/integrate/service-users/personal-access-token) which can be used directly to access the example API.
+In this example we will use a service account with a [personal access token](/guides/integrate/service-accounts/personal-access-token) which can be used directly to access the example API.

 ## Running the example

@@ -186,7 +186,7 @@ CLIENT_SECRET = "NVAp70IqiGmJldbS...."

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

-1. Create a service user and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat).
+1. Create a service user and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat).
 2. To enable authorization, follow [this guide](/guides/manage/console/roles) to create a role `read:messages` on your project.
 3. Next, create an authorization for the service user you created by adding the role `read:messages` to the user. Follow this [guide](/guides/manage/console/roles#authorizations) for more information on creating an authorization.

@@ -117,7 +117,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
 ## Example call

 Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
-by calling the ZITADEL API to create a human user.
+by calling the ZITADEL API to create a user.

 ```shell
 curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
@@ -171,7 +171,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
 ## Example call

 Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
-by calling the ZITADEL API to create a human user.
+by calling the ZITADEL API to create a user.

 ```shell
 curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
@@ -152,7 +152,7 @@ You can do this by using **Webhook.site** (see [Creating a Listener with Webhook
 ## Example call

 Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
-by calling the ZITADEL API to create a human user.
+by calling the ZITADEL API to create a user.

 ```shell
 curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
@@ -121,7 +121,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
 ## Example call

 Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
-by calling the ZITADEL API to create a human user.
+by calling the ZITADEL API to create a user.

 ```shell
 curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
@@ -121,7 +121,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
 ## Example call

 Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
-by calling the ZITADEL API to create a human user.
+by calling the ZITADEL API to create a user.

 ```shell
 curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
@@ -137,7 +137,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \

 ## 7. Example Call

-Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or by calling the ZITADEL API to create a human user.
+Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or by calling the ZITADEL API to create a user.

 Here, we are creating a user via the API:

@@ -178,7 +178,7 @@ You can also activate the v2 login for your apps, so users are redirected to `/u

        The simplest way to deploy the new login for yourself is by using the [Deploy with Vercel button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) to deploy the login directly to your Vercel.

-        1. [Create a service user](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
+        1. [Create a service user](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
        2. Give the user IAM_LOGIN_CLIENT Permissions in the default settings (CUSTOM_DOMAIN/ui/console/instance?id=organizations)
        Note: [Zitadel Manager Guide](/guides/manage/console/managers)
        3. Deploy login to Vercel: You can do so by directly clicking the [“Deploy” button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) in our [repository](https://github.com/zitadel/zitadel)
@@ -12,7 +12,7 @@ Roles are critical to managing permissions in a single-tenant or multi-tenant ap

 ## Assign roles and memberships

-Human or service users can be assigned roles. You can do this via the ZITADEL Management Console or the ZITADEL APIs. As mentioned earlier, there are two types of roles in ZITADEL. You can have your own application-specific roles, and alternatively, ZITADEL also has administrator roles, such as `ORG_OWNER` and `IAM_OWNER`.
+Users or service accounts can be assigned roles. You can do this via the ZITADEL Management Console or the ZITADEL APIs. As mentioned earlier, there are two types of roles in ZITADEL. You can have your own application-specific roles, and alternatively, ZITADEL also has administrator roles, such as `ORG_OWNER` and `IAM_OWNER`.

 Follow the links below to assign roles to your users.

@@ -27,12 +27,12 @@ Roles can be requested via our auth and management APIs, from userinfo endpoint

 ### Generate a token

-You must first of all generate a token for the user. For human users, the typical approach involves using a front-end application and logging in through the browser or device. An access token will be returned after they log in successfully. A machine user will use a script or other program to generate a token using the JWT profile or client credentials grant types.
+You must first of all generate a token for the user. For users, the typical approach involves using a front-end application and logging in through the browser or device. An access token will be returned after they log in successfully. A service account will use a script or other program to generate a token using the JWT profile or client credentials grant types.

 How to generate a token:

- [Generate tokens for human users](/guides/integrate/login/oidc/login-users)
- [Generate tokens for service users](/guides/integrate/service-users/authenticate-service-users)
+- [Generate tokens for users](/guides/integrate/login/oidc/login-users)
+- [Generate tokens for service accounts](/guides/integrate/service-accounts/authenticate-service-accounts)

 In order to access role information via the token you must include the right audience and the necessary role claims in the scope and/or select the required role settings in the ZITADEL management console before requesting the token.

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

     * Client Credentials Grant

-4. Detailed instructions to authenticate the Service User can be found [here](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+4. Detailed instructions to authenticate the Service User can be found [here](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ## Step 2: Set Up SCIM in Okta

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

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

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

 * [ZITADEL SCIM 2.0 API Endpoints](https://zitadel.com/docs/apis/scim2)

@@ -1,6 +1,6 @@
 ---
-title: Authenticate service users and client applications
-sidebar_label: Authenticate service users
+title: Authenticate service accounts and client applications
+sidebar_label: Authenticate service accounts
 ---

 import DocCardList from '@/components/docusaurus/doc-card-list';
@@ -12,7 +12,7 @@ This guide explains ZITADEL service users and their role in facilitating secure
 Service users in ZITADEL represent **non-human entities** within your system.
 They are ideal for scenarios involving secure communication between applications, particularly when interacting with backend services or APIs.
 Service users in combination with [Manager](/concepts/structure/managers) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
-Unlike regular human users, service users don't rely on traditional login methods (e.g., username/password) and require alternative authentication mechanisms.
+Unlike users, service accounts don't rely on traditional login methods (e.g., username/password) and require alternative authentication mechanisms.

 ## Benefits of using Service Users

@@ -84,7 +84,7 @@ This method is still available in ZITADEL but is generally considered less secur
 ### Personal Access Tokens (PATs)

 * **Ready-to-use tokens:** Generated for specific service users and can be directly included in the authorization header of API requests.
-* **Currently available only for machine users** (service users) and not regular human users.
+* **Currently available only for service accounts** and not users.

 Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service users and applications.

@@ -127,7 +127,7 @@ However, [client credentials authentication](./client-credentials) might be cons

 ## Further resources

-* Read about the [different methods to authenticate service users](./authenticate-service-users)
+* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
 * [Service User API reference](/reference/api/user)
 * [OIDC JWT with private key](/apis/openidoauth/authn-methods#jwt-with-private-key) authentication method reference
 * [Access ZITADEL APIs](../zitadel-apis/access-zitadel-apis)
@@ -3,9 +3,9 @@ title: Configure client credential authentication for service users
 sidebar_label: Client credential authentication
 ---

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

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

 ## Steps to authenticate a Service User with client credentials

@@ -101,7 +101,7 @@ By following these steps and adhering to security best practices, you can effect

 ## Notes

-* Read about the [different methods to authenticate service users](./authenticate-service-users)
+* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
 * [Service User API reference](/reference/api/user)
 * [OIDC client secret basic](/apis/openidoauth/authn-methods#client-secret-basic) authentication method reference
 * [Access ZITADEL APIs](../zitadel-apis/access-zitadel-apis)
@@ -6,7 +6,7 @@ sidebar_label: Personal access token authentication
 A Personal Access Token (PAT) is a ready to use token which can be used as _Authorization_ header.
 At the moment ZITADEL only allows PATs for machine accounts (service users).

-It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service users](./authenticate-service-users).
+It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service users](./authenticate-service-accounts).

 ## Create a Service User with a PAT

@@ -7,7 +7,7 @@ This guide explains how developers can use private key JWT authentication to sec

 In ZITADEL, the `urn:ietf:params:oauth:grant-type:jwt-bearer` (**"JWT bearer token with private key"**, [RFC7523](https://tools.ietf.org/html/rfc7523)) authorization grant type is used for non-interactive authentication.

-Read more about the [different authentication methods for service users](./authenticate-service-users), including their benefits, drawbacks, and security considerations.
+Read more about the [different authentication methods for service users](./authenticate-service-accounts), including their benefits, drawbacks, and security considerations.

 #### How private key JWT authentication works

@@ -27,7 +27,7 @@ If you have an API that behaves as an OAuth resource server that can be accessed

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

 ## Further references

@@ -7,7 +7,7 @@ import IntrospectionResponse from './_introspection-response.mdx';

 This guide explains how to use ZITADEL's [Private Key JWT authentication method](/apis/openidoauth/authn-methods#jwt-with-private-key) to authenticate your application and call the token introspection endpoint. This is not about securing an API, but about allowing your backend to introspect access tokens in a secure way.

-If you're looking to set up Private Key JWT authentication specifically for Service Users, see our dedicated guide [here](/guides/integrate/service-users/private-key-jwt).
+If you're looking to set up Private Key JWT authentication specifically for Service Users, see our dedicated guide [here](/guides/integrate/service-accounts/private-key-jwt).

 ## Register an Application & Generate a Key Pair

@@ -27,9 +27,9 @@ For further details and in-depth exploration, you can refer to the [ZITADEL API

 Accessing ZITADEL APIs, except for the Auth API and the System API, requires these basic steps:

-1. **Create a service user**: A service user is a special type of account used to grant programmatic access to ZITADEL's functionalities. Unlike regular users who log in with a username and password, [service users rely on a more secure mechanism involving digital keys and tokens](../service-users/authenticate-service-users).
+1. **Create a service user**: A service user is a special type of account used to grant programmatic access to ZITADEL's functionalities. Unlike regular users who log in with a username and password, [service users rely on a more secure mechanism involving digital keys and tokens](../service-accounts/authenticate-service-accounts).
 2. **Give permission to access ZITADEL APIs**: Assign a Administrator role to the service user, giving it permission to make changes to certain resources in ZITADEL.
-3. **Authenticate the service user**: Like human users, service users must authenticate and request an OAuth token with the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to access ZITADEL APIs. [Service users can be authenticated](../service-users/authenticate-service-users) using private key JWT, client credentials, or personal access tokens.
+3. **Authenticate the service account**: Like users, service accounts must authenticate and request an OAuth token with the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to access ZITADEL APIs. [Service accounts can be authenticated](../service-accounts/authenticate-service-accounts) using private key JWT, client credentials, or personal access tokens.
 4. **Access ZITADEL APIs with the token**: The OAuth token must be included in the Authorization Header of calls to ZITADEL APIs.

 ### Accessing Auth API
@@ -84,7 +84,7 @@ To be able to access the ZITADEL APIs your service user needs permissions to ZIT
 ## 3. Authenticate service user and request token

 Service users can be authenticated using private key JWT, client credentials, or personal access tokens.
-The [service user authentication](../service-users/authenticate-service-users) can be used to make machine-to-machine requests to any Resource Server (eg, a backend service / API) by requesting a token from the Authorization Server (ZITADEL) and sending the short-lived token (access token) in the Header of requests.
+The [service user authentication](../service-accounts/authenticate-service-accounts) can be used to make machine-to-machine requests to any Resource Server (eg, a backend service / API) by requesting a token from the Authorization Server (ZITADEL) and sending the short-lived token (access token) in the Header of requests.

 This guide covers a specific case of service user authentication when requesting access to the [ZITADEL APIs](/apis/introduction).
 While PAT can be used directly to access the ZITADEL APIS, the more secure authentication methods private key JWT and client credentials must include the [reserved scope](/apis/openidoauth/scopes) `urn:zitadel:iam:org:project:id:zitadel:aud` when requesting an access from the token endpoint.
@@ -95,7 +95,7 @@ The following sections will explain the more specific authentication to access t

 ### Authenticate with private key JWT

-Follow the steps in this guide to [generate an key file](../service-users/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-users/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).
+Follow the steps in this guide to [generate an key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-accounts/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).

 With the encoded JWT (assertion) from the prior step, you will need to craft a POST request to ZITADEL's token endpoint.

@@ -232,4 +232,4 @@ curl --request GET \
 - [Example application in Go](./example-zitadel-api-with-go) to access ZITADEL APIs
 - [Example application in .NET](./example-zitadel-api-with-dot-net) to access ZITADEL APIs
 - Learn how to use the [Event API](./event-api) to retrieve your audit trail
- Read about the [different methods to authenticate service users](../service-users/authenticate-service-users)
+- Read about the [different methods to authenticate service users](../service-accounts/authenticate-service-accounts)
@@ -18,7 +18,7 @@ All that is required, is a service account with an Org Owner (or another role, d
 However, we recommend you read the guide on [how to access ZITADEL API](/guides/integrate/zitadel-apis/access-zitadel-apis) and the associated guides for a basic knowledge of :

 - [Recommended Authorization Flows](/guides/integrate/login/oidc/oauth-recommended-flows)
- - [Service Users](/guides/integrate/service-users/authenticate-service-users)
+ - [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts)

 > Be sure to have a valid key JSON and that its service account is either ORG_OWNER or at least ORG_OWNER_VIEWER before you continue with this guide.

@@ -21,7 +21,7 @@ All that is required, is a service account with an Org Owner (or another role, d

 However, we recommend you read the guide on [how to access ZITADEL API](/guides/integrate/zitadel-apis/access-zitadel-apis)) and the associated guides for a basic knowledge of :
 - [Recommended Authorization Flows](/guides/integrate/login/oidc/oauth-recommended-flows)
- - [Service Users](/guides/integrate/service-users/authenticate-service-users)
+ - [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts)

 > Be sure to have a valid key JSON and that its service account is either ORG_OWNER or at least ORG_OWNER_VIEWER before you continue with this guide.

@@ -24,7 +24,7 @@ In this case please enable the Feature Flag "Use V2 Api in Management Console fo
    <Tab value="human_deprecated" label="Human User [deprecated]">
        <img src="/docs/img/guides/console/addhuman.png" width="680px" alt="Add Human" />

-        After a human user is created, by default, an initialization mail with a code is sent to the registered email. This code then has to be verified on first login.
+        After a user is created, by default, an initialization mail with a code is sent to the registered email. This code then has to be verified on first login.
        If you want to omit this mail, you can check the **email verified** and **set initial password** toggle.
        If no password is set initially, the initialization mail prompting the user to set his password is sent.

@@ -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 human and service users. 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 configuration.

 ### Login Name Formats
 By default, if the setting **User Loginname must contain orgdomain** is **disabled**, usernames are unique across the entire instance.
@@ -8,22 +8,22 @@ import CreateUser from './_create-user.mdx';

 ## Overview

-ZITADEL supports authentication and authorization for different user types. We mainly differentiate between **Human Users** (interactive) and **Service Users** (machine-to-machine).
+ZITADEL supports authentication and authorization for different user types. We mainly differentiate between **users** (interactive) and **Service Accounts** (machine-to-machine).

 <img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />

 ## Types of Users

-### Human Users
-Human users represent actual people who log in via an interactive interface (e.g., a login page).
+### Users (Human)
+Users represent actual people who log in via an interactive interface (e.g., a login page).
 * **Profile:** Has an email address, password, and optional profile data (phone, nickname, gender, language).
 * **Authentication:** Can authenticate via password, multiple factors (MFA), or passwordless authentication (Passkeys).
 * **Flow:** The application redirects the user to ZITADEL, which handles the credentials and issues a token to the application.

 Read more on how to [login users with ZITADEL](/guides/integrate/login/login-users).

-### Service Users (Machine Accounts)
-Service users represent machines, backend services, or IoT devices requiring non-interactive access.
+### Service Accounts
+Service accounts represent machines, backend services, or IoT devices requiring non-interactive access.
 * **Profile:** Only has a name, description, and username.
 * **Authentication:** Authenticates via **JWT Profile** or **Personal Access Tokens (PAT)**. Both methods support expiration settings.
 * **Usage:** Primarily used to gain access to the ZITADEL Management API or to secure backend-to-backend communication.
@@ -40,7 +40,7 @@ In a multi-tenancy architecture, users are typically isolated within [Organizati
 However, using [External User Grants](../../../concepts/features/external-user-grant), an organization can invite users from *another* organization to access their projects. These invited users are referred to as **External Users** within the context of the inviting organization.

 ### Managers
-Any user—whether Human or Service User—can be assigned an [Administrator Role](/concepts/structure/managers).
+Any user—whether User or Service Account—can be assigned an [Administrator Role](/concepts/structure/managers).
 A user with an administrator role is not just an end-user of your application but also has permissions to manage specific aspects of the ZITADEL instance, organization, or project (e.g., `ORG_OWNER`, `PROJECT_OWNER`).

 ## Considerations
@@ -12,14 +12,14 @@ ZITADEL differs two different types of users:

 <img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />

-A human user has an email address and a password, and can additionally save information about phone, nickname, gender, language.
-A service user only has a name and a description aside his username.
+A user has an email address and a password, and can additionally save information about phone, nickname, gender, language.
+A service account only has a name and a description aside his username.

-A service user can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry.
-A human user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication.
+A service account can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry.
+A user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication.

-Service users are primarily used to gain access for a backend service or iot device. The fact that service users can also be ZITADEL managers is used to restrict access to specific projects or organizations.
-To get an understanding on how service users are used, take a look at our NextJS B2B Demo application.
+Service users are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL managers is used to restrict access to specific projects or organizations.
+To get an understanding on how service accounts are used, take a look at our NextJS B2B Demo application.

 ## Create User

@@ -221,7 +221,7 @@ Learn everything about how to build your own registration UI [here](/guides/inte
 The previous methods allowed you to retrieve metadata only for the `sub` in the access token.
 In case you want to get the metadata for another user, you need to use the management service.
 The user that calls the management service must have [manager permissions](/guides/manage/console/managers).
-A user can be either a human user or a service user.
+A user can be either a User (Human) or a Service Account.

 You can get [metadata of a user filtered by your query](/apis/resources/mgmt/management-service-list-user-metadata) or [get a metadata object from a user by a specific key](/apis/resources/mgmt/management-service-get-user-metadata).
 The management service allows you to set and delete metadata, see the [API documentation for users](/reference/api/user).
@@ -14,7 +14,7 @@ It can be used to create, update, and delete ZITADEL resources, as well as to ma
 Make sure you create the following resources in ZITADEL and have [Terraform installed](https://learn.hashicorp.com/tutorials/terraform/install-cli):

 - [A ZITADEL Instance](../start/quickstart)
- [A service user](/guides/integrate/service-users/authenticate-service-users) with [enough authorization](/guides/manage/console/managers) to manage the desired resources
+- [A service user](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/managers) to manage the desired resources

 ## Manage ZITADEL resources through terraform

@@ -25,7 +25,7 @@ To provide a small guide to where to start:
 1. Create a folder where all the terraform files reside.
 2. Configure the provider to use the right domain, port and token, with for example a `main.tf`file [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs).
 3. Add a `zitadel_org` resource to the `main.tf` file, to create and manage a new organization in the instance, [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/org).
-4. Add any resources to the organization in the `main.tf` file, [as example a human user](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/human_user).
+4. Add any resources to the organization in the `main.tf` file, [as an example a user](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/human_user).
 5. (Optional) Use Terraform in the directory with the command `terraform plan`, to see which resources would be created and how.
 6. Apply the changes and start managing your resources with terraform with `terraform apply`.
 7. (Optional) Delete your created resources with `terraform destroy` to clean-up.
@@ -122,12 +122,12 @@ To call the ZITADEL Admin API, you need to authenticate using a **Service User**
 There are two recommended authentication methods:

 - **Client Credentials Flow**
-  [Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-users/client-credentials)
+  [Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-accounts/client-credentials)

 - **Personal Access Token (PAT)**
-  [Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#personal-access-token)
+  [Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#personal-access-token)

-**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#authentication-methods)
+**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)

 ### 5.2. Import Data with the ZITADEL API

@@ -105,18 +105,18 @@ To call the ZITADEL Management API, you need to authenticate using a **Service U
 There are two recommended authentication methods:

 * **Client Credentials Flow**
-  [Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-users/client-credentials)
+  [Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-accounts/client-credentials)

 * **Personal Access Token (PAT)**
-  [Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-users/personal-access-token)
+  [Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-accounts/personal-access-token)

-**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#authentication-methods)
+**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)

 ---

 ### 5.2. Import Data with the ZITADEL API

-Use your **access token** or **PAT** to authenticate, then call the [Management API – Human User Import](/reference/api/management/zitadel.management.v1.ManagementService.ImportHumanUser) endpoint.
+Use your **access token** or **PAT** to authenticate, then call the [Management API – User Import](/reference/api/management/zitadel.management.v1.ManagementService.ImportHumanUser) endpoint.

 **Import Endpoint:**

@@ -36,7 +36,7 @@ You need a PAT from a service user with IAM Owner permissions in both the source

 1. Go to your default organization
 2. Create a service user "import_user" with Access Token Type "Bearer"
-3. Create a [personal access token](/guides/integrate/service-users/personal-access-token)
+3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
 4. Go to the Default settings
 5. Add the import_user as [manager](/guides/manage/console/managers) with the role "IAM Owner"

@@ -46,7 +46,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai

 1. Go to your default organization
 2. Create a service user "export_user" with Access Token Type "Bearer"
-3. Create a [personal access token](/guides/integrate/service-users/personal-access-token)
+3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
 4. Go to the Default settings
 5. Add the export_user as [manager](/guides/manage/console/managers) with the role "IAM Owner"

@@ -53,7 +53,7 @@ First, you need a user with manager permissions to change the project settings i
 This means either you add the manager to the organization or you use a manager on the instance level with "IAM-OWNER" permissions.
 After that create a Personal Access Token (PAT) for the manager.

-More detailed information about creating a PAT and administrator roles you can find [here](/guides/integrate/service-users/personal-access-token)
+More detailed information about creating a PAT and administrator roles you can find [here](/guides/integrate/service-accounts/personal-access-token)

 Then you have to send the following request:
 ```bash
@@ -407,7 +407,7 @@ You’ve successfully integrated ZITADEL into an application.
 <Callout type="warn" title="Prevent Misconfiguration Lockouts">
  Login policy misconfigurations that occur during the testing phase can easily lead to a [lockout](/legal/policies/account-lockout-policy). To ensure you don't lose access to your instance:

-  1.  **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-users/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/managers) role to revert any login UI misconfigurations using the API.
+  1.  **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/managers) role to revert any login UI misconfigurations using the API.
  2.  **Add a second Instance Manager:** Always designate at least one [**second instance manager**](/guides/manage/console/managers).
  
 </Callout>
@@ -27,6 +27,6 @@ This strategic versioning will ensure a more consistent and intuitive developmen
        This SDK provides a convenient client for interacting with the ZITADEL APIs, simplifying how you manage resources within your instance.

        Currently, the client is tailored for machine-to-machine communication, enabling machine users to authenticate and manage ZITADEL resources programmatically.
-        Please note that this initial version is focused on API calls for automated tasks and does not yet include support for human user authentication flows like OAuth or OIDC.
+        Please note that this initial version is focused on API calls for automated tasks and does not yet include support for user authentication flows like OAuth or OIDC.
    </details>
 </details>
@@ -162,7 +162,7 @@ class Demo {

 Choose the authentication method that best suits your needs based on your
 environment and security requirements. For more details, please refer to the
-[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Versioning

@@ -193,7 +193,7 @@ try {

 Choose the authentication method that best suits your needs based on your
 environment and security requirements. For more details, please refer to the
-[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Versioning

@@ -178,7 +178,7 @@ try {

 Choose the authentication method that best suits your needs based on your
 environment and security requirements. For more details, please refer to the
-[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Versioning

@@ -182,7 +182,7 @@ except ApiError as e:

 Choose the authentication method that best suits your needs based on your
 environment and security requirements. For more details, please refer to the
-[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Versioning

@@ -172,7 +172,7 @@ end

 Choose the authentication method that best suits your needs based on your
 environment and security requirements. For more details, please refer to the
-[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
+[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Debugging

@@ -95,7 +95,7 @@ The following table describes the milestones that are sent to the endpoints:
 | Trigger                                                                           | Description                                                                                                                                        |
 |-----------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|
 | A virtual instance is created.                                                    | This data point is also sent when the first instance is automatically created during the ZITADEL binaries setup phase in a self-hosting scenario.  |
-| An authentication succeeded for the first time on an instance.                    | This is the first authentication with the instances automatically created admin user during the instance setup, which can be a human or a machine. |
+| An authentication succeeded for the first time on an instance.                    | This is the first authentication with the instances automatically created admin user during the instance setup, which can be a user or a service account. |
 | A project is created for the first time in a virtual instance.                    | The ZITADEL project that is automatically created during the instance setup is omitted.                                                            |
 | An application is created for the first time in a virtual instance.               | The applications in the ZITADEL project that are automatically created during the instance setup are omitted.                                      |
 | An authentication succeeded for the first time in a virtual instances application. | This is the first authentication using a ZITADEL application that is not created during the instance setup phase.                                  |
@@ -185,10 +185,10 @@ export const guidesSidebar: readonly SidebarItem[] = [
            type: "category",
            label: "Machine-to-Machine (M2M)",
            items: [
-              "guides/integrate/service-users/authenticate-service-users",
-              "guides/integrate/service-users/private-key-jwt",
-              "guides/integrate/service-users/client-credentials",
-              "guides/integrate/service-users/personal-access-token",
+              "guides/integrate/service-accounts/authenticate-service-accounts",
+              "guides/integrate/service-accounts/private-key-jwt",
+              "guides/integrate/service-accounts/client-credentials",
+              "guides/integrate/service-accounts/personal-access-token",
            ],
          },
        ],
@@ -8,8 +8,8 @@ package domain

 // // CreateUserCommand adds a new user including the email verification for humans.
 // // In the future it might make sense to separate the command into two commands:
-// // - CreateHumanCommand: creates a new human user
-// // - CreateMachineCommand: creates a new machine user
+// // - CreateHumanCommand: creates a new User (Human)
+// // - CreateMachineCommand: creates a new service account
 // type CreateUserCommand struct {
 // 	user  *User
 // 	email *SetEmailCommand
@@ -83,8 +83,8 @@ type userColumns interface {
 //go:generate mockgen -typed -package domainmock -destination ./mock/human_user.mock.go . HumanUserRepository

 type HumanUserRepository interface {
-	// Update updates the human user
-	// It ensures that updates are only applied to human users
+	// Update updates the user
+	// It ensures that updates are only applied to user
 	Update(ctx context.Context, client database.QueryExecutor, condition database.Condition, changes ...database.Change) (int64, error)
 	humanConditions
 	humanChanges
@@ -691,7 +691,7 @@ SCIM:
    - Name: Zitadel authentication token
      Description: Authentication scheme using the OAuth Bearer Token Standard
      SpecUri: https://www.rfc-editor.org/info/rfc6750
-      DocumentationUri: https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users
+      DocumentationUri: https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts
      Type: oauthbearertoken
  # default values whether an email/phone is considered verified when a users email/phone is created or updated
  EmailVerified: true # ZITADEL_SCIM_EMAILVERIFIED
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "المستخدمون",
-      "DESCRIPTION": "المستخدم هو إنسان أو آلة يمكنها الوصول إلى تطبيقاتك.",
+      "DESCRIPTION": "المستخدم هو إنسان أو حساب خدمة يمكنه الوصول إلى تطبيقاتك.",
      "HUMANS": {
        "TITLE": "المستخدمون",
        "DESCRIPTION": "يقوم المستخدمون بالمصادقة بشكل تفاعلي في جلسة المتصفح مع مطالبة تسجيل الدخول.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "потребители",
-      "DESCRIPTION": "Потребител е човек или машина, която може да достъпва вашите приложения.",
+      "DESCRIPTION": "Потребител е човек или сметка за услуга, която може да достъпва вашите приложения.",
      "HUMANS": {
        "TITLE": "потребители",
        "DESCRIPTION": "Хората се удостоверяват интерактивно в сесия на браузъра с искане за вход.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Uživatelé",
-      "DESCRIPTION": "Uživatel je člověk nebo stroj, který může přistupovat k vašim aplikacím.",
+      "DESCRIPTION": "Uživatel je člověk nebo účet služby, který může přistupovat k vašim aplikacím.",
      "HUMANS": {
        "TITLE": "Uživatelé",
        "DESCRIPTION": "Uživatelé se autentizují interaktivně v prohlížečové relaci s výzvou k přihlášení.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Benutzer",
-      "DESCRIPTION": "Ein Benutzer ist ein Mensch oder ein Computer, der auf deine Anwendungen zugreifen kann.",
+      "DESCRIPTION": "Ein Benutzer ist ein Mensch oder ein Servicekonto, das auf deine Anwendungen zugreifen kann.",
      "HUMANS": {
        "TITLE": "Benutzer",
        "DESCRIPTION": "Benutzer authentifizieren sich interaktiv in einer Browsersitzung mit einem Login-Formular.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Users",
-      "DESCRIPTION": "A user is a human or a machine that can access your applications.",
+      "DESCRIPTION": "A user is a human or a service account that can access your applications.",
      "HUMANS": {
        "TITLE": "Users",
        "DESCRIPTION": "Users authenticate interactively in a browser session with a login prompt.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Usuarios",
-      "DESCRIPTION": "Un usuario es un humano o una máquina que puede acceder a tus aplicaciones.",
+      "DESCRIPTION": "Un usuario es un humano o una cuenta de servicio que puede acceder a tus aplicaciones.",
      "HUMANS": {
        "TITLE": "Usuarios",
        "DESCRIPTION": "Los Usuarios se autentican de manera interactiva en una sesión de navegador con una solicitud de inicio de sesión.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Utilisateurs",
-      "DESCRIPTION": "Un utilisateur est un humain ou une machine qui peut accéder à vos applications.",
+      "DESCRIPTION": "Un utilisateur est un humain ou compte de service qui peut accéder à vos applications.",
      "HUMANS": {
        "TITLE": "Utilisateurs",
        "DESCRIPTION": "Les utilisateurs s'authentifient de manière interactive dans une session de navigateur avec une invite de connexion.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Felhasználók",
-      "DESCRIPTION": "A felhasználó lehet ember vagy gép, amely hozzáfér az alkalmazásaidhoz.",
+      "DESCRIPTION": "A felhasználó lehet ember vagy szolgáltatásfiók, amely hozzáfér az alkalmazásaidhoz.",
      "HUMANS": {
        "TITLE": "Felhasználók",
        "DESCRIPTION": "A felhasználók interaktívan hitelesítik magukat egy böngésző munkamenetben egy bejelentkezési felhívással.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Pengguna",
-      "DESCRIPTION": "Pengguna adalah manusia atau mesin yang dapat mengakses aplikasi Anda.",
+      "DESCRIPTION": "Pengguna adalah manusia atau akun layanan yang dapat mengakses aplikasi Anda.",
      "HUMANS": {
        "TITLE": "Pengguna",
        "DESCRIPTION": "Pengguna mengautentikasi secara interaktif dalam sesi browser dengan perintah login.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Utenti",
-      "DESCRIPTION": "Un utente è un essere umano o una macchina che può accedere alle tue applicazioni.",
+      "DESCRIPTION": "Un utente è un essere umano o account di servizio che può accedere alle tue applicazioni.",
      "HUMANS": {
        "TITLE": "Utenti",
        "DESCRIPTION": "Gli utenti si autenticano interattivamente in una sessione del browser con un prompt di login.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "ユーザー",
-      "DESCRIPTION": "ユーザーは、あなたのアプリケーションにアクセスできる人間または機械です。",
+      "DESCRIPTION": "ユーザーは、あなたのアプリケーションにアクセスできる人間またはサービスアカウントです。",
      "HUMANS": {
        "TITLE": "ユーザー",
        "DESCRIPTION": "ユーザーは、ログイン プロンプトを使用してブラウザ セッションで対話的に認証を行います。",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "사용자",
-      "DESCRIPTION": "사용자는 애플리케이션에 액세스할 수 있는 사람 또는 장치입니다.",
+      "DESCRIPTION": "사용자는 애플리케이션에 액세스할 수 있는 사람 또는 서비스 계정입니다.",
      "HUMANS": {
        "TITLE": "사용자",
        "DESCRIPTION": "사용자는 로그인 프롬프트로 브라우저 세션에서 상호 인증을 수행합니다.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Корисници",
-      "DESCRIPTION": "Корисник е човек или машина кој може да пристапи до твоите апликации.",
+      "DESCRIPTION": "Корисник е човек или сметка за услуга кој може да пристапи до твоите апликации.",
      "HUMANS": {
        "TITLE": "Корисници",
        "DESCRIPTION": "Корисниците интерактивно се автентицираат во сесија на прелистувач со барање за најава.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Gebruikers",
-      "DESCRIPTION": "Een gebruiker is een mens of een machine die toegang kan krijgen tot je applicaties.",
+      "DESCRIPTION": "Een gebruiker is een mens of een serviceaccount die toegang kan krijgen tot je applicaties.",
      "HUMANS": {
        "TITLE": "Gebruikers",
        "DESCRIPTION": "Gebruikers authenticeren interactief in een browsersessie met een loginprompt.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Użytkownicy",
-      "DESCRIPTION": "Użytkownik to człowiek lub maszyna, która może uzyskać dostęp do twoich aplikacji.",
+      "DESCRIPTION": "Użytkownik to człowiek lub konto usługi, które może uzyskać dostęp do twoich aplikacji.",
      "HUMANS": {
        "TITLE": "Użytkownicy",
        "DESCRIPTION": "Użytkownicy uwierzytelniają się interaktywnie w sesji przeglądarki z monitem logowania.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Usuários",
-      "DESCRIPTION": "Um usuário é um humano ou uma máquina que pode acessar seus aplicativos.",
+      "DESCRIPTION": "Um usuário é um humano ou uma conta de serviço que pode acessar seus aplicativos.",
      "HUMANS": {
        "TITLE": "Usuários",
        "DESCRIPTION": "Os usuários são autenticados interativamente em uma sessão do navegador com um prompt de login.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Utilizatori",
-      "DESCRIPTION": "Un utilizator este o persoană sau o mașină care vă poate accesa aplicațiile.",
+      "DESCRIPTION": "Un utilizator este o persoană sau un cont de serviciu care vă poate accesa aplicațiile.",
      "HUMANS": {
        "TITLE": "Utilizatori",
        "DESCRIPTION": "Utilizatorii se autentifică interactiv într-o sesiune de browser cu o solicitare de autentificare.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Пользователи",
-      "DESCRIPTION": "Пользователь - это человек или машина, которая может получить доступ к вашим приложениям.",
+      "DESCRIPTION": "Пользователь - это человек или учетная запись службы, которая может получить доступ к вашим приложениям.",
      "HUMANS": {
        "TITLE": "Пользователи",
        "DESCRIPTION": "Пользователи проходят аутентификацию в интерактивном режиме в сеансе браузера с помощью приглашения на вход.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Användare",
-      "DESCRIPTION": "En användare är en människa eller en maskin som kan få åtkomst till dina applikationer.",
+      "DESCRIPTION": "En användare är en människa eller ett tjänstkonto som kan få åtkomst till dina applikationer.",
      "HUMANS": {
        "TITLE": "Användare",
        "DESCRIPTION": "Användare autentiserar interaktivt i en webbläsarsession med en inloggningsprompt.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Kullanıcılar",
-      "DESCRIPTION": "Kullanıcı, uygulamalarınıza erişebilen bir insan veya makinedir.",
+      "DESCRIPTION": "Kullanıcı, uygulamalarınıza erişebilen bir insan veya hizmet hesabıdır.",
      "HUMANS": {
        "TITLE": "Kullanıcılar",
        "DESCRIPTION": "Kullanıcılar, giriş istemiyle bir tarayıcı oturumunda etkileşimli olarak kimlik doğrulaması yapar.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "Користувачі",
-      "DESCRIPTION": "Користувач - це людина або машина, яка може отримати доступ до ваших додатків.",
+      "DESCRIPTION": "Користувач - це людина або обліковий запис служби, який може отримати доступ до ваших додатків.",
      "HUMANS": {
        "TITLE": "Користувачі",
        "DESCRIPTION": "Користувачі автентифікуються інтерактивно в сеансі браузера за допомогою запиту входу.",
@@ -46,7 +46,7 @@
    },
    "USERS": {
      "TITLE": "用户",
-      "DESCRIPTION": "用户是可以访问你的应用的人或机器。",
+      "DESCRIPTION": "用户是可以访问你的应用的人或服务账户。",
      "HUMANS": {
        "TITLE": "用户",
        "DESCRIPTION": "用户在浏览器会话中通过登录提示进行交互身份验证。",
@@ -157,7 +157,7 @@ func AddInstancePbToSetupInstance(req *system_pb.AddInstanceRequest, defaultInst
 	}

 	if defaultInstance.Org.Human != nil {
-		// used to not overwrite the default human later
+		// used to not overwrite the default User (human) later
 		humanCopy := *defaultInstance.Org.Human
 		instance.Org.Human = &humanCopy
 	} else {
@@ -446,7 +446,7 @@ func TestServer_ListUsers(t *testing.T) {
 					},
 				}
 			}(),
-			want: &user.ListUsersResponse{ // human user should return itself when calling ListUsers() even if it has no permissions
+			want: &user.ListUsersResponse{ // User (Human) should return itself when calling ListUsers() even if it has no permissions
 				Details: &object.ListDetails{
 					TotalResult: 1,
 					Timestamp:   timestamppb.Now(),
@@ -441,7 +441,7 @@ func TestServer_ListUsers(t *testing.T) {
 					},
 				}
 			}(),
-			want: &user_v2beta.ListUsersResponse{ // human user should return itself when calling ListUsers() even if it has no permissions
+			want: &user_v2beta.ListUsersResponse{ // User (Human) should return itself when calling ListUsers() even if it has no permissions
 				Details: &object_v2beta.ListDetails{
 					TotalResult: 1,
 					Timestamp:   timestamppb.Now(),
@@ -185,7 +185,7 @@ func userInfoToOIDC(user *query.OIDCUserInfo, userInfoAssertion bool, scope []st
 			if !userInfoAssertion {
 				continue
 			}
-			// TODO: handle address for human users as soon as implemented
+			// TODO: handle address for Users (Humans) as soon as implemented
 		case ScopeUserMetaData:
 			setUserInfoMetadata(user.Metadata, out)
 		case ScopeResourceOwner:
@@ -33,7 +33,7 @@
      "name": "Zitadel authentication token",
      "description": "Authentication scheme using the OAuth Bearer Token Standard",
      "specUri": "https://www.rfc-editor.org/info/rfc6750",
-      "documentationUri": "https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users",
+      "documentationUri": "https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts",
      "type": "oauthbearertoken",
      "primary": false
    }
@@ -69,7 +69,7 @@ func (h *UsersHandler) buildListQuery(ctx context.Context, request *ListRequest)
 		SearchRequest: searchRequest,
 	}

-	// the zitadel scim implementation only supports humans for now
+	// the zitadel scim implementation only supports User (Humans) for now
 	userTypeQuery, err := query.NewUserTypeSearchQuery(domain.UserTypeHuman)
 	if err != nil {
 		return nil, err
@@ -362,7 +362,7 @@ func (repo *AuthRequestRepo) SelectUser(ctx context.Context, authReqID, userID,
 }

 func (repo *AuthRequestRepo) selectUser(ctx context.Context, request *domain.AuthRequest, userID string) error {
-	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, repo.LockoutPolicyViewProvider, userID, false)
+	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, userID, false)
 	if err != nil {
 		return err
 	}
@@ -669,7 +669,7 @@ func (repo *AuthRequestRepo) getAuthRequestEnsureUser(ctx context.Context, authR
 	if request.UserID != userID {
 		return nil, zerrors.ThrowPreconditionFailed(nil, "EVENT-GBH32", "Errors.User.NotMatchingUserID")
 	}
-	_, err = activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, repo.LockoutPolicyViewProvider, request.UserID, false)
+	_, err = activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, request.UserID, false)
 	if err != nil {
 		return request, err
 	}
@@ -820,7 +820,7 @@ func (repo *AuthRequestRepo) checkLoginName(ctx context.Context, request *domain
 	if err != nil && !zerrors.IsNotFound(err) {
 		return err
 	}
-	// if there's an active (human) user, let's use it
+	// if there's an active User (Human), let's use it
 	if user != nil && !user.HumanView.IsZero() && domain.UserState(user.State).IsEnabled() {
 		request.SetUserInfo(user.ID, loginNameInput, preferredLoginName, "", "", user.ResourceOwner)
 		return nil
@@ -1054,7 +1054,7 @@ func (repo *AuthRequestRepo) checkExternalUserLogin(ctx context.Context, request
 	if len(links.Links) != 1 {
 		return zerrors.ThrowNotFound(nil, "AUTH-Sf8sd", "Errors.ExternalIDP.NotFound")
 	}
-	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, repo.LockoutPolicyViewProvider, links.Links[0].UserID, false)
+	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, links.Links[0].UserID, false)
 	if err != nil {
 		return err
 	}
@@ -1084,7 +1084,7 @@ func (repo *AuthRequestRepo) nextSteps(ctx context.Context, request *domain.Auth
 			return steps, err
 		}
 	}
-	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, repo.LockoutPolicyViewProvider, request.UserID, request.LoginPolicy.IgnoreUnknownUsernames)
+	user, err := activeUserByID(ctx, repo.UserViewProvider, repo.UserEventProvider, repo.OrgViewProvider, request.UserID, request.LoginPolicy.IgnoreUnknownUsernames)
 	if err != nil {
 		return nil, err
 	}
@@ -1166,7 +1166,7 @@ func (repo *AuthRequestRepo) nextSteps(ctx context.Context, request *domain.Auth
 		return steps, nil
 	}

-	if request.LinkingUsers != nil && len(request.LinkingUsers) != 0 {
+	if len(request.LinkingUsers) != 0 {
 		return append(steps, &domain.LinkUsersStep{}), nil
 	}
 	//PLANNED: consent step
@@ -1223,7 +1223,7 @@ func (repo *AuthRequestRepo) nextStepsUser(ctx context.Context, request *domain.
 	defer func() { span.EndWithError(err) }()

 	steps := make([]domain.NextStep, 0)
-	if request.LinkingUsers != nil && len(request.LinkingUsers) > 0 {
+	if len(request.LinkingUsers) > 0 {
 		steps = append(steps, new(domain.ExternalNotFoundOptionStep))
 		return steps, nil
 	}
@@ -1739,8 +1739,7 @@ func userSessionByIDs(ctx context.Context, provider userSessionViewProvider, eve
 	return user_view_model.UserSessionToModel(&sessionCopy), nil
 }

-func activeUserByID(ctx context.Context, userViewProvider userViewProvider, userEventProvider userEventProvider, queries orgViewProvider, lockoutPolicyProvider lockoutPolicyViewProvider, userID string, ignoreUnknownUsernames bool) (user *user_model.UserView, err error) {
-	// PLANNED: Check LockoutPolicy
+func activeUserByID(ctx context.Context, userViewProvider userViewProvider, userEventProvider userEventProvider, queries orgViewProvider, userID string, ignoreUnknownUsernames bool) (user *user_model.UserView, err error) {
 	user, err = userByID(ctx, userViewProvider, userEventProvider, userID)
 	if err != nil {
 		if ignoreUnknownUsernames && zerrors.IsNotFound(err) {
@@ -1611,7 +1611,7 @@ func TestCommandSide_SetUpOrg(t *testing.T) {
 			name: "human added with initial mail",
 			fields: fields{
 				eventstore: expectEventstore(
-					expectFilter(), // add human exists check
+					expectFilter(), // add User (Human) exists check
 					expectFilter(),
 					expectFilter(
 						eventFromEventPusher(
@@ -409,7 +409,7 @@ func (wm *UserV2WriteModel) SetPasswordCodeSent(e *user.HumanPasswordCodeSentEve

 func (wm *UserV2WriteModel) Query() *eventstore.SearchQueryBuilder {
 	// remove events are always processed
-	// and username is based for machine and human
+	// and username is based for service account and user (human)
 	eventTypes := []eventstore.EventType{
 		user.UserRemovedType,
 		user.UserUserNameChangedType,
@@ -17,7 +17,7 @@ var _ eventstore.Event = (*Event)(nil)

 // Event represents all information about a manipulation of an aggregate
 type Event struct {
-	//ID is a generated uuid for this event
+	// ID is a generated uuid for this event
 	ID string

 	// Seq is the sequence of the event
@@ -25,7 +25,7 @@ type Event struct {
 	// Pos is the global sequence of the event multiple events can have the same sequence
 	Pos decimal.Decimal

-	//CreationDate is the time the event is created
+	// CreationDate is the time the event is created
 	// it's used for human readability.
 	// Don't use it for event ordering,
 	// time drifts in different services could cause integrity problems
@@ -35,29 +35,29 @@ type Event struct {
 	// it should always be in past-form
 	Typ eventstore.EventType

-	//Data describe the changed fields (e.g. userName = "hodor")
+	// Data describe the changed fields (e.g. userName = "hodor")
 	// data must always a pointer to a struct, a struct or a byte array containing json bytes
 	Data []byte

-	//EditorUser should be a unique identifier for the user which created the event
+	// EditorUser should be a unique identifier for the user which created the event
 	// it's meant for maintainability.
 	// It's recommend to use the aggregate id of the user
 	EditorUser string

-	//Version describes the definition of the aggregate at a certain point in time
+	// Version describes the definition of the aggregate at a certain point in time
 	// it's used in read models to reduce the events in the correct definition
 	Version eventstore.Version
-	//AggregateID id is the unique identifier of the aggregate
+	// AggregateID id is the unique identifier of the aggregate
 	// the client must generate it by it's own
 	AggregateID string
-	//AggregateType describes the meaning of the aggregate for this event
+	// AggregateType describes the meaning of the aggregate for this event
 	// it could an object like user
 	AggregateType eventstore.AggregateType
-	//ResourceOwner is the organisation which owns this aggregate
+	// ResourceOwner is the organisation which owns this aggregate
 	// an aggregate can only be managed by one organisation
 	// use the ID of the org
 	ResourceOwner sql.NullString
-	//InstanceID is the instance where this event belongs to
+	// InstanceID is the instance where this event belongs to
 	// use the ID of the instance
 	InstanceID string

@@ -92,7 +92,7 @@ type Instance struct {
 	Instance    *instance.InstanceDetail
 	DefaultOrg  *org.Org
 	Users       UserMap
-	AdminUserID string // First human user for password login
+	AdminUserID string // First User (Human) for password login

 	Client   *Client
 	WebAuthN *webauthn.Client
@@ -225,7 +225,7 @@ var (
 		"username",
 		"login_names",
 		"preferred_login_name",
-		// human
+		// User (human)
 		"user_id",
 		"first_name",
 		"last_name",
@@ -234,7 +234,7 @@ var (
 		"preferred_language",
 		"gender",
 		"avatar_key",
-		// machine
+		// service account
 		"user_id",
 		"last_email",
 		"verified_email",
@@ -293,7 +293,7 @@ var (
 		"username",
 		"login_names",
 		"preferred_login_name",
-		// human
+		// User (human)
 		"user_id",
 		"first_name",
 		"last_name",
@@ -309,7 +309,7 @@ var (
 		"password_change_required",
 		"password_changed",
 		"mfa_init_skipped",
-		// machine
+		// service account
 		"user_id",
 		"name",
 		"description",
@@ -717,7 +717,7 @@ func Test_UserPrepares(t *testing.T) {
 						"username",
 						database.TextArray[string]{"login_name1", "login_name2"},
 						"login_name1",
-						// human
+						// User (human)
 						"id",
 						"first_name",
 						"last_name",
@@ -780,7 +780,7 @@ func Test_UserPrepares(t *testing.T) {
 						"username",
 						database.TextArray[string]{"login_name1", "login_name2"},
 						"login_name1",
-						// human
+						// User (human)
 						"id",
 						"first_name",
 						"last_name",
@@ -867,7 +867,7 @@ func Test_UserPrepares(t *testing.T) {
 							"username",
 							database.TextArray[string]{"login_name1", "login_name2"},
 							"login_name1",
-							// human
+							// User (human)
 							"id",
 							"first_name",
 							"last_name",
@@ -883,7 +883,7 @@ func Test_UserPrepares(t *testing.T) {
 							true,
 							testNow,
 							testNow,
-							// machine
+							// service account
 							nil,
 							nil,
 							nil,
@@ -952,7 +952,7 @@ func Test_UserPrepares(t *testing.T) {
 							"username",
 							database.TextArray[string]{"login_name1", "login_name2"},
 							"login_name1",
-							// human
+							// User (human)
 							"id",
 							"first_name",
 							"last_name",
@@ -968,7 +968,7 @@ func Test_UserPrepares(t *testing.T) {
 							true,
 							testNow,
 							testNow,
-							// machine
+							// service account
 							nil,
 							nil,
 							nil,
@@ -1042,7 +1042,7 @@ func Test_UserPrepares(t *testing.T) {
 							"username",
 							database.TextArray[string]{"login_name1", "login_name2"},
 							"login_name1",
-							// human
+							// User (human)
 							"id",
 							"first_name",
 							"last_name",
@@ -1058,7 +1058,7 @@ func Test_UserPrepares(t *testing.T) {
 							true,
 							testNow,
 							testNow,
-							// machine
+							// service account
 							nil,
 							nil,
 							nil,
@@ -1077,7 +1077,7 @@ func Test_UserPrepares(t *testing.T) {
 							"username",
 							database.TextArray[string]{"login_name1", "login_name2"},
 							"login_name1",
-							// human
+							// User (human)
 							nil,
 							nil,
 							nil,
@@ -1093,7 +1093,7 @@ func Test_UserPrepares(t *testing.T) {
 							nil,
 							nil,
 							nil,
-							// machine
+							// service account
 							"id",
 							"name",
 							"description",
@@ -284,7 +284,7 @@ service ManagementService {
    //
    // Deprecated: use [user service v2 ListUsers with InUserIDQuery](apis/resources/user_service_v2/user-service-list-users.api.mdx) instead.
    //
-    // Returns the full user object (human or machine) including the profile, email, etc.
+    // Returns the full user or Service Account including the profile, email, etc.
    rpc GetUserByID(GetUserByIDRequest) returns (GetUserByIDResponse) {
        option (google.api.http) = {
            get: "/users/{id}"
@@ -444,7 +444,7 @@ service ManagementService {
    //
    // Deprecated: use [user service v2 CreateUser](apis/resources/user_service_v2/user-service-create-user.api.mdx) instead.
    //
-    // Create a new user with the type human. The newly created user will get an initialization email if either the email address is not marked as verified or no password is set. If a password is set the user will not be requested to set a new one on the first login.
+    // Create a new user. The newly created user will get an initialization email if either the email address is not marked as verified or no password is set. If a password is set the user will not be requested to set a new one on the first login.
    rpc AddHumanUser(AddHumanUserRequest) returns (AddHumanUserResponse) {
        option (google.api.http) = {
            post: "/users/human"
@@ -473,7 +473,7 @@ service ManagementService {
    //
    // Deprecated: use [user service v2 UpdateHumanUser](apis/resources/user_service_v2/user-service-update-human-user.api.mdx) instead.
    //
-    // Create/import a new user with the type human. The newly created user will get an initialization email if either the email address is not marked as verified or no password is set. If a password is set the user will not be requested to set a new one on the first login.
+    // Create/import a new user. The newly created user will get an initialization email if either the email address is not marked as verified or no password is set. If a password is set the user will not be requested to set a new one on the first login.
    rpc ImportHumanUser(ImportHumanUserRequest) returns (ImportHumanUserResponse) {
        option (google.api.http) = {
            post: "/users/human/_import"
@@ -129,7 +129,7 @@ service UserService {

  // Create a User
  //
-  // Create a new human or machine user in the specified organization.
+  // Create a new user or service account in the specified organization.
  //
  // Required permission:
  //   - user.write
@@ -168,11 +168,11 @@ service UserService {
    };
  }

-  // Create a new human user
+  // Create a new User (Human)
  //
-  // Deprecated: Use [CreateUser](/docs/reference/api/user/zitadel.user.v2.UserService.CreateUser) to create a new user of type human instead.
+  // Deprecated: Use [CreateUser](/docs/reference/api/user/zitadel.user.v2.UserService.CreateUser) to create a new user.
  //
-  // Create/import a new user with the type human. The newly created user will get a verification email if either the email address is not marked as verified and you did not request the verification to be returned.
+  // Create/import a new user. The newly created user will get a verification email if either the email address is not marked as verified and you did not request the verification to be returned.
  rpc AddHumanUser (AddHumanUserRequest) returns (AddHumanUserResponse) {
    option (google.api.http) = {
      post: "/v2/users/human"
@@ -202,7 +202,7 @@ service UserService {

  // User by ID
  //
-  // Returns the full user object (human or machine) including the profile, email, etc..
+  // Returns the full user or Service Account including the profile, email, etc..
  rpc GetUserByID(GetUserByIDRequest) returns (GetUserByIDResponse) {
    option (google.api.http) = {
      get: "/v2/users/{user_id}"
@@ -574,9 +574,9 @@ service UserService {
    };
  }

-  // Update Human User
+  // Update User (Human)
  //
-  // Deprecated: Use [UpdateUser](/docs/reference/api/user/zitadel.user.v2.UserService.UpdateUser) to update a user of type human instead.
+  // Deprecated: Use [UpdateUser](/docs/reference/api/user/zitadel.user.v2.UserService.UpdateUser) to update a user.
  //
  // Update all information from a user.
  rpc UpdateHumanUser(UpdateHumanUserRequest) returns (UpdateHumanUserResponse) {
@@ -2138,7 +2138,7 @@ message CreateUserRequest{
  ];

  // The username is a unique identifier for the user in the organization.
-  // If not specified, Zitadel sets the username to the email for users of type human and to the user_id for users of type machine.
+  // If not specified, Zitadel sets the username to the email for user and to the user_id for Service Accounts.
  // It is used to identify the user in the organization and can be used for login.
  optional string username = 3 [
    (validate.rules).string = {min_len: 1, max_len: 200},
@@ -111,9 +111,9 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
 // Deprecated: use user service v2 instead. This service will be removed in the next major version of ZITADEL.
 service UserService {

-  // Create a new human user
+  // Create a new User (Human)
  //
-  // Create/import a new user with the type human. The newly created user will get a verification email if either the email address is not marked as verified and you did not request the verification to be returned.
+  // Create/import a new user. The newly created user will get a verification email if either the email address is not marked as verified and you did not request the verification to be returned.
  //
  // Deprecated: please move to the corresponding endpoint under user service v2 (GA)
  rpc AddHumanUser (AddHumanUserRequest) returns (AddHumanUserResponse) {
@@ -145,7 +145,7 @@ service UserService {

  // User by ID
  //
-  // Returns the full user object (human or machine) including the profile, email, etc.
+  // Returns the full user or Service Account including the profile, email, etc.
  //
  // Deprecated: please move to the corresponding endpoint under user service v2 (GA).
  rpc GetUserByID(GetUserByIDRequest) returns (GetUserByIDResponse) {