andwati/zitadel
1
0
Fork 0
mirror of https://github.com/andwati/zitadel.git synced 2026-11-03 12:52:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: fixed some typos, formatting, grammar (#11540)

Browse Source 
# Which Problems Are Solved

- Typos
- Punctuation
- Markdown table formatting
- ...

(A bunch of issues my editor gave)

# How the Problems Are Solved


# Additional Changes


# Additional Context
This commit is contained in:
Wim Van Laer
2026-02-13 07:45:17 +01:00
committed by GitHub
parent b0609aa861
commit 9b064d8b74
127 changed files with 764 additions and 760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/docs/content/concepts/structure/instance.mdx
+2 -2
View File
@@ -8,7 +8,7 @@ sidebar_label: Instances
An instance is the top node in ZITADEL's data hierarchy.
Within an instance all the default [settings](/concepts/structure/policies),
such as branding, login policy, password policy, etc. for the system can be configured.
One instance normally runs on one domain and represents one issuer (e.g login.customer.com).
One instance normally runs on one domain and represents one issuer (e.g. login.customer.com).
One instance can contain multiple [organizations](/guides/manage/console/organizations-overview),
which in turn can represent your own company (e.g. departments), your business customers or a consumer organization.
@@ -25,7 +25,7 @@ You will find more detailed explanations around the different concepts in the fo
ZITADEL has the concept of virtual instances.
When installing ZITADEL from scratch, one instance is always automatically created for you.
Nevertheless, you can add more virtual instances via the [system API](/reference/api/system).
This is useful if you have business customers, which in turn have their business customers with self service and Custom Domain demands.
This is useful if you have business customers, which in turn have their business customers with self-service and Custom Domain demands.
By providing a virtual ZITADEL instances, your customers have all the customization options available in ZITADEL.
Scaling ZITADEL instances virtually enables you to easily distribute your limited compute resources to all your customers.
apps/docs/content/concepts/structure/users.mdx
+3 -3
View File
@@ -19,9 +19,9 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use
### Service users
Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
Service users are for machine-to-machine communication, and you would use those typically to access secure backend services.
For example in ZITADEL you would require an authenticated Service User to access the Management API.
The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.
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.
@@ -33,7 +33,7 @@ A user with an administrator role is not only an end-user of ZITADEL but can als
### Federated users
Federated users are identities that are managed by a third-party identity provider.
Users can login via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Users can log in via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Federated user [accounts are linked](../features/account-linking) to internal users to be able to assign roles and keep an audit trail.
### External users