Administration 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
| 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
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
- 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.
- Use Admin > Organizations when the task is organization-level setup or review. The page is available to platform administrators.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
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
Operator wallets
Check configured operator wallet balances from the Admin area before low native token balances interrupt gas-funded platform operations.
Invite users
Send invitations for team members and external partners to join your platform from the Users page, and understand what the recipient completes after accepting.