# Administration operating model Source: https://docs.settlemint.com/docs/user-guides/user-management/admin-operating-model Understand how DALP separates organization administration, invitations, platform permissions, API keys, webhooks, providers, security settings, and operator wallets. DALP administration is split across organization membership, invitations, platform permissions, personal API access, outbound webhooks, provider configuration, account security, and operator wallets. Each surface answers a different operating question: * Who belongs to the organization? * Which people still need to accept an invitation? * What can each role administer? * Which credentials act on behalf of an account? * Where are outbound events sent? * Which provider and security settings affect onboarding or signing? * Which platform wallets need funding or monitoring? ## Administration surfaces [#administration-surfaces] | Surface | Where operators use it | What it controls | | ---------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Organizations | **Admin** > **Organizations** | Organization records, owners, member counts, asset counts, and organization creation. | | Users and participants | **Participants** > **Users** and user detail pages | User accounts, invitations, identity registration, KYC evidence, holdings, activity, and security follow-up. | | Account API keys | **Account** > **API keys** | API credentials for the active organization context of the signed-in account. | | Webhooks | **Platform settings** > **Webhooks** | Outbound endpoint delivery, signing secret lifecycle, delivery history, and endpoint settings. | | Compliance providers | **Platform settings** > **Compliance providers** | Provider credentials, hosted-flow settings, webhook authentication details, and provider monitoring. | | Account security | **Account** > **Security** and user detail security views | Two-factor authentication, active sessions, passkeys, and account protection controls that are enabled for the deployment. | | Operator wallets | **Admin** > **Operator wallets** | Operator-wallet accounts and native balances used for platform operations. | ## Role and permission model [#role-and-permission-model] DALP combines organization roles with platform-specific permissions. * The **admin** role can list and create organizations, manage platform settings, operate systems, read exchange rates, and manage webhooks. * The **owner** role can manage users, platform settings, systems, exchange rates, and webhooks inside the organization. * The **member** role can read settings, systems, and exchange rates, but does not manage webhooks. Some views also check on-chain or system-level roles before showing operational data. For example, operator-wallet access is available to administrators, system managers, or gas managers because that page is about operational wallet funding and monitoring. ## Operating flow for administrators [#operating-flow-for-administrators] 1. Confirm the active organization before creating users, invitations, API keys, providers, or webhooks. API keys, provider settings, and webhook permissions are evaluated against the organization context of the current session. 2. Use **Admin** > **Organizations** when the task is organization-level setup or review. The page is available to platform administrators. 3. Use **Participants** > **Users** when the task is a person, invitation, identity, KYC, holdings, activity, or account-security review. User detail pages show the evidence and follow-up actions available for that participant. 4. Use **Account** > **API keys** when an integration needs account-scoped API credentials. Treat API keys as credentials for the current organization context, not as a replacement for user, provider, or webhook permissions. 5. Use **Platform settings** > **Compliance providers** when onboarding flows depend on a KYC, KYB, AML, or wallet-monitoring provider. Provider pages hold vendor credentials, webhook authentication settings, and provider monitoring views. 6. Use **Platform settings** > **Webhooks** when an external system needs outbound event delivery. Webhook-management permission grants access to the webhook list and management entry point. Endpoint overview, deliveries, and settings pages require administrator or system-manager access because they expose operational delivery data. 7. Use **Account** > **Security** when the task is account protection. The available cards depend on deployment configuration and the signing methods already enabled for the user. 8. Use **Admin** > **Operator wallets** when operations need to inspect operator-wallet balances. Low native balances can affect operational workflows that rely on those wallets. ## What stays outside this page [#what-stays-outside-this-page] This page maps the administration model. It does not replace task guides for inviting users, creating users, registering identities, configuring providers, configuring webhooks, managing API keys, or reviewing account security. Use the related pages for task steps and deeper reference material. ## Related pages [#related-pages] * [User lifecycle events](/docs/events) * [Invite users](/docs/user-guides/user-management/invite-users) * [Create users](/docs/user-guides/user-management/create-users) * [User onboarding](/docs/user-guides/user-management/user-onboarding) * [Account security](/docs/user-guides/user-management/account-security) * [Authentication](/docs/architecture/security/authentication) * [Webhook events](/docs/events) * [Compliance providers](/docs/architecture/integrations/compliance-providers) * [Onboarding a provider](/docs/developer-guides/compliance/onboarding-a-provider)