#Overview

#Accounts allow users to sign in to both the Enterprise API and the admin UI with email and password

Accounts are used to authenticate users against both the Enterprise API and the admin UI using an email address and password.

• A Super Admin (or any admin with the right role) typically creates accounts via protected administration routes.
• Optional self-service signup is available via an unprotected endpoint that is controlled by the account-registration feature flag. The flag defaults to enabled, so public signup is exposed unless you disable it.
• New accounts start without any roles, so they cannot perform operations until roles are assigned.

#Accounts stay global while their access is defined by roles in specific organizations, tenants, and services

Accounts are global resources and are not bound to a single organization or tenant.

• The same account can be granted access to multiple organizations, tenants, sub-tenants, or services.
• What an account can do is entirely determined by the roles assigned to it, and by the permissions those roles grant within each scope.

#Enabled self-registration lets end users create their own accounts via /v1/account/register

The unprotected /v1/account/register endpoint is controlled by the account-registration feature flag.

• It is enabled by default, so new Enterprise Stack deployments expose public signup until you explicitly disable the flag (recommended for production).
• Toggle the feature via the feature manager or _features.conf, depending on your deployment workflow.

Disable this flag everywhere you do not want public account creation, and only leave it enabled for sandboxes, demos, or other controlled environments.

#Get Started

• Create Account - Provision an account via the protected admin APIs (or optional self-registration).
• Assign Roles - Give an account permissions scoped to specific organizations, tenants, or services.