chore: Service Account Naming Consistency (#11557)

# Which Problems Are Solved Inconsistent naming of service account, found in the following variations: - Machine User - machine user - Service User - Machine Account - Technical Account - User: Type Machine # How the Problems Are Solved Attentive search and replace. Localizations have been translated using Copilot # Additional Changes Some unused methods have been removed from the Go code. # Additional Context - Closes #11285
2026-11-01 20:02:15 +00:00 · 2026-02-13 12:31:43 +01:00
parent 9f3d7e7bc3
commit 382aec2d61
136 changed files with 493 additions and 507 deletions
@@ -25,10 +25,10 @@ Additionally, you can use the [session API](/reference/api/session) to authentic

 ### Authenticate service accounts

-Service users allow for machine-to-machine (M2M) communication.
+Service accounts allow for machine-to-machine (M2M) communication.
 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.
+Accessing the ZITADEL APIs through a service account 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.

 ### OpenID Connect & OAuth

@@ -98,7 +98,7 @@ 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 User (Human) or machine users.
+  - 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 service accounts.
  - 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.
@@ -270,7 +270,7 @@ curl --request POST \
 | ------------ | ------------------------------------------------------------------------------------- |
 | access_token | An `access_token` as JWT or opaque token                                              |
 | expires_in   | Number of second until the expiration of the `access_token`                           |
-| id_token     | An `id_token` of the authorized service user                                          |
+| id_token     | An `id_token` of the authorized service account                                          |
 | scope        | Scopes of the `access_token`. These might differ from the provided `scope` parameter. |
 | token_type   | Type of the `access_token`. Value is always `Bearer`                                  |

@@ -44,9 +44,9 @@ For a list of supported or unsupported `Grant Types` please have a look at the t

 ### Using JWTs as Authorization Grants

-Our service user work with the JWT profile to authenticate them against ZITADEL.
+Our service account works with the JWT profile to authenticate them against ZITADEL.

-1. Create or use an existing service user
+1. Create or use an existing service account
 2. Create a new key and download it
 3. Generate a JWT with the structure below and sign it with the downloaded key
 4. Send the JWT Base64 encoded to ZITADEL's token endpoint
@@ -61,7 +61,7 @@ Key JSON
 | type   | `"serviceaccount"`                                                  | The type of account, right now only serviceaccount is valid        |
 | keyId  | `"81693565968772648"`                                               | This is unique ID of the key                                       |
 | key    | `"-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----"` | The private key generated by ZITADEL, this can not be regenerated! |
-| userId | `78366401571647008`                                                 | The service users ID, this is the same as the subject from tokens  |
+| userId | `78366401571647008`                                                 | The service accounts ID, this is the same as the subject from tokens  |

 ```json
 {
@@ -82,7 +82,7 @@ JWT
 | exp   | `1605183582`                 | Unix timestamp of the expiry                                                                                  |
 | iat   | `1605179982`                 | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h                             |
 | iss   | `"77479219772321307"`        | String which represents the requesting party (owner of the key), normally the `userId` from the json key file |
-| sub   | `"77479219772321307"`        | The subject ID of the service user, normally the `userId` from the json key file                              |
+| sub   | `"77479219772321307"`        | The subject ID of the service account, normally the `userId` from the json key file                              |

 ```json
 {
@@ -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-accounts/authenticate-service-accounts).
+For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Accounts Guide](/guides/integrate/service-accounts/authenticate-service-accounts).

 ## Query

@@ -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-accounts/authenticate-service-accounts) account, allowing you to integrate the events with your own business logic.
+Access to the API is possible with a [Service Account](/guides/integrate/service-accounts/authenticate-service-accounts), allowing you to integrate the events with your own business logic.

 ## Using logs in external systems

@@ -67,8 +67,8 @@ 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-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).
+Service acounts 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 Accounts](/guides/integrate/service-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).

 ## Logout

@@ -136,7 +136,7 @@ Thus, we will explain service for two of the most common scenarios in ZITADEL:
 - `Administrators in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other

 A list of [Administrator Roles](../../guides/manage/console/administrators#roles) is available with a description of permissions.
-Administrators can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
+Administrators can be assigned to both human users and service accounts, e.g., for managing certain tasks programmatically.

 ### Administrators in isolation

@@ -7,7 +7,7 @@ sidebar_label: Users

 ZITADEL supports authentication and authorization for different user types.
 We can mainly differentiate between Users and Service Accounts.
-We typically call human users simply "Users" and machine users "Service Users".
+Users are accounts operated/used by a human, while service accounts are those operated/used by an application/third-party software.

 ### Users

@@ -17,10 +17,10 @@ ZITADEL handles the authentication and provides the application with a token tha

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

-### Service users
+### Service accounts

-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.
+Service accounts 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 Account to access the Management API.
 The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via a login prompt, but service accounts require a non-interactive logon process.

 Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.
@@ -0,0 +1,42 @@
+1. Go to the **Users** tab in your organization as shown below and click on the **Service Accounts** tab.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/1.png)
+
+2. To add a service account, click on the **New** button.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/2.png)
+
+3. Next, add the details of the service account and select either **Bearer** or **JWT** for **Access Token Type** and click on **Create**. For this example, we will select **JWT**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/3.png)
+
+4. Now you will see the saved details.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/4.png)
+
+5. Next,  we need to generate a private-public key pair in ZITADEL and you must get the private key to sign your JWT.  Go to **Keys** and click on **New**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/5.png)
+
+6. Select type **JSON** and click **Add**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/6.png)
+
+7. Download the key by clicking **Download**. After the download, click **Close**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/7.png)
+
+8. You will see the following screen afterward.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/8.png)
+
+9. The downloaded key will be of the following format:
+
+```
+{
+    "type":"serviceaccount",
+    "keyId":"<YOUR_KEY_ID>",
+    "key":"-----BEGIN RSA PRIVATE KEY-----\n<YOUR_KEY>\n-----END RSA PRIVATE KEY-----\n",
+    "userId":"<YOUR_USER_ID>"
+}
+```
@@ -0,0 +1,36 @@
+In order to access this route, you must create the role `read:messages` in your ZITADEL project and also create an authorization for the service account you created by adding the role to the user. Follow these steps to do so:
+
+1. Go to your project and select **Roles**. Click **New**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/1.png)
+
+2. Add the `read:messages` role as shown below and click **Save**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/2.png)
+
+3. You will see the created role listed.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/3.png)
+
+4. To assign this role to a user, click on **Authorizations**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/4.png)
+
+5. Select the user you want to assign the role to.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/5.png)
+
+6. Select the project where this authorization is applicable.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/6.png)
+7. Click **Continue**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/7.png)
+
+8. Select the role **read:messages** and click **Save**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/8.png)
+
+9. You will now see the service account has been assigned the role **read:messages**.
+
+![](../../../public/img/examples/secure-api/service-account-jwt/scopes/9.png)
@@ -1,42 +0,0 @@
-1. Go to the **Users** tab in your organization as shown below and click on the **Service Users** tab.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/1.png)
-
-2. To add a service user, click on the **New** button.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/2.png)
-
-3. Next, add the details of the service user and select either **Bearer** or **JWT** for **Access Token Type** and click on **Create**. For this example, we will select **JWT**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/3.png)
-
-4. Now you will see the saved details.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/4.png)
-
-5. Next,  we need to generate a private-public key pair in ZITADEL and you must get the private key to sign your JWT.  Go to **Keys** and click on **New**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/5.png)
-
-6. Select type **JSON** and click **Add**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/6.png)
-
-7. Download the key by clicking **Download**. After the download, click **Close**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/7.png)
-
-8. You will see the following screen afterward.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/8.png)
-
-9. The downloaded key will be of the following format:
-
-```
-{
-    "type":"serviceaccount",
-    "keyId":"<YOUR_KEY_ID>",
-    "key":"-----BEGIN RSA PRIVATE KEY-----\n<YOUR_KEY>\n-----END RSA PRIVATE KEY-----\n",
-    "userId":"<YOUR_USER_ID>"
-}
-```
@@ -1,36 +0,0 @@
-In order to access this route, you must create the role `read:messages` in your ZITADEL project and also create an authorization for the service user you created by adding the role to the user. Follow these steps to do so:
-
-1. Go to your project and select **Roles**. Click **New**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/1.png)
-
-2. Add the `read:messages` role as shown below and click **Save**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/2.png)
-
-3. You will see the created role listed.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/3.png)
-
-4. To assign this role to a user, click on **Authorizations**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/4.png)
-
-5. Select the user you want to assign the role to.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/5.png)
-
-6. Select the project where this authorization is applicable.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/6.png)
-7. Click **Continue**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/7.png)
-
-8. Select the role **read:messages** and click **Save**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/8.png)
-
-9. You will now see the service user has been assigned the role **read:messages**.
-
-![](../../../public/img/examples/secure-api/service-user-jwt/scopes/9.png)
@@ -59,20 +59,20 @@ To set up the needed roles for your project, navigate to your `Portal` project,
 Now in the `General` section of the Portal project, make sure to enable `Assert Roles on Authentication`.
 This makes sure that roles, which is used by the application to enable UI components, are set in your OIDC ID Token.

-### Service User
+### Service Account

-To make the application work you need a service user which loads granted-projects and user-grants for you.
-In the B2B-Demo organization, navigate to `Users` in navigation of Management Console, click on `Service Users` and create a new user.
+To make the application work you need a service account which loads granted-projects and user-grants for you.
+In the B2B-Demo organization, navigate to `Users` in navigation of Management Console, click on `Service Accounts` and create a new user.
 Let's set its username to `nextjs` and its name to `NextJS`. Then press `create`.

 On the detail page of that user, navigate to "Personal Access Tokens" and add a new entry, set an optional expiration date.

 Copy the generated Token as you will need this in your environment configuration file later.

-Go back to the `Portal` project and add the Service User as Manager (top right).
+Go back to the `Portal` project and add the Service Account as Manager (top right).
 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 User as `Org Project Permission Editor` Manager.
+To show granted projects, go to the `Demo-Vendor` organization and add the Service Account as `Org Project Permission Editor` Manager.

 ## Configuration

@@ -104,7 +104,7 @@ Replace the values as follows

 `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`.

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

 ## Install and Run

@@ -17,7 +17,7 @@ At the end of the guide you should have an API with a protected endpoint.
 ## Prerequisites

 This will handle the OAuth 2.0 introspection request including authentication using JWT with Private Key using our [Go SDK](https://github.com/zitadel/zitadel-go).
-All that is required, is to create your API, create a private key and a personal access token for a service user.
+All that is required, is to create your API, create a private key and a personal access token for a service account.

 ### Set up application and obtain keys

@@ -54,15 +54,15 @@ And make sure to download it, as you won't be able to retrieve it again.

 Now we need to create a *Personal Access Token* to authenticate the application requests.

-On the user view, switch to *Service Users* and create a new one.
+On the user view, switch to *Service Accounts* and create a new one.

 ![](../../../public/img/go/api-service_user_panel.png)

-Give the service user a name and a username. Select `Bearer` as *Access Token Type*.
+Give the service account a name and a username. Select `Bearer` as *Access Token Type*.

 ![](../../../public/img/go/api-create_service_user.png)

-### Create service user and personal access token (PAT)
+### Create service account and personal access token (PAT)

 Once done, from the left panel of the user management, click on Personal Access Token and create a new one.

@@ -4,8 +4,8 @@ sidebar_label: Pylon
 ---

 import AppJWT from "../imports/_app_jwt.mdx";
-import ServiceuserJWT from "../imports/_serviceuser_jwt.mdx";
-import ServiceuserRole from "../imports/_serviceuser_role.mdx";
+import ServiceAccountJWT from "../imports/_serviceaccount_jwt.mdx";
+import ServiceAccountRole from "../imports/_serviceaccount_role.mdx";

 This integration guide demonstrates the recommended way to incorporate ZITADEL into your [Pylon](https://pylon.cronit.io) service.
 It explains how to check the token validity in the API and how to check for permissions.
@@ -20,13 +20,13 @@ Before we can start building our application, we have to do a few configuration

 <AppJWT components={props.components}  />

-### Create Serviceuser
+### Create Service Account

-<ServiceuserJWT components={props.components}  />
+<ServiceAccountJWT components={props.components}  />

-### Give Serviceuser an authorization
+### Give Service Account an authorization

-<ServiceuserRole components={props.components}  />
+<ServiceAccountRole components={props.components}  />

 ### Prerequisites

@@ -36,9 +36,9 @@ At the end you should have the following for the API:
 - `.json`-key-file for the API, from the application
 - ID of the project

-And the following from the Serviceuser:
+And the following from the Service Account:

- `.json`-key-file from the serviceuser
+- `.json`-key-file from the service account

 ## Setup new Pylon service

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

 Optionally set the token as an environment variable:
@@ -4,8 +4,8 @@ sidebar_label: Django
 ---

 import AppJWT from '../imports/_app_jwt.mdx';
-import ServiceuserJWT from '../imports/_serviceuser_jwt.mdx';
-import ServiceuserRole from '../imports/_serviceuser_role.mdx';
+import ServiceAccountJWT from '../imports/_serviceaccount_jwt.mdx';
+import ServiceAccountRole from '../imports/_serviceaccount_role.mdx';
 import SetupPython from '../imports/_setup_python.mdx';

 This integration guide demonstrates the recommended way to incorporate ZITADEL into your Django Python application.
@@ -25,13 +25,13 @@ Before we can start building our application, we have to do a few configuration

 <AppJWT components={props.components} />

-### Create Serviceuser
+### Create Service Account

-<ServiceuserJWT components={props.components} />
+<ServiceAccountJWT components={props.components} />

-### Give Serviceuser an authorization
+### Give Service Account an authorization

-<ServiceuserRole components={props.components} />
+<ServiceAccountRole components={props.components} />

 ### Prerequisites

@@ -42,8 +42,8 @@ At the end you should have the following for the API:
 - `.json`-key-file for the API, from the application
 - ID of the project

-And the following from the Serviceuser:
- `.json`-key-file from the serviceuser
+And the following from the Service Account:
+- `.json`-key-file from the service account

 ## Setup new Django application

@@ -182,13 +182,13 @@ CLIENT_ID = "197....@projectname"
 CLIENT_SECRET = "NVAp70IqiGmJldbS...."
 ```

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

 ![](../../../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-accounts/personal-access-token#create-a-service-user-with-a-pat).
+1. Create a service account and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-account-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.
+3. Next, create an authorization for the service account 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.

 ### Run the API

@@ -222,7 +222,7 @@ curl --request GET \

 You should get a response with Status Code 401 and an error message.

-Now let's add an authorization header to your request. Save the personal access token for your service user to a variable by running the following command. Replace the value with the PAT you obtained earlier.
+Now let's add an authorization header to your request. Save the personal access token for your service account to a variable by running the following command. Replace the value with the PAT you obtained earlier.

 `PAT=nr9vnUTkQkn4rxWk...`

@@ -252,4 +252,4 @@ You should get a response with Status Code 200 and the following message.

 `{"message":"Private, scoped route - You need to be authenticated and have the role read:messages to see this."}`

-You can remove the role from the service user in ZITADEL and try again. You should then get a Status Code 403, Forbidden error.
+You can remove the role from the service account in ZITADEL and try again. You should then get a Status Code 403, Forbidden error.
@@ -23,7 +23,7 @@ Its set of features will increase with time and its progress will be tracked [he
 The new Login app consists of a confidential (backend) part and a browser (client side) part.
 In addition to that, the OIDC specification builds upon a proxy which is set up in the Next.js middleware. It rewrites requests of the paths `/.well-known/:path*`, `/oauth/:path*`, `/oidc/:path*` to ZITADEL.

-The backend side of the application is authorized using a machine user's personal access token.
+The backend side of the application is authorized using a service account's personal access token.
 This token is used to fetch policies and settings from your instances or organization which define how users are authenticated and how the Login app is displayed.

 The frontend side of the application communicates to the backend side by using a cookie which is set by the server.
@@ -137,7 +137,7 @@ You can review an example implementation of a middleware [here](https://github.c
  <img src="https://vercel.com/button" alt="Deploy with Vercel" style={{pointerEvents: "none", display: "block"}}/>
 </a>

-To deploy your own version on Vercel, navigate to your instance and create a service user.
+To deploy your own version on Vercel, navigate to your instance and create a service account.
 Create a personal access token (PAT) for the user and copy and set it as `ZITADEL_SERVICE_USER_TOKEN`, then navigate to Default settings and make sure it gets `IAM_LOGIN_CLIENT` permissions.
 Finally set your instance url as `ZITADEL_API_URL`. Make sure to set it without trailing slash.
 Also ensure your login domain is registered on your instance by adding it as a [Trusted Domain](/apis/resources/admin/admin-service-add-instance-trusted-domain).
@@ -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 user with a personal access token (PAT) and the IAM_OWNER role.
+    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.
 </Callout>
@@ -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-accounts/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
+        1. [Create a service account](/guides/integrate/service-accounts/personal-access-token#create-a-service-account-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 Administrator Guide](/guides/manage/console/administrators)
        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)
@@ -215,7 +215,7 @@ https://github.com/zitadel/actions/blob/main/examples/custom_roles.js
 Now we will use the auth API to retrieve roles from a logged in user using the user’s token
 The base URL is: **https://`${CUSTOM_DOMAIN}`/auth/v1**

-Let’s start with a user who has multiple roles in different organizations in a multi-tenanted set up. You can use the logged in user’s token or the machine user’s token to retrieve the authorizations using the [APIs listed under user authorizations/grants in the auth API](/reference/api/authorization).
+Let’s start with a user who has multiple roles in different organizations in a multi-tenanted set up. You can use the logged in user’s token or the service account’s token to retrieve the authorizations using the [APIs listed under user authorizations/grants in the auth API](/reference/api/authorization).

 **Scope used:** `openid urn:zitadel:iam:org:project:id:zitadel:aud`

@@ -14,15 +14,15 @@ This guide provides step-by-step instructions to configure SCIM provisioning fro

 ## Step 1: Set Up SCIM Provisioning in ZITADEL

-SCIM provisioning in ZITADEL is accomplished by authenticating a Service User with appropriate permissions.
+SCIM provisioning in ZITADEL is accomplished by authenticating a Service Account with appropriate permissions.

-1. **Create a Service User**:
+1. **Create a Service Account**:

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

 2. **Assign the Role**:

-   * Grant the Service User the **Org User Manager** role. No higher managerial role is required.
+   * Grant the Service Account the **Org User Manager** role. No higher managerial role is required.

 3. **Choose an Authentication Method**:

@@ -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-accounts/authenticate-service-accounts).
+4. Detailed instructions to authenticate the Service Account can be found [here](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ## Step 2: Set Up SCIM in Okta

@@ -110,9 +110,9 @@ Review and adjust attribute mappings in Okta as needed:

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

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

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

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

@@ -5,53 +5,53 @@ sidebar_label: Authenticate service accounts

 import DocCardList from '@/components/docusaurus/doc-card-list';

-This guide explains ZITADEL service users and their role in facilitating secure machine-to-machine communication within your applications.
+This guide explains ZITADEL service accounts and their role in facilitating secure machine-to-machine communication within your applications.

-## What are Service Users?
+## What are Service Accounts?

-Service users in ZITADEL represent **non-human entities** within your system.
+Service accounts 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 [Administrator](/concepts/structure/administrators) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
+Service accounts in combination with [Administrator](/concepts/structure/administrators) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
 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
+## Benefits of using Service Accounts

 ### Enhanced security

-* **Principle of Least Privilege:** Grant service users only the minimum permissions they need, minimizing potential damage in case of compromise.
-* **Distinct Credentials:** Avoid embedding sensitive credentials like API keys directly in code. Service user credentials can be rotated independently.
+* **Principle of Least Privilege:** Grant service accounts only the minimum permissions they need, minimizing potential damage in case of compromise.
+* **Distinct Credentials:** Avoid embedding sensitive credentials like API keys directly in code. Service account credentials can be rotated independently.

 ### Segregated authorization

-Manage authorization for service users separately from human users, providing an extra layer of control.
+Manage authorization for service accounts separately from human users, providing an extra layer of control.

 ### API and backend access

-Service users offer a secure way to authenticate and access various API endpoints and protected backend services.
+Service accounts offer a secure way to authenticate and access various API endpoints and protected backend services.

-You can [use service users to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis), follow the guides to learn how to access the different ZITADEL APIs.
+You can [use service accounts to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis), follow the guides to learn how to access the different ZITADEL APIs.
 While you can define the scopes and required information in your requests for your applications API endpoints, when using the ZITADEL APIs, you must include the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to gain access.

 ### Improved auditability

-Actions performed by service users are clearly identifiable in logs, facilitating easier auditing and tracing.
+Actions performed by service accounts are clearly identifiable in logs, facilitating easier auditing and tracing.

 Using the [Event API](../zitadel-apis/event-api) you can use these logs for further analysis or to integrate the logs with [external SOC / SIEM](../external-audit-log) systems.

 ## Authentication methods

-ZITADEL supports two primary authentication methods for service users:
+ZITADEL supports two primary authentication methods for service accounts:

 ### Private key JWT authentication

 #### How private key JWT authentication works

-* Generate a private/public key pair associated with the service user.
+* Generate a private/public key pair associated with the service account.
 * Sign JWTs with the private key.
-* ZITADEL validates the signature using the service user's public key.
+* ZITADEL validates the signature using the service account's public key.
 * JWTs can include expiration dates and scopes to control access.

-Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service users and applications.
+Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service accounts and applications.

 #### Benefits of private key JWT authentication

@@ -71,22 +71,22 @@ Follow our guide on using [private key JWT client authentication](./private-key-

 ### Client credentials grant

-* Presents a client ID and client secret associated with the service user.
+* Presents a client ID and client secret associated with the service account.
 * Simpler than the JWT profile in specific scenarios.

-Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service users and applications.
+Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service accounts and applications.

 This method is still available in ZITADEL but is generally considered less secure than JWT due to:

 * **Centralized Validation:** Relies on the server to verify credentials for every request, potentially impacting performance and requiring more server resources.
-* **Credentials Exposure:** Leaked client ID and secret could be used by attackers to impersonate the service user until rotation occurs.
+* **Credentials Exposure:** Leaked client ID and secret could be used by attackers to impersonate the service account until rotation occurs.

 ### 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.
+* **Ready-to-use tokens:** Generated for specific service accounts and can be directly included in the authorization header of API requests.
 * **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.
+Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service accounts and applications.

 PAT offer some benefits, such as:

@@ -98,15 +98,15 @@ However, PATs also come with limitations:
 * **Revocation:** Requires deleting the PAT directly, potentially causing downtime if not managed carefully.
 * **Leakage:** PATs are long-lived tokens that can be readily used in API calls, if leaked the attacker can access all resources until the PAT is expired or deleted. Private key JWT and client credentials create a short-lived access token instead.

-## Using Service Users
+## Using Service Accounts

-1. **Creation:** Access the ZITADEL management console and create a new service user. Assign a descriptive name that reflects its purpose. Follow our detailed guide on [how to create service users](../../manage/console/users).
+1. **Creation:** Access the ZITADEL management console and create a new service account. Assign a descriptive name that reflects its purpose. Follow our detailed guide on [how to create service accounts](../../manage/console/users).
 2. **Credentials:** Choose your preferred authentication method (JWT or Client Credentials) and securely store the generated credentials (private key, client secret).
 3. **Making API Calls:** When your service needs to make an API call:
    * **For JWT:** Generate and sign a JWT. Include it in the "Authorization" header of your API request.
    * **For Client Credentials:** Include the client ID and client secret in your API request.
    * **For PATs:** Include the PAT directly in the "Authorization" header of your API request.
-4. ZITADEL Verifies the credentials and authorizes the service user to perform the requested action based on its granted permissions.
+4. ZITADEL Verifies the credentials and authorizes the service account to perform the requested action based on its granted permissions.

 We have guides for the different authentication methods:

@@ -116,19 +116,19 @@ We have guides for the different authentication methods:

 ## Important considerations

-* **Secure Credentials:** Treat service user credentials (private keys, client secrets) with utmost care. Store them securely, similar to any other sensitive information like API keys or passwords.
+* **Secure Credentials:** Treat service account credentials (private keys, client secrets) with utmost care. Store them securely, similar to any other sensitive information like API keys or passwords.
 * **Expiry Management:** Set appropriate expiration dates for JWTs and regularly rotate all credentials to maintain strong security practices.
-* **Permission Granting:** Adhere to the principle of least privilege by granting only the specific permissions required for a service user's function.
+* **Permission Granting:** Adhere to the principle of least privilege by granting only the specific permissions required for a service account's function.

 ## Choosing the right authentication method

-For most service user scenarios in ZITADEL, [private key JWT authentication](./private-key-jwt) is the recommended choice due to its benefits in security, performance, and control.
+For most service account scenarios in ZITADEL, [private key JWT authentication](./private-key-jwt) is the recommended choice due to its benefits in security, performance, and control.
 However, [client credentials authentication](./client-credentials) might be considered in specific situations where simplicity and trust between servers are priorities.

 ## Further resources

-* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
-* [Service User API reference](/reference/api/user)
+* Read about the [different methods to authenticate service accounts](./authenticate-service-accounts)
+* [Service Account 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)
 * Validate access tokens with [token introspection with private key jwt](../token-introspection/private-key-jwt.mdx)
@@ -1,17 +1,17 @@
 ---
-title: Configure client credential authentication for service users
+title: Configure client credential authentication for service accounts
 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-accounts) and client applications within ZITADEL.
+This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service accounts](/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-accounts) as alternative to the [JWT profile authentication](./authenticate-service-accounts).

-## Steps to authenticate a Service User with client credentials
+## Steps to authenticate a Service Account with client credentials

-### 1. Create a Service User with a client secret
+### 1. Create a Service Account with a client secret

-1. Navigate to Service Users
+1. Navigate to Service Accounts
 2. Click on **New**
 3. Enter a username and a display name
 4. Click on **Create**
@@ -23,11 +23,11 @@ Make sure to copy in particular the ClientSecret. You won't be able to retrieve
 If you lose it, you will have to generate a new one.
 </Callout>

-![](../../../../public/img/console_serviceusers_secret.gif)
+![](../../../../public/img/console_serviceaccounts_secret.gif)

-### 2. Authenticating a service user and request a token
+### 2. Authenticating a service account and request a token

-In this step, we will authenticate a service user and receive an access_token to use against the ZITADEL API.
+In this step, we will authenticate a service account and receive an access_token to use against the ZITADEL API.

 You will need to craft a POST request to ZITADEL's token endpoint:

@@ -48,7 +48,7 @@ curl --request POST \
 If you want to access ZITADEL APIs, make sure to include the required scopes `urn:zitadel:iam:org:project:id:zitadel:aud`.
 Read our guide [how to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis) to learn more.

-**Important Note:** If the service user token needs to be validated using token introspection, ensure you include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request.
+**Important Note:** If the service account token needs to be validated using token introspection, ensure you include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request.
 Without this, token introspection will fail.

 You should receive a successful response with `access_token`,  `token_type` and time to expiry in seconds as `expires_in`.
@@ -64,15 +64,15 @@ Content-Type: application/json
 }
 ```

-Per default a service user will get an opaque access token.
-If you want to get a Jason Web Token (JWT) as an access token for your user, you can change the token type in the general settings of your service account.
+Per default a service account will get an opaque access token.
+If you want to get a JSON Web Token (JWT) as an access token for your user, you can change the token type in the general settings of your service account.
 To learn more about opaque and JWT tokens read our [Opaque Tokens in ZITADEL: Enhancing Application Security](/concepts/knowledge/opaque-tokens) Guide

-![](../../../../public/img/console_service_user_tokentype.png)
+![](../../../../public/img/console_service_account_tokentype.png)

 ### 3. Include the access token in the authorization header

-When making API requests on behalf of the service user, include the generated token in the "Authorization" header with the "Bearer" prefix.
+When making API requests on behalf of the service account, include the generated token in the "Authorization" header with the "Bearer" prefix.

 ```bash
 curl --request POST \
@@ -84,7 +84,7 @@ curl --request POST \
 ## Accessing ZITADEL APIs

 You might want to access ZITADEL APIs to manage resources, such as users, or to validate tokens sent to your backend service.
-Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service user using client credentials.
+Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service account using client credentials.

 ### Token introspection

@@ -97,12 +97,12 @@ Follow our [guide on token introspection with client credentials](../token-intro
 * **Store private keys securely:** **Never share or embed the private key in your code or application.** Consider using secure key management solutions.
 * **Set appropriate expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise.

-By following these steps and adhering to security best practices, you can effectively secure service user and client application communication within ZITADEL using client credential authentication.
+By following these steps and adhering to security best practices, you can effectively secure service account and client application communication within ZITADEL using client credential authentication.

 ## Notes

-* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
-* [Service User API reference](/reference/api/user)
+* Read about the [different methods to authenticate service accounts](./authenticate-service-accounts)
+* [Service Account 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)
 * Validate access tokens with [token introspection with basic auth](../token-introspection/basic-auth)
@@ -1,16 +1,16 @@
 ---
-title: Configure personal access token authentication for service users
+title: Configure personal access token authentication for service accounts
 sidebar_label: Personal access token authentication
 ---

 A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header.
-At the moment ZITADEL only allows PATs for machine accounts (service users).
+At the moment ZITADEL only allows PATs for service accounts.

-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).
+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 accounts](./authenticate-service-accounts).

-## Create a Service User with a PAT
+## Create a Service Account with a PAT

-1. Navigate to Service Users
+1. Navigate to Service Accounts
 2. Click on **New**
 3. Enter a username and a display name
 4. Click on the Personal Access Token menu point in the detail of your user
@@ -22,11 +22,11 @@ It is an alternative to the [private key JWT](./private-key-jwt) and [client cre

 ## Grant role for ZITADEL

-To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL.
+To be able to access the ZITADEL APIs, your service account needs permissions to ZITADEL.

 1. Go to the detail page of your organization
 2. Click in the top right corner the "+" button
-3. Search for your service user
+3. Search for your service account
 4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators))

 ![](../../../../public/img/guides/console-service-user-org-owner.gif)
@@ -34,7 +34,7 @@ To be able to access the ZITADEL APIs, your service user needs permissions to ZI
 ## Accessing ZITADEL APIs

 You might want to access ZITADEL APIs to manage resources, such as users, or to validate tokens sent to your backend service.
-Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service user.
+Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service account.

 ### Token introspection

@@ -45,7 +45,7 @@ Follow our [guide on token introspection with private key JWT](../token-introspe
 ## Call ZITADEL API with PAT

 Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API.
-In this example we read the organization of the service user.
+In this example we read the organization of the service account.

 ```bash
 curl --request GET \
@@ -55,7 +55,7 @@ curl --request GET \

 ## Client application authentication

-The above steps demonstrate service user authentication.
+The above steps demonstrate service account authentication.
 If your application also needs to authenticate itself, you can utilize [Client Credentials Grant](./client-credentials).
 Refer to ZITADEL documentation for details on this alternative method.

@@ -65,4 +65,4 @@ Refer to ZITADEL documentation for details on this alternative method.
 * **Set appropriate JWT expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise.
 * **Implement proper error handling:** Handle situations where JWT verification fails or tokens are expired.

-By following these steps and adhering to security best practices, you can effectively secure service user and client application communication within ZITADEL using private key JWT authentication.
+By following these steps and adhering to security best practices, you can effectively secure service account and client application communication within ZITADEL using private key JWT authentication.
@@ -1,23 +1,23 @@
 ---
-title: Configure private key JWT authentication for service users
+title: Configure private key JWT authentication for service accounts
 sidebar_label: Private key JWT authentication
 ---

-This guide explains how developers can use private key JWT authentication to secure communication between service users and client applications in ZITADEL.
+This guide explains how developers can use private key JWT authentication to secure communication between service accounts and client applications in ZITADEL.

 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-accounts), including their benefits, drawbacks, and security considerations.
+Read more about the [different authentication methods for service accounts](./authenticate-service-accounts), including their benefits, drawbacks, and security considerations.

 #### How private key JWT authentication works

-1. Generate a private/public key pair associated with the service user.
+1. Generate a private/public key pair associated with the service account.
 2. The authorization server stores the public key.
 3. The authorization server returns the private key as a JSON file.
 4. The developer configures the client application to use the private key.
-5. The client creates a JWT assertion with the subject set to the service user and signs the JWT with the private key.
+5. The client creates a JWT assertion with the subject set to the service account and signs the JWT with the private key.
 6. The client application requests a token from ZITADEL by sending the `client_assertion`.
-7. The authorization server validates the signature using the service user's public key.
+7. The authorization server validates the signature using the service account's public key.
 8. The authorization server returns an OAuth `access_token`.
 9. The client sends an API request, including the `access_token` in the Authorization header.
 10. The resource server validates the JWT with [token introspection](../token-introspection/).
@@ -28,32 +28,32 @@ Read more about the [different authentication methods for service users](./authe

 A code library or framework that supports JWT generation and verification (such as `pyjwt` for Python or `jsonwebtoken` for Node.js).

-## Steps to authenticate a Service User with private JWT
+## Steps to authenticate a Service Account with private JWT

-Follow these steps to authenticate a service user and obtain an access token for subsequent requests.
+Follow these steps to authenticate a service account and obtain an access token for subsequent requests.

-### 1. Create a Service User
+### 1. Create a Service Account

-1. Navigate to **Service Users**.
+1. Navigate to **Service Accounts**.
 2. Click on **New**.
 3. Enter a username and a display name.
 4. Click on **Create**.

-### 2. Register a private key for your service user
+### 2. Register a private key for your service account

 You can let ZITADEL generate a private key for you, **or** upload your own (externally generated) public key. Choose one of the following:

 #### Option A: Generate and download a private key from ZITADEL

-1. Open the ZITADEL web console and go to your service user.
+1. Open the ZITADEL web console and go to your service account.
 2. Click on the **Keys** tab.
 3. Click **New**.
 4. Optionally set an expiration date for the key, or leave empty for no expiration.
 5. Click **Download** and save the JSON key file securely.

-#### Option B: Register an existing public key for your service user
+#### Option B: Register an existing public key for your service account

-If you already have a key pair, you can upload the public key for your service user. For example, to generate a key pair using OpenSSL:
+If you already have a key pair, you can upload the public key for your service account. For example, to generate a key pair using OpenSSL:

 ```bash
 # generate key pair
@@ -73,7 +73,7 @@ If you generate a key in ZITADEL, make sure to download and securely store the k
 If you set an expiration date when generating a key in ZITADEL, that key will expire at midnight on the specified day.
 </Callout>

-![](../../../../public/img/console_serviceusers_new_key.gif)
+![](../../../../public/img/console_serviceaccounts_new_key.gif)

 If you let ZITADEL generate a key for you and download the JSON file, it will look similar to the example below. In this ZITADEL-generated key file, the `key` property contains the _private_ key for your service account. Store this JSON securely and never share your private key. ZITADEL automatically stores the public key component, so you do not need to upload it.

@@ -130,7 +130,7 @@ There are also [many libraries](https://jwt.io/#libraries-io) available for gene
 import jwt
 import datetime

-# Replace with your service user ID and private key
+# Replace with your service account ID and private key
 service_user_id = "your_service_user_id"
 private_key = "-----BEGIN PRIVATE KEY-----\nYOUR_PRIVATE_KEY\n-----END PRIVATE KEY-----"
 key_id = "your_key_id"
@@ -178,7 +178,7 @@ curl --request POST \
 If you want to access ZITADEL APIs, make sure to include the required scope `urn:zitadel:iam:org:project:id:zitadel:aud`.
 See our guide on [how to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis) for more details.

-**Important Note:** If the service user token must be validated using token introspection, you must include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request.
+**Important Note:** If the service account token must be validated using token introspection, you must include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request.
 If you do not include this, token introspection will fail.

 A successful response will include the `access_token`, `token_type`, and the time to expiry in seconds (`expires_in`):
@@ -196,7 +196,7 @@ Content-Type: application/json

 ### 5. Include the access token in the Authorization header

-When making API requests as the service user, include the generated token in the "Authorization" header with the "Bearer" prefix.
+When making API requests as the service account, include the generated token in the "Authorization" header with the "Bearer" prefix.

 ```bash
 curl --request POST \
@@ -208,7 +208,7 @@ curl --request POST \
 ## Accessing ZITADEL APIs

 You may use ZITADEL APIs to manage resources (e.g., users) or to validate tokens received by your backend service.
-Follow our guide on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) with your service user.
+Follow our guide on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) with your service account.

 ### Token introspection

@@ -218,7 +218,7 @@ See our [guide on token introspection with private key JWT](../token-introspecti

 ## Client application authentication

-The steps above describe service user authentication.
+The steps above describe service account authentication.
 If your application itself also needs authentication, you can use the [Client Credentials Grant](./client-credentials).
 See the ZITADEL documentation for additional details on this approach.

@@ -228,7 +228,7 @@ See the ZITADEL documentation for additional details on this approach.
 * **Set appropriate JWT expiration times:** Limit token validity to reduce risk in the event of a compromise.
 * **Implement proper error handling:** Handle cases where JWT verification fails or tokens are expired.

-By following these steps and adhering to best practices, you can securely manage service user and client application authentication within ZITADEL using private key JWTs.
+By following these steps and adhering to best practices, you can securely manage service account and client application authentication within ZITADEL using private key JWTs.

 ## Notes

@@ -23,16 +23,16 @@ If you have an API that behaves as an OAuth resource server that can be accessed
 - [JSON Web Token (JWT) Profile (Recommended)](/guides/integrate/token-introspection/private-key-jwt)
 - [Basic Authentication](/guides/integrate/token-introspection/basic-auth)

-## Service users
+## Service accounts

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

 ## Further references

 - [Introspection API reference](/apis/openidoauth/endpoints#token-endpoint)
 - [JWT vs. opaque tokens](/concepts/knowledge/opaque-tokens)
- [Python examples for securing an API and invoking it as a service user](https://github.com/zitadel/examples-api-access-and-token-introspection)
+- [Python examples for securing an API and invoking it as a service account](https://github.com/zitadel/examples-api-access-and-token-introspection)

 <DocCardList />
@@ -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-accounts/private-key-jwt).
+If you're looking to set up Private Key JWT authentication specifically for Service Accounts, see our dedicated guide [here](/guides/integrate/service-accounts/private-key-jwt).

 ## Register an Application & Generate a Key Pair

@@ -1,6 +1,6 @@
 ## Accessing ZITADEL APIs

-In this step, we will authenticate a service user and receive an access_token to use against the ZITADEL API.
+In this step, we will authenticate a service account and receive an access_token to use against the ZITADEL API.

 You will need to craft a POST request to ZITADEL's token endpoint:

@@ -32,7 +32,7 @@ Content-Type: application/json
 }
 ```

-In this step we will authenticate a service user and receive an access_token to use against the ZITADEL API.
+In this step we will authenticate a service account and receive an access_token to use against the ZITADEL API.

 You will need to craft a POST request to ZITADEL's token endpoint:

@@ -2,7 +2,7 @@
 title: Access ZITADEL APIs
 ---

-This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a service user to manage all types of resources and settings.
+This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a service account to manage all types of resources and settings.

 ## What are the ZITADEL APIs

@@ -27,15 +27,15 @@ 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-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.
+1. **Create a service account**: A service account 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 accounts 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 account, giving it permission to make changes to certain resources in ZITADEL.
 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

 The Auth API can be used for all operations on the requesting user, meaning the user id in the `sub` claim of the used token.
-Using this API doesn't require a service user to be authenticated.
+Using this API doesn't require a service account to be authenticated.
 Instead, you call the Auth API with the token of the user.

 [Reference documentation for authentication API](/apis/introduction#authentication)
@@ -43,24 +43,24 @@ 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 users 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 a special configuration 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)

-## 1. Create a service user
+## 1. Create a service account

-First, you need to create a new service user through the management console or ZITADEL APIs.
+First, you need to create a new service account through the management console or ZITADEL APIs.

 Via Management Console:

-1. In an organization, navigate to Users > Service Users
+1. In an organization, navigate to Users > Service Accounts
 2. Click on **New**
 3. Enter a username and a display name
 4. Click on **Create**

 Via APIs23: * [Create User (Machine)](/reference/api/management/zitadel.management.v1.ManagementService.AddMachineUser)

-## 2. Grant an Administrator Role to the Service User
+## 2. Grant an Administrator Role to the Service Account

 ZITADEL Administrators are users who have permission to manage ZITADEL itself.
 There are different levels of administrators.
@@ -72,21 +72,21 @@ There are different levels of administrators.

 There are different roles on each level. You can find more about the different roles here: [ZITADEL Administrator Roles](/guides/manage/console/administrators#roles)

-To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL.
+To be able to access the ZITADEL APIs, your service account needs permissions to ZITADEL.

 1. Go to the detail page of your organization
 2. Click in the top right corner the "+" button
-3. Search for your service user
+3. Search for your service account
 4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators))

 ![](../../../../public/img/console_org_owner_add.gif)

-## 3. Authenticate service user and request token
+## 3. Authenticate service account and request token

-Service users can be authenticated using private key JWT, client credentials, or personal access tokens.
-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.
+Service accounts can be authenticated using private key JWT, client credentials, or personal access tokens.
+The [service account 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).
+This guide covers a specific case of service account 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.
 This scope will add the ZITADEL APIs to the audience of the access token.
 ZITADEL APIs will check if they are in the audience of the access token and reject the token in case they are not in the audience.
@@ -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 a 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).
+Follow the steps in this guide to [generate a key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-account) 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.

@@ -134,7 +134,7 @@ Content-Type: application/json
 ```

 Use the access_token in the Authorization header to make requests to the ZITADEL APIs.
-In the following example, we read the organization of the service user.
+In the following example, we read the organization of the service account.

 ```bash
 curl --request GET \
@@ -146,11 +146,11 @@ curl --request GET \

 Get the client id and client secret by

-1. navigating to the service user, then
+1. navigating to the service account, then
 2. Open **Actions** in the top right corner and click on **Generate Client Secret**
 3. Copy the **ClientID** and **ClientSecret** from the dialog

-![](../../../../public/img/console_serviceusers_secret.gif)
+![](../../../../public/img/console_serviceaccounts_secret.gif)

 With the ClientId and ClientSecret from the prior step, you will need to craft a POST request to ZITADEL's token endpoint.

@@ -160,7 +160,7 @@ With the ClientId and ClientSecret from the prior step, you will need to craft a
 This is possible by sending a [reserved scope](/apis/openidoauth/scopes) for the audience.
 Use the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to include the ZITADEL project id in your audience

-In this step we will authenticate a service user and receive an access_token to use against the ZITADEL API.
+In this step we will authenticate a service account and receive an access_token to use against the ZITADEL API.

 #### Basic authentication

@@ -206,7 +206,7 @@ Content-Type: application/json
 ```

 Because the received token includes the `urn:zitadel:iam:org:project:id:zitadel:aud` scope, we can send it in your requests to the ZITADEL API as the Authorization Header.
-In this example we read the organization of the service user.
+In this example, we read the organization of the service account.

 ```bash
 curl --request GET \
@@ -219,7 +219,7 @@ curl --request GET \
 A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header.

 Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API.
-In this example, we read the organization of the service user.
+In this example, we read the organization of the service account.

 ```bash
 curl --request GET \
@@ -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-accounts/authenticate-service-accounts)
+- Read about the [different methods to authenticate service accounts](../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-accounts/authenticate-service-accounts)
+ - [Service Accounts](/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.

@@ -107,7 +107,7 @@ To use the auth API you will not need a specific role, because only an authentic

 For accessing the admin or management API the user will need some specific roles.
 If you encountered an error (e.g. `code = PermissionDenied desc = No matching permissions found`),
-ensure your service user has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role
+ensure your service account has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role
 and check the mentioned [guides](#prerequisites) at the beginning.

 If you've run into any other problem, don't hesitate to contact us or raise an issue on [ZITADEL](https://github.com/zitadel/zitadel/issues) or in the [SDK](https://github.com/zitadel/zitadel-go/issues).
@@ -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-accounts/authenticate-service-accounts)
+ - [Service Accounts](/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.

@@ -69,7 +69,7 @@ This will output something similar to:
 You have successfully used the ZITADEL Go SDK to call the management API!

 If you encountered an error (e.g. `code = PermissionDenied desc = No matching permissions found`),
-ensure your service user has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role
+ensure your service account has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role
 and check the mentioned [guides](#prerequisites) at the beginning.

 If you've run into any other problem, don't hesitate to contact us or raise an issue on [ZITADEL](https://github.com/zitadel/zitadel/issues) or in the [SDK](https://github.com/zitadel/zitadel-go/issues).
@@ -1,5 +1,5 @@
 When adding a new administrator, you can select multiple roles, some of which are only allowed to read data.
-This can be especially useful if you add service users for one of your projects where you only need read access.
+This can be especially useful if you add service account for one of your projects where you only need read access.

 By default, you will only search for users within the selected organization. If you like to give a role to a user outside the organization, you need to switch to the global search and type the exact loginname of the users. This will prevent users from guessing users from other organizations.

@@ -29,11 +29,11 @@ In this case please enable the Feature Flag "Use V2 Api in Management Console fo
        If no password is set initially, the initialization mail prompting the user to set his password is sent.

    </Tab>
-    <Tab value="service" label="Service User">
+    <Tab value="service" label="Service Account">
        <img
            src="/docs/img/guides/console/addmachine.png"
            width="540px"
-            alt="Add Service User"
+            alt="Add Service Account"
        />
    </Tab>
 </Tabs>
@@ -28,7 +28,7 @@ Service accounts represent machines, backend services, or IoT devices requiring
 * **Authentication:** Authenticates via **JWT Profile** or **Personal Access Tokens (PAT)**. Both methods support expiration settings.
 * **Usage:** Primarily used to gain access to the ZITADEL Management API or to secure backend-to-backend communication.

-To see how service users are utilized in practice, check out our [NextJS B2B Demo application](https://github.com/zitadel/zitadel-nextjs-b2b).
+To see how service accounts are utilized in practice, check out our [NextJS B2B Demo application](https://github.com/zitadel/zitadel-nextjs-b2b).

 ### Federated Users
 Federated users are identities managed by a third-party Identity Provider (IdP) such as Google, Azure AD, or GitHub.
@@ -8,7 +8,7 @@ import CreateUser from './_create-user.mdx';
 ZITADEL differs two different types of users:

 - Users (Humans)
- Service Users (Machine Accounts)
+- Service Accounts

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

@@ -18,7 +18,7 @@ A service account only has a name and a description aside his username.
 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 accounts can also be ZITADEL administrators is used to restrict access to specific projects or organizations.
+Service accounts are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL administrators 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
@@ -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-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/administrators) to manage the desired resources
+- [A service account](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/administrators) to manage the desired resources

 ## Manage ZITADEL resources through terraform

@@ -19,14 +19,14 @@ Zitadel uses provisioning domains to scope the handling of the SCIM **`externalI

 ### Setting a provisioning domain

-A provisioning domain can be assigned to a **machine user** by adding the following metadata entry:
+A provisioning domain can be assigned to a **service account** by adding the following metadata entry:

 - **Key:** `urn:zitadel:scim:provisioningDomain`
 - **Value:** the name of the provisioning domain

 ### How Zitadel stores `externalId`

-If a machine user has a provisioning domain set, any SCIM `externalId` provided during user provisioning or lookup is stored under:
+If a service account has a provisioning domain set, any SCIM `externalId` provided during user provisioning or lookup is stored under:
 `urn:zitadel:scim:{provisioningDomain}:externalId`

 If *no* provisioning domain is configured, Zitadel falls back to a simplified metadata key:
@@ -117,7 +117,7 @@ The tool will merge both objects into a single one in the importBody.json output

 ### 5.1. Obtain Access Token (or PAT) for API Access

-To call the ZITADEL Admin API, you need to authenticate using a **Service User** with the `IAM_OWNER` Manager permissions.
+To call the ZITADEL Admin API, you need to authenticate using a **Service Account** with the `IAM_OWNER` Manager permissions.

 There are two recommended authentication methods:

@@ -127,7 +127,7 @@ There are two recommended authentication methods:
 - **Personal Access Token (PAT)**
  [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-accounts/authenticate-service-accounts#authentication-methods)
+**Reference:** [Service Accounts & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)

 ### 5.2. Import Data with the ZITADEL API

@@ -100,7 +100,7 @@ The tool will generate `importBody.json`, which is ready for importing into ZITA

 ### 5.1. Obtain Access Token (or PAT) for API Access

-To call the ZITADEL Management API, you need to authenticate using a **Service User** with the `IAM_OWNER` Manager permissions.
+To call the ZITADEL Management API, you need to authenticate using a **Service Account** with the `IAM_OWNER` Manager permissions.

 There are two recommended authentication methods:

@@ -110,7 +110,7 @@ There are two recommended authentication methods:
 * **Personal Access Token (PAT)**
  [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-accounts/authenticate-service-accounts#authentication-methods)
+**Reference:** [Service Accounts & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)

 ---

@@ -30,12 +30,12 @@ Note that the resources will be migrated without the event stream. This means th

 ## Authorization

-You need a PAT from a service user with instance Owner permissions in both the source and target system.
+You need a PAT from a service account with instance Owner permissions in both the source and target system.

 ### Source system

 1. Go to your default organization
-2. Create a service user "import_user" with Access Token Type "Bearer"
+2. Create a service account "import_user" with Access Token Type "Bearer"
 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/administrators) with the role "instance Owner"
@@ -45,7 +45,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai
 ### Target system

 1. Go to your default organization
-2. Create a service user "export_user" with Access Token Type "Bearer"
+2. Create a service account "export_user" with Access Token Type "Bearer"
 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/administrators) with the role "instance Owner"
@@ -16,7 +16,7 @@ B2B can be a simple scenario where an organization only shares one of its projec
 ## Sample scenario

 Octagon is a fictitious company which is used throughout this guide to explain the details and key concepts of such a B2B scenario.
-Octagon tries to solve multiple tasks in the banking field. Its portfolio includes several applications for their employees, customers, and partners. Some of which are web-based, some of which are used by machine users only.
+Octagon tries to solve multiple tasks in the banking field. Its portfolio includes several applications for their employees, customers, and partners. Some of which are web-based, some of which are used by service accounts only.

 ### Portal Application

@@ -71,7 +71,7 @@ In this scenario, Dimitri and Michael share the same organization Pentagon, wher

 > Note: Roles are meant for internal business logic and therefore need to be validated separately, none of the users described are allowed to create user grants, at least if they do not own a ZITADEL administrator role.

-If you made a dashboard where some users are able to create user grants, the Management API to do such operations should be triggered with the personal access token of the users, not with a token of a machine user, to create a meaningful audit log.
+If you made a dashboard where some users are able to create user grants, the Management API to do such operations should be triggered with the personal access token of the users, not with a token of a service account, to create a meaningful audit log.
 If you had such a use case, ZITADEL administrator roles must be assigned to those users.

 ### Noteworthy
@@ -72,7 +72,7 @@ curl -L -X PUT "https://${CUSTOM_DOMAIN}/management/v1/projects/${PROJECT_ID}" \

 Where
 - `${CUSTOM_DOMAIN}` is your Custom Domain, f.e. mydemo.zitadel.cloud
- `${PAT}` is your service user's personal access token
+- `${PAT}` is your service account's personal access token
 - `${PROJECT_ID}` is the default-project's ID that can be found in Management Console see screenshot above

 You should now be able to log in with users of the organization that have the grant (in this example users of the organization "Customer-A").
@@ -1036,7 +1036,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-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/administrators) role to revert any login UI misconfigurations using the API.
+  1.  **Generate a backup PAT:** Create a [Service Account Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/administrators) role to revert any login UI misconfigurations using the API.
  2.  **Add a second Instance Administrator:** Always designate at least one [**second instance administrator**](/guides/manage/console/administrators).
 </Callout>

@@ -54,7 +54,7 @@ Our support team will follow up with additional verification steps if needed.

 ### Instance Manager access recovery

-If you need to recover a Manager account to an instance, please make sure you can't recover the account via another user or service user with Manager permissions.
+If you need to recover a Manager account to an instance, please make sure you can't recover the account via another user or service account with Manager permissions.

 Please visit the [support page in the customer portal](https://zitadel.com/admin/support):

@@ -10,9 +10,9 @@ This strategic versioning will ensure a more consistent and intuitive developmen
    <NewFeature components={props.components} />

    <details>
-        <summary>Machine User Authentication Methods</summary>
+        <summary>Service Account Authentication Methods</summary>

-        This feature introduces robust and standardized authentication methods for your machine users, enabling secure automated access to your resources.
+        This feature introduces robust and standardized authentication methods for your service accounts, enabling secure automated access to your resources.

        Choose from the following authentication methods:
        - **Private Key JWT Authentication**: Enhance security by using asymmetric cryptography. A client with a registered public key can generate and sign a JSON Web Token (JWT) with its private key to authenticate.
@@ -26,7 +26,7 @@ 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.
+        Currently, the client is tailored for machine-to-machine communication, enabling service accounts 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 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-accounts/authenticate-service-accounts).
+[Zitadel documentation on authenticating service accounts](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-accounts/authenticate-service-accounts).
+[Zitadel documentation on authenticating service accounts](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-accounts/authenticate-service-accounts).
+[Zitadel documentation on authenticating service accounts](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-accounts/authenticate-service-accounts).
+[Zitadel documentation on authenticating service accounts](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-accounts/authenticate-service-accounts).
+[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).

 ### Debugging

@@ -30,7 +30,7 @@ Check out our [Example Application](/sdk-examples/flutter#example-application).

 Additionally, you can use [smartive/zitadel-dart](https://github.com/smartive/zitadel-dart) for user and resource management.
 - Manage Resources through ZITADEL APIs
-  - Authenticate Service User
+  - Authenticate Service Account
  - Generated gRPC Clients for integrating ZITADEL API
  - User, Organization, Project, etc. Management

@@ -40,7 +40,7 @@ The following features are covered by the SDK:
    - Authorization Check using OAuth2 Introspection
    - Check User Roles on Endpoint
 - Manage Resources through ZITADEL APIs
-    - Authenticate Service User
+    - Authenticate Service Account
    - Generated gRPC Clients for integrating ZITADEL API
    - User, Organization, Project, etc. Management

@@ -54,7 +54,7 @@ You might want to check out the following links to find a good library:

 - [B2B customer portal](https://github.com/zitadel/zitadel-nextjs-b2b): Showcase the use of personal access tokens in a B2B environment. Uses Next.js Framework.
 - [Frontend with backend API](https://github.com/zitadel/example-quote-generator-app): A simple web application using a React front-end and a Python back-end API, both secured using Zitadel
- [Introspection](https://github.com/zitadel/examples-api-access-and-token-introspection): Python examples for securing an API and invoking it as a service user
+- [Introspection](https://github.com/zitadel/examples-api-access-and-token-introspection): Python examples for securing an API and invoking it as a service account
 - [Fine-grained authorization](https://github.com/zitadel/example-fine-grained-authorization): Leverage actions, custom metadata, and claims for attribute-based access control

 Search for the "example" tag in our repository to [explore all examples](https://github.com/search?q=topic%3Aexamples+org%3Azitadel&type=repositories).
@@ -115,7 +115,7 @@ zitadel:
          PasswordChangeRequired: false
 ```

-#### Machine User for System API
+#### Service Account for System API

 For programmatic access, configure a system user with RSA keys:

@@ -14,7 +14,7 @@ In that case, you can create a new PAT for the login client manually.

 In the following URLs, replace the base URL and the user ID according to your environment.

-1. Create a new machine user, for example at http://localhost:8080/ui/console/users/create-machine
+1. Create a new service account, for example at http://localhost:8080/ui/console/users/create-machine
 2. Create a PAT, for example at http://localhost:8080/ui/console/users/332169800719532035?new=true&id=pat
 3. Save the PAT to a file, for example `/path/on/your/host/login-client.pat`
 4. Make sure the user has the `Instance Login Client` role (internally called `IAM_LOGIN_CLIENT`), for example at http://localhost:8080/ui/console/instance/members
@@ -34,7 +34,7 @@ docker run -p 3000:3000 -v /path/on/your/host/login-client.pat:/path/in/containe
 <Callout type="warn">
 Before doing this, make sure you have a working PAT for an instance Owner user.
 In case something goes wrong and you lock yourself out from the login screen, you can revert the changes.
-Create a machine user PAT like you created the [login client PAT above](#create-login-client), but give the user the instance Owner role (internally called `IAM_OWNER`).
+Create a service account PAT like you created the [login client PAT above](#create-login-client), but give the user the instance Owner role (internally called `IAM_OWNER`).
 </Callout>

 Enable the `Login V2` feature flag, for example at the bottom of http://localhost:8080/ui/console/instance?id=features.
@@ -2,12 +2,12 @@ declare namespace NodeJS {
  interface ProcessEnv {
    // Allow any environment variable that matches the pattern
    [key: `${string}_AUDIENCE`]: string; // The system api url
-    [key: `${string}_SYSTEM_USER_ID`]: string; // The service user id
-    [key: `${string}_SYSTEM_USER_PRIVATE_KEY`]: string; // The service user private key
+    [key: `${string}_SYSTEM_USER_ID`]: string; // The service account id
+    [key: `${string}_SYSTEM_USER_PRIVATE_KEY`]: string; // The service account private key

    AUDIENCE: string; // The fallback system api url
-    SYSTEM_USER_ID: string; // The fallback service user id
-    SYSTEM_USER_PRIVATE_KEY: string; // The fallback service user private key
+    SYSTEM_USER_ID: string; // The fallback service account id
+    SYSTEM_USER_PRIVATE_KEY: string; // The fallback service account private key

    /**
     * The Zitadel API url
@@ -15,7 +15,7 @@ declare namespace NodeJS {
    ZITADEL_API_URL: string;

    /**
-     * The service user token
+     * The service account token
     * If ZITADEL_SERVICE_USER_TOKEN is set, its value is used.
     * If ZITADEL_SERVICE_USER_TOKEN is not set but ZITADEL_SERVICE_USER_TOKEN_FILE is set, the application blocks until the file is created.
     * As soon as the file exists, its content is read and ZITADEL_SERVICE_USER_TOKEN is set.
@@ -15,7 +15,7 @@ export function hasSystemUserCredentials(): boolean {
 }

 /**
- * Checks if service user token is available for authentication.
+ * Checks if service account token is available for authentication.
 *
 * @returns true if ZITADEL_SERVICE_USER_TOKEN is present, false otherwise
 */
@@ -23,11 +23,11 @@ export async function createServiceForHost<T extends ServiceClass>(service: T, s
  let token;

  // Determine authentication method based on available credentials
-  // Prefer system user JWT if available, fallback to service user token
+  // Prefer system user JWT if available, fallback to service account token
  if (hasSystemUserCredentials()) {
    token = await systemAPIToken();
  } else if (hasServiceUserToken()) {
-    // Use service user token authentication (self-hosted)
+    // Use service account token authentication (self-hosted)
    token = process.env.ZITADEL_SERVICE_USER_TOKEN;
  } else {
    throw new Error(
@@ -234,8 +234,8 @@ type humanColumns interface {
 //go:generate mockgen -typed -package domainmock -destination ./mock/machine_user.mock.go . MachineUserRepository

 type MachineUserRepository interface {
-	// Update updates the machine user
-	// It ensures that updates are only applied to machine users
+	// Update updates the service account
+	// It ensures that updates are only applied to service accounts
 	Update(ctx context.Context, client database.QueryExecutor, condition database.Condition, changes ...database.Change) (int64, error)
 	machineConditions
 	machineChanges
@@ -258,14 +258,14 @@ type machineChanges interface {
 	// SetAccessTokenType sets the personal access token type field
 	SetAccessTokenType(tokenType PersonalAccessTokenType) database.Change

-	// AddKey adds a key for the machine user
+	// AddKey adds a key for the service account
 	AddKey(key *MachineKey) database.Change
-	// RemoveKey removes a key for the machine user
+	// RemoveKey removes a key for the service account
 	RemoveKey(id string) database.Change

-	// AddPersonalAccessToken adds a personal access token for the machine user
+	// AddPersonalAccessToken adds a personal access token for the service account
 	AddPersonalAccessToken(pat *PersonalAccessToken) database.Change
-	// RemovePersonalAccessToken removes a personal access token for the machine user
+	// RemovePersonalAccessToken removes a personal access token for the service account
 	RemovePersonalAccessToken(id string) database.Change
 }

@@ -53,7 +53,7 @@ Before you run the tests you need an initialized user. The tests don't implement
  setup: creates human users  
  test: creates new sessions with user id check
 * `make oidc_session`  
-  setup: creates a machine user to create the auth request and session.  
+  setup: creates a service account to create the auth request and session.  
  test: creates an auth request, a session and links the session to the auth request. Implementation of [this flow](https://zitadel.com/docs/guides/integrate/login-ui/oidc-standard).
 * `make otp_session`  
  setup: creates 1 human user for each VU and adds OTP Email to it  
@@ -62,10 +62,10 @@ Before you run the tests you need an initialized user. The tests don't implement
  setup: creates 1 human user for each VU and adds OTP Email to it  
  test: creates a session based on the login name of the user and checks for the password on a second step
 * `make machine_jwt_profile_grant`  
-  setup: generates private/public key, creates machine users, adds a key  
+  setup: generates private/public key, creates service accounts, adds a key  
  test: creates a token and calls user info 
 * `make machine_jwt_profile_grant_single_user`  
-  setup: generates private/public key, creates machine user, adds a key  
+  setup: generates private/public key, creates service account, adds a key  
  test: creates a token and calls user info in parallel for the same user
 * `make users_by_metadata_key`  
  setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user
@@ -845,7 +845,7 @@ SystemDefaults:
    #   - "scrypt"
    #   - "pbkdf2"   # verifier for all pbkdf2 hash modes.
  SecretHasher:
-    # Set hasher configuration for machine users, API and OIDC client secrets.
+    # Set hasher configuration for service accounts, API and OIDC client secrets.
    Hasher:
      # Supported algorithms: "argon2i", "argon2id", "bcrypt", "scrypt", "pbkdf2"
      # Depending on the algorithm, different configuration options take effect.
@@ -964,7 +964,7 @@ DefaultInstance:
  Org:
    Name: ZITADEL # ZITADEL_DEFAULTINSTANCE_ORG_NAME
    # In the DefaultInstance.Org.Human section, the initial organization's admin user with the role IAM_OWNER is defined.
-    # If DefaultInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role.
+    # If DefaultInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role.
    Human:
      # In case that UserLoginMustBeDomain is false (default) and if you don't overwrite the username with an email,
      # it will be suffixed by the org domain (org-name + domain from config).
@@ -984,7 +984,7 @@ DefaultInstance:
        Verified: # ZITADEL_DEFAULTINSTANCE_ORG_HUMAN_PHONE_VERIFIED
      Password: # ZITADEL_DEFAULTINSTANCE_ORG_HUMAN_PASSWORD
    # In the DefaultInstance.Org.Machine section, the initial organization's admin user with the role IAM_OWNER is defined.
-    # If DefaultInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role.
+    # If DefaultInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role.
    Machine:
      Machine:
        Username: # ZITADEL_DEFAULTINSTANCE_ORG_MACHINE_MACHINE_USERNAME
@@ -38,7 +38,7 @@ BEGIN
        RETURN;
    END IF;
  
-    -- if human/machine user
+    -- if human/service account
    DECLARE
    	matched_roles TEXT[] := eventstore.find_roles(req_instance_id, perm);
 	BEGIN
@@ -29,7 +29,7 @@ BEGIN
        RETURN;
    END IF;

-    -- if human/machine user
+    -- if human/service account
    SELECT * FROM eventstore.permitted_orgs(
        req_instance_id
        , auth_user_id
@@ -122,7 +122,7 @@ FirstInstance:
  Org:
    Name: ZITADEL # ZITADEL_FIRSTINSTANCE_ORG_NAME
    # In the FirstInstance.Org.Human section, the initial organization's admin user with the role IAM_OWNER is defined.
-    # If FirstInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role.
+    # If FirstInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role.
    Human:
      # In case UserLoginMustBeDomain is false (default) and you don't overwrite the username with an email,
      # it will be suffixed by the org domain (org-name + domain from config).
@@ -144,7 +144,7 @@ FirstInstance:
      Password: Password1! # ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORD
      PasswordChangeRequired: true # ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORDCHANGEREQUIRED
    # In the FirstInstance.Org.Machine section, the initial organization's admin user with the role IAM_OWNER is defined.
-    # If FirstInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role.
+    # If FirstInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role.
    Machine:
      Machine:
        Username: # ZITADEL_FIRSTINSTANCE_ORG_MACHINE_MACHINE_USERNAME
@@ -53,9 +53,9 @@
        "METADATA": "أضف سمات مخصصة للمستخدم مثل القسم. يمكنك استخدام هذه المعلومات في إجراءاتك."
      },
      "MACHINES": {
-        "TITLE": "مستخدمو الخدمة",
-        "DESCRIPTION": "يقوم مستخدمو الخدمة بالمصادقة بشكل غير تفاعلي باستخدام رمز JWT موقّع بمفتاح خاص. يمكنهم أيضاً استخدام رمز وصول شخصي.",
-        "METADATA": "أضف سمات مخصصة للمستخدم مثل نظام المصادقة. يمكنك استخدام هذه المعلومات في إجراءاتك."
+        "TITLE": "حسابات الخدمة",
+        "DESCRIPTION": "تقوم حسابات الخدمة بالمصادقة بشكل غير تفاعلي باستخدام رمز JWT موقّع بمفتاح خاص. يمكنها أيضاً استخدام رمز وصول شخصي.",
+        "METADATA": "أضف سمات مخصصة للحساب مثل نظام المصادقة. يمكنك استخدام هذه المعلومات في إجراءاتك."
      },
      "SELF": {
        "METADATA": "أضف سمات مخصصة للمستخدم الخاص بك مثل قسمك. يمكنك استخدام هذه المعلومات في إجراءات مؤسستك."
@@ -424,7 +424,7 @@
    "ROLES": "الأدوار",
    "GRANTEDPROJECT": "المشاريع الممنوحة",
    "HUMANUSERS": "المستخدمون",
-    "MACHINEUSERS": "مستخدمو الخدمة",
+    "MACHINEUSERS": "حسابات الخدمة",
    "LOGOUT": "تسجيل خروج جميع المستخدمين",
    "NEWORG": "منظمة جديدة",
    "IAMADMIN": "أنت مسؤول instance. لاحظ أن لديك أذونات موسعة.",
@@ -983,7 +983,7 @@
      "COUNTRY": "الدولة"
    },
    "MACHINE": {
-      "TITLE": "تفاصيل مستخدم الخدمة",
+      "TITLE": "تفاصيل حساب الخدمة",
      "USERNAME": "اسم المستخدم",
      "NAME": "الاسم",
      "DESCRIPTION": "الوصف",
@@ -1145,7 +1145,7 @@
      "SELECTEDDEACTIVATED": "تم تعطيل المستخدمين المحددين.",
      "SELECTEDKEYSDELETED": "تم حذف المفاتيح المحددة.",
      "KEYADDED": "تمت إضافة المفتاح!",
-      "MACHINEADDED": "تم إنشاء مستخدم الخدمة!",
+      "MACHINEADDED": "تم إنشاء حساب الخدمة!",
      "DELETED": "تم حذف المستخدم بنجاح!",
      "UNLOCKED": "تم فتح قفل المستخدم بنجاح!",
      "PASSWORDLESSREGISTRATIONSENT": "تم إرسال رابط التسجيل بنجاح.",
@@ -53,9 +53,9 @@
        "METADATA": "Добавете персонализирани атрибути към потребителя, като отдела. Можете да използвате тази информация във вашите действия."
      },
      "MACHINES": {
-        "TITLE": "потребители на услугата",
-        "DESCRIPTION": "Потребителите на услугата се удостоверяват неинтерактивно, като използват JWT носител, подписан с частен ключ. Те могат също да използват личен маркер за достъп.",
-        "METADATA": "Добавете персонализирани атрибути към потребителя, като системата за удостоверяване. Можете да използвате тази информация във вашите действия."
+        "TITLE": "сметки на услугата",
+        "DESCRIPTION": "Сметките на услугата се удостоверяват неинтерактивно, като използват JWT носител, подписан с частен ключ. Те могат също да използват личен маркер за достъп.",
+        "METADATA": "Добавете персонализирани атрибути към сметката, като системата за удостоверяване. Можете да използвате тази информация във вашите действия."
      },
      "SELF": {
        "METADATA": "Добавете персонализирани атрибути към вашия потребител, като вашето отделение. Можете да използвате тази информация в действията на вашите организации."
@@ -424,7 +424,7 @@
    "ROLES": "Роли",
    "GRANTEDPROJECT": "Предоставени проекти",
    "HUMANUSERS": "Потребители",
-    "MACHINEUSERS": "Потребители на услугата",
+    "MACHINEUSERS": "Сметки на услугата",
    "LOGOUT": "Излезте всички потребители",
    "NEWORG": "Нова организация",
    "IAMADMIN": "Вие сте инстанс администратор. ",
@@ -989,7 +989,7 @@
      "COUNTRY": "Държава"
    },
    "MACHINE": {
-      "TITLE": "Подробности за потребителя на услугата",
+      "TITLE": "Подробности за сметката на услугата",
      "USERNAME": "Потребителско име",
      "NAME": "Име",
      "DESCRIPTION": "Описание",
@@ -1151,7 +1151,7 @@
      "SELECTEDDEACTIVATED": "Избраните потребители са деактивирани.",
      "SELECTEDKEYSDELETED": "Избраните ключове са изтрити.",
      "KEYADDED": "Ключът е добавен!",
-      "MACHINEADDED": "Потребител на услугата е създаден!",
+      "MACHINEADDED": "Сметката на услугата е създадена!",
      "DELETED": "Потребителят е изтрит успешно!",
      "UNLOCKED": "Потребителят е отключен успешно!",
      "PASSWORDLESSREGISTRATIONSENT": "Линкът за регистрация е изпратен успешно.",
@@ -53,9 +53,9 @@
        "METADATA": "Přidejte vlastní atributy k uživateli, jako je oddělení. Tyto informace můžete využít ve vašich akcích."
      },
      "MACHINES": {
-        "TITLE": "Uživatelé služby",
-        "DESCRIPTION": "Uživatelé služby se ověřují neinteraktivně pomocí tokenu nosiče JWT podepsaného soukromým klíčem. Mohou také použít osobní přístupový token.",
-        "METADATA": "Přidejte vlastní atributy k uživateli, jako je autentizační systém. Tyto informace můžete využít ve vašich akcích."
+        "TITLE": "Servisní účty",
+        "DESCRIPTION": "Servisní účty se ověřují neinteraktivně pomocí tokenu nosiče JWT podepsaného soukromým klíčem. Mohou také použít osobní přístupový token.",
+        "METADATA": "Přidejte vlastní atributy k účtu, jako je autentizační systém. Tyto informace můžete využít ve vašich akcích."
      },
      "SELF": {
        "METADATA": "Přidejte vlastní atributy k vašemu uživateli, jako je vaše oddělení. Tyto informace můžete využít v akcích vaší organizace."
@@ -424,7 +424,7 @@
    "ROLES": "Role",
    "GRANTEDPROJECT": "Pověřené projekty",
    "HUMANUSERS": "Uživatelé",
-    "MACHINEUSERS": "Systémoví uživatelé",
+    "MACHINEUSERS": "Servisní účty",
    "LOGOUT": "Odhlásit všechny uživatele",
    "NEWORG": "Nová organizace",
    "IAMADMIN": "Jste administrátor instance. Vezměte prosím na vědomí, že máte rozšířená oprávnění.",
@@ -990,7 +990,7 @@
      "COUNTRY": "Země"
    },
    "MACHINE": {
-      "TITLE": "Detaily systémového uživatele",
+      "TITLE": "Detaily servisního účtu",
      "USERNAME": "Uživatelské jméno",
      "NAME": "Název",
      "DESCRIPTION": "Popis",
@@ -53,9 +53,9 @@
        "METADATA": "Füge dem Benutzer benutzerdefinierte Attribute hinzu, wie die Abteilung. Du kannst diese Informationen in den Aktionen nutzen."
      },
      "MACHINES": {
-        "TITLE": "Service-Benutzer",
-        "DESCRIPTION": "Service-Benutzer authentifizieren sich nicht-interaktiv mit einem JWT Bearer-Token, welches mit einem privaten Schlüssel signiert ist. Sie können auch ein persönliches Zugangstoken verwenden.",
-        "METADATA": "Füge dem Benutzer benutzerdefinierte Attribute hinzu, wie das authentifizierende System. Du kannst diese Informationen in den Aktionen nutzen."
+        "TITLE": "Servicekonten",
+        "DESCRIPTION": "Servicekonten authentifizieren sich nicht-interaktiv mit einem JWT Bearer-Token, welches mit einem privaten Schlüssel signiert ist. Sie können auch ein persönliches Zugangstoken verwenden.",
+        "METADATA": "Füge dem Konto benutzerdefinierte Attribute hinzu, wie das authentifizierende System. Du kannst diese Informationen in den Aktionen nutzen."
      },
      "SELF": {
        "METADATA": "Füge deinem Benutzer benutzerdefinierte Attribute hinzu, wie deine Abteilung. Du kannst diese Informationen in den Aktionen deiner Organisation nutzen."
@@ -424,7 +424,7 @@
    "ROLES": "Rollen",
    "GRANTEDPROJECT": "Berechtigte Projekte",
    "HUMANUSERS": "Benutzer",
-    "MACHINEUSERS": "Service-Benutzer",
+    "MACHINEUSERS": "Servicekonten",
    "LOGOUT": "Alle Benutzer abmelden",
    "NEWORG": "Neue Organisation",
    "IAMADMIN": "Du bist ein Instanz-Administrator. Beachte, dass Du erhöhte Rechte besitzt.",
@@ -990,8 +990,8 @@
      "COUNTRY": "Land"
    },
    "MACHINE": {
-      "TITLE": "Details Service-Benutzer",
-      "USERNAME": "Benutzername",
+      "TITLE": "Details Servicekonto",
+      "USERNAME": "Kontoname",
      "NAME": "Name",
      "DESCRIPTION": "Beschreibung",
      "KEYSTITLE": "Schlüssel",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "Selektierte Benutzer deaktiviert.",
      "SELECTEDKEYSDELETED": "Selektierte Schlüssel gelöscht.",
      "KEYADDED": "Schlüssel hinzugefügt!",
-      "MACHINEADDED": "Service-Benutzer erstellt!",
+      "MACHINEADDED": "Servicekonto erstellt!",
      "DELETED": "Benutzer erfolgreich gelöscht!",
      "UNLOCKED": "Benutzer erfolgreich freigeschaltet!",
      "PASSWORDLESSREGISTRATIONSENT": "Passkey Registrierungslink via E-Mail versendet.",
@@ -53,9 +53,9 @@
        "METADATA": "Add custom attributes to the user like the department. You can use this information in your actions."
      },
      "MACHINES": {
-        "TITLE": "Service Users",
-        "DESCRIPTION": "Service Users authenticate non-interactively using a JWT bearer token signed with a private key. They can also use a personal access token.",
-        "METADATA": "Add custom attributes to the user like the authenticating system. You can use this information in your actions."
+        "TITLE": "Service Accounts",
+        "DESCRIPTION": "Service Accounts authenticate non-interactively using a JWT bearer token signed with a private key. They can also use a personal access token.",
+        "METADATA": "Add custom attributes to the account like the authenticating system. You can use this information in your actions."
      },
      "SELF": {
        "METADATA": "Add custom attributes to your user like your department. You can use this information in your organizations actions."
@@ -424,7 +424,7 @@
    "ROLES": "Roles",
    "GRANTEDPROJECT": "Granted Projects",
    "HUMANUSERS": "Users",
-    "MACHINEUSERS": "Service Users",
+    "MACHINEUSERS": "Service Accounts",
    "LOGOUT": "Logout All Users",
    "NEWORG": "New Organization",
    "IAMADMIN": "You are an IAM Administrator. Note that you have extended permissions.",
@@ -991,7 +991,7 @@
      "COUNTRY": "Country"
    },
    "MACHINE": {
-      "TITLE": "Service User Details",
+      "TITLE": "Service Account Details",
      "USERNAME": "User Name",
      "NAME": "Name",
      "DESCRIPTION": "Description",
@@ -1153,7 +1153,7 @@
      "SELECTEDDEACTIVATED": "Selected users deactivated.",
      "SELECTEDKEYSDELETED": "Selected keys deleted.",
      "KEYADDED": "Key added!",
-      "MACHINEADDED": "Service User created!",
+      "MACHINEADDED": "Service Account created!",
      "DELETED": "User deleted successfully!",
      "UNLOCKED": "User unlocked successfully!",
      "PASSWORDLESSREGISTRATIONSENT": "Registration Link sent successfully.",
@@ -53,9 +53,9 @@
        "METADATA": "Añade atributos personalizados al usuario como el departamento. Puedes usar esta información en tus acciones."
      },
      "MACHINES": {
-        "TITLE": "Usuarios del servicio",
-        "DESCRIPTION": "Los Usuarios del servicio se autentican de manera no interactiva usando un token portador JWT firmado con una clave privada. También pueden usar un token de acceso personal.",
-        "METADATA": "Añade atributos personalizados al usuario como el sistema autenticador. Puedes usar esta información en tus acciones."
+        "TITLE": "Cuentas de servicio",
+        "DESCRIPTION": "Las cuentas de servicio se autentican de manera no interactiva usando un token portador JWT firmado con una clave privada. También pueden usar un token de acceso personal.",
+        "METADATA": "Añade atributos personalizados a la cuenta como el sistema autenticador. Puedes usar esta información en tus acciones."
      },
      "SELF": {
        "METADATA": "Añade atributos personalizados a tu usuario como tu departamento. Puedes usar esta información en las acciones de tu organización."
@@ -424,7 +424,7 @@
    "ROLES": "Roles",
    "GRANTEDPROJECT": "Proyecto concedido",
    "HUMANUSERS": "Usuarios",
-    "MACHINEUSERS": "Usuarios del servicio",
+    "MACHINEUSERS": "Cuentas de servicio",
    "LOGOUT": "Cerrar sesión para todos los usuarios",
    "NEWORG": "Nueva organización",
    "IAMADMIN": "Eres un administrador instancia. Ten en cuenta que tienes permisos ampliados.",
@@ -990,8 +990,8 @@
      "COUNTRY": "País"
    },
    "MACHINE": {
-      "TITLE": "Detalles del usuario del servicio",
-      "USERNAME": "Nombre de usuario",
+      "TITLE": "Detalles de la cuenta de servicio",
+      "USERNAME": "Nombre de la cuenta",
      "NAME": "Nombre",
      "DESCRIPTION": "Descripción",
      "KEYSTITLE": "Claves",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "Se desactivaron los usuarios seleccionados.",
      "SELECTEDKEYSDELETED": "Se borraron las claves seleccionadas.",
      "KEYADDED": "¡Clave añadida!",
-      "MACHINEADDED": "¡Creado servicio de usuario!",
+      "MACHINEADDED": "¡Cuenta de servicio creada!",
      "DELETED": "¡El usuario se borró con éxito!",
      "UNLOCKED": "¡El usuario se desbloqueó con éxito!",
      "PASSWORDLESSREGISTRATIONSENT": "Enviado con éxito un enlace de registro.",
@@ -53,9 +53,9 @@
        "METADATA": "Ajoutez des attributs personnalisés à l'utilisateur comme le département. Vous pouvez utiliser cette information dans vos actions."
      },
      "MACHINES": {
-        "TITLE": "Utilisateurs des services",
-        "DESCRIPTION": "Les utilisateurs des services s'authentifient de manière non interactive en utilisant un token porteur JWT signé avec une clé privée. Elles peuvent également utiliser un token d'accès personnel.",
-        "METADATA": "Ajoute des attributs personnalisés à l'utilisateur comme le système d'authentification. Vous pouvez utiliser cette information dans vos actions."
+        "TITLE": "Comptes de service",
+        "DESCRIPTION": "Les comptes de service s'authentifient de manière non interactive en utilisant un token porteur JWT signé avec une clé privée. Elles peuvent également utiliser un token d'accès personnel.",
+        "METADATA": "Ajoute des attributs personnalisés au compte comme le système d'authentification. Vous pouvez utiliser cette information dans vos actions."
      },
      "SELF": {
        "METADATA": "Ajoutez des attributs personnalisés à votre utilisateur comme votre département. Vous pouvez utiliser cette information dans les actions de votre organisation."
@@ -424,7 +424,7 @@
    "ROLES": "Rôles",
    "GRANTEDPROJECT": "Projets octroyés",
    "HUMANUSERS": "Utilisateurs",
-    "MACHINEUSERS": "Utilisateurs de services",
+    "MACHINEUSERS": "Comptes de service",
    "LOGOUT": "Déconnexion de tous les utilisateurs",
    "NEWORG": "Nouvelle organisation",
    "IAMADMIN": "Vous êtes un administrateur d'instance. Notez que vous disposez de permissions étendues.",
@@ -990,8 +990,8 @@
      "COUNTRY": "Pays"
    },
    "MACHINE": {
-      "TITLE": "Détails de l'utilisateur du service",
-      "USERNAME": "Nom de l'utilisateur",
+      "TITLE": "Détails du compte de service",
+      "USERNAME": "Nom du compte",
      "NAME": "Nom",
      "DESCRIPTION": "Description",
      "KEYSTITLE": "Clés",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "Utilisateurs sélectionnés désactivés.",
      "SELECTEDKEYSDELETED": "Clés sélectionnées supprimées.",
      "KEYADDED": "Clé ajoutée !",
-      "MACHINEADDED": "Utilisateur de service créé !",
+      "MACHINEADDED": "Compte de service créé !",
      "DELETED": "Utilisateur supprimé avec succès !",
      "UNLOCKED": "Utilisateur déverrouillé avec succès !",
      "PASSWORDLESSREGISTRATIONSENT": "Lien d'enregistrement envoyé avec succès.",
@@ -53,9 +53,9 @@
        "METADATA": "Adj hozzá egyéni attribútumokat a felhasználóhoz, mint például az osztály. Ezt az információt felhasználhatod a műveleteid során."
      },
      "MACHINES": {
-        "TITLE": "Szolgáltatásfelhasználók",
-        "DESCRIPTION": "A szolgáltatásfelhasználók nem interaktívan hitelesítik magukat egy privát kulccsal aláírt JWT hordozó tokennel. Személyes hozzáférési tokent is használhatnak.",
-        "METADATA": "Adj hozzá egyéni attribútumokat a felhasználóhoz, mint például a hitelesítő rendszer. Ezt az információt felhasználhatod a műveleteid során."
+        "TITLE": "Szolgáltatásfiók",
+        "DESCRIPTION": "A szolgáltatásfiókok nem interaktívan hitelesítik magukat egy privát kulccsal aláírt JWT hordozó tokennel. Személyes hozzáférési tokent is használhatnak.",
+        "METADATA": "Adj hozzá egyéni attribútumokat a fiókhoz, mint például a hitelesítő rendszer. Ezt az információt felhasználhatod a műveleteid során."
      },
      "SELF": {
        "METADATA": "Adj hozzá egyéni attribútumokat a felhasználódhoz, mint például az osztályod. Ezt az információt felhasználhatod a szervezeted műveleteiben."
@@ -424,7 +424,7 @@
    "ROLES": "Szerepkörök",
    "GRANTEDPROJECT": "Megadott Projektek",
    "HUMANUSERS": "Felhasználók",
-    "MACHINEUSERS": "Szolgáltatási Felhasználók",
+    "MACHINEUSERS": "Szolgáltatásfiók",
    "LOGOUT": "Minden Felhasználó Kijelentkezése",
    "NEWORG": "Új Szervezet",
    "IAMADMIN": "Te egy példány Adminisztrátor vagy. Ne felejtsd el, hogy kibővített jogosultságokkal rendelkezel.",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "A kiválasztott felhasználók deaktiválva.",
      "SELECTEDKEYSDELETED": "A kiválasztott kulcsok törölve.",
      "KEYADDED": "Kulcs hozzáadva!",
-      "MACHINEADDED": "Service User létrehozva!",
+      "MACHINEADDED": "Szolgáltatásfiók létrehozva!",
      "DELETED": "A felhasználó sikeresen törölve!",
      "UNLOCKED": "A felhasználó sikeresen feloldva!",
      "PASSWORDLESSREGISTRATIONSENT": "A Passkey regisztrációs link sikeresen elküldve.",
@@ -53,8 +53,8 @@
        "METADATA": "Tambahkan atribut khusus ke pengguna seperti departemen. Anda dapat menggunakan informasi ini dalam tindakan Anda."
      },
      "MACHINES": {
-        "TITLE": "Pengguna Layanan",
-        "DESCRIPTION": "Pengguna Layanan mengautentikasi secara non-interaktif menggunakan token pembawa JWT yang ditandatangani dengan kunci pribadi. Mereka juga dapat menggunakan token akses pribadi.",
+        "TITLE": "Akun Layanan",
+        "DESCRIPTION": "Akun Layanan mengautentikasi secara non-interaktif menggunakan token pembawa JWT yang ditandatangani dengan kunci pribadi. Mereka juga dapat menggunakan token akses pribadi.",
        "METADATA": "Tambahkan atribut khusus kepada pengguna seperti sistem autentikasi. Anda dapat menggunakan informasi ini dalam tindakan Anda."
      },
      "SELF": {
@@ -424,7 +424,7 @@
    "ROLES": "Peran",
    "GRANTEDPROJECT": "Proyek yang Diberikan",
    "HUMANUSERS": "Pengguna",
-    "MACHINEUSERS": "Pengguna Layanan",
+    "MACHINEUSERS": "Akun Layanan",
    "LOGOUT": "Logout Semua Pengguna",
    "NEWORG": "Organisasi Baru",
    "IAMADMIN": "Anda adalah Administrator instance. Perhatikan bahwa Anda memiliki izin yang diperluas.",
@@ -990,7 +990,7 @@
      "COUNTRY": "Negara"
    },
    "MACHINE": {
-      "TITLE": "Detail Pengguna Layanan",
+      "TITLE": "Detail Akun Layanan",
      "USERNAME": "Nama belakang",
      "NAME": "Nama",
      "DESCRIPTION": "Keterangan",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "Pengguna terpilih dinonaktifkan.",
      "SELECTEDKEYSDELETED": "Kunci yang dipilih dihapus.",
      "KEYADDED": "Kunci ditambahkan!",
-      "MACHINEADDED": "Pengguna Layanan dibuat!",
+      "MACHINEADDED": "Akun Layanan dibuat!",
      "DELETED": "Pengguna berhasil dihapus!",
      "UNLOCKED": "Pengguna berhasil membuka kuncinya!",
      "PASSWORDLESSREGISTRATIONSENT": "Tautan Pendaftaran berhasil dikirim.",
@@ -53,9 +53,9 @@
        "METADATA": "Aggiungi attributi personalizzati all'utente come il dipartimento. Puoi utilizzare queste informazioni nelle tue azioni."
      },
      "MACHINES": {
-        "TITLE": "Utenti di servizio",
-        "DESCRIPTION": "Utenti di servizio si autenticano in modo non interattivo utilizzando un token JWT firmato con una chiave privata. Possono anche utilizzare un token di accesso personale.",
-        "METADATA": "Aggiungi attributi personalizzati all'utente come il sistema di autenticazione. Puoi utilizzare queste informazioni nelle tue azioni."
+        "TITLE": "Account di servizio",
+        "DESCRIPTION": "Gli account di servizio si autenticano in modo non interattivo utilizzando un token JWT firmato con una chiave privata. Possono anche utilizzare un token di accesso personale.",
+        "METADATA": "Aggiungi attributi personalizzati all'account come il sistema di autenticazione. Puoi utilizzare queste informazioni nelle tue azioni."
      },
      "SELF": {
        "METADATA": "Aggiungi attributi personalizzati al tuo utente come il tuo dipartimento. Puoi utilizzare queste informazioni nelle azioni della tua organizzazione."
@@ -424,7 +424,7 @@
    "ROLES": "Ruoli",
    "GRANTEDPROJECT": "Progetto delegato",
    "HUMANUSERS": "Utenti",
-    "MACHINEUSERS": "Utenti di servizio",
+    "MACHINEUSERS": "Account di servizio",
    "LOGOUT": "Esci con tutti gli utenti",
    "NEWORG": "Nuova organizzazione",
    "IAMADMIN": "Sei un amministratore d'istanza. Nota che hai autorizzazioni estese.",
@@ -989,8 +989,8 @@
      "COUNTRY": "Paese"
    },
    "MACHINE": {
-      "TITLE": "Dettagli dell'utente del servizio",
-      "USERNAME": "Nome utente",
+      "TITLE": "Dettagli dell'account di servizio",
+      "USERNAME": "Nome dell'account",
      "NAME": "Nome",
      "DESCRIPTION": "Descrizione",
      "KEYSTITLE": "Chiavi",
@@ -1151,7 +1151,7 @@
      "SELECTEDDEACTIVATED": "Utenti selezionati disattivati.",
      "SELECTEDKEYSDELETED": "Tasti selezionati cancellati.",
      "KEYADDED": "Chiave aggiunta!",
-      "MACHINEADDED": "Utente di servizio creato!",
+      "MACHINEADDED": "Account di servizio creato!",
      "DELETED": "Utente cancellato con successo!",
      "UNLOCKED": "Utente sbloccato con successo!",
      "PASSWORDLESSREGISTRATIONSENT": "Link per la registrazione inviato con successo.",
@@ -53,9 +53,9 @@
        "METADATA": "部門のようなユーザーにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。"
      },
      "MACHINES": {
-        "TITLE": "サービス利用者",
-        "DESCRIPTION": "サービス ユーザーは、秘密キーで署名された JWT ベアラー トークンを使用して非対話的に認証されます。個人のアクセス トークンを使用することもできます。",
-        "METADATA": "認証システムのようなユーザーにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。"
+        "TITLE": "サービスアカウント",
+        "DESCRIPTION": "サービスアカウントは、秘密キーで署名された JWT ベアラー トークンを使用して非対話的に認証されます。個人のアクセス トークンを使用することもできます。",
+        "METADATA": "認証システムのようなアカウントにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。"
      },
      "SELF": {
        "METADATA": "あなたの部門のようなあなたのユーザーにカスタム属性を追加してください。この情報をあなたの組織のアクションで使用できます。"
@@ -424,7 +424,7 @@
    "ROLES": "ロール",
    "GRANTEDPROJECT": "グラントされたプロジェクト",
    "HUMANUSERS": "ユーザー",
-    "MACHINEUSERS": "サービスユーザー",
+    "MACHINEUSERS": "サービスアカウント",
    "LOGOUT": "すべてのユーザーをログアウトする",
    "NEWORG": "新しい組織",
    "IAMADMIN": "あなたはインスタンス管理者です。広範囲の権限があることに注意してください。",
@@ -990,8 +990,8 @@
      "COUNTRY": "国"
    },
    "MACHINE": {
-      "TITLE": "サービスユーザーの詳細",
-      "USERNAME": "ユーザー名",
+      "TITLE": "サービスアカウントの詳細",
+      "USERNAME": "アカウント名",
      "NAME": "名前",
      "DESCRIPTION": "概要",
      "KEYSTITLE": "キー",
@@ -1152,7 +1152,7 @@
      "SELECTEDDEACTIVATED": "選択されたユーザー非アクティブになりました。",
      "SELECTEDKEYSDELETED": "選択したキーが削除されました。",
      "KEYADDED": "キーが追加されました！",
-      "MACHINEADDED": "サービスユーザーが作成されました！",
+      "MACHINEADDED": "サービスアカウントが作成されました！",
      "DELETED": "ユーザーが正常に削除されました！",
      "UNLOCKED": "ユーザーのロックが正常に解除されました！",
      "PASSWORDLESSREGISTRATIONSENT": "登録リンクが正常に送信されました。",
@@ -53,8 +53,8 @@
        "METADATA": "부서와 같은 사용자 정의 속성을 사용자에게 추가하세요. 이 정보를 작업에 사용할 수 있습니다."
      },
      "MACHINES": {
-        "TITLE": "서비스 사용자",
-        "DESCRIPTION": "서비스 사용자는 개인 키로 서명된 JWT bearer 토큰을 사용하여 비대화형 인증을 수행합니다. 또한 개인 액세스 토큰을 사용할 수 있습니다.",
+        "TITLE": "서비스 계정",
+        "DESCRIPTION": "서비스 계정은 개인 키로 서명된 JWT bearer 토큰을 사용하여 비대화형 인증을 수행합니다. 또한 개인 액세스 토큰을 사용할 수 있습니다.",
        "METADATA": "인증 시스템과 같은 사용자 정의 속성을 사용자에게 추가하세요. 이 정보를 작업에 사용할 수 있습니다."
      },
      "SELF": {
@@ -424,7 +424,7 @@
    "ROLES": "역할",
    "GRANTEDPROJECT": "부여된 프로젝트",
    "HUMANUSERS": "사용자",
-    "MACHINEUSERS": "서비스 사용자",
+    "MACHINEUSERS": "서비스 계정",
    "LOGOUT": "모든 사용자 로그아웃",
    "NEWORG": "새 조직",
    "IAMADMIN": "인스턴스 관리자입니다. 확장된 권한이 부여되었습니다.",
--- a/Show More
+++ b/Show More