# Admin operating model Source: https://docs.settlemint.com/docs/developer-guides/platform-setup/admin-operating-model Plan the DALP administrator setup across organizations, users, roles, API keys, webhooks, providers, and operator wallets. DALP administration starts with the organization that owns the platform workspace. Platform administrators configure the organization, invite operators, grant roles for sensitive actions, create machine credentials for integrations, and connect the operating surfaces that need ongoing care. This page is an explanation for platform administrators. It maps the live administration areas and points to the task pages that show how to configure each one. ## Administration map [#administration-map] | Admin area | What it governs | Where to configure it | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------ | | Organization profile | The active organization context, name, and branding visible to operators. | Platform settings, Organization | | Users and invitations | People who can sign in and act inside the organization. | User management and invitation flows | | Roles and permissions | Which users can list, grant, or change platform roles and system permissions. | Platform settings, Permissions | | API keys | Machine-to-machine credentials scoped to the organization active when the key is created. | Account, API keys | | Webhook endpoints | Outbound event delivery, signing state, endpoint health, and delivery history. | Platform settings, Webhooks | | Providers and platform services | Compliance providers, trusted issuers, verification topics, exchange rates, pricing, asset classes, and templates. | Platform settings | | Operator wallets | Operational wallet balances used by the platform for supported administrative workflows. | Admin, Operator wallets | ## What to configure first [#what-to-configure-first] Start with organization and access controls before connecting automation. The organization context determines which off-chain records and API-key scopes a user can reach. A key created while the wrong organization is active can point automation at the wrong records, even when the user belongs to multiple organizations. 1. Create the first administrator and organization. See [first admin setup](/docs/developer-guides/platform-setup/first-admin-setup). 2. Invite administrators and operators who need console access. See [add admins](/docs/developer-guides/platform-setup/add-admins). 3. Grant or change platform roles only after the user has the wallet and identity state required by the target role. See [change admin roles](/docs/developer-guides/platform-setup/change-admin-roles). 4. Create separate API keys for integration workloads that need REST API access. See [API integration getting started](/docs/developer-guides/api-integration/getting-started). 5. Configure webhook endpoints for systems that consume DALP events. See [webhook endpoints](/docs/developer-guides/api-integration/webhook-endpoints). 6. Configure provider and platform settings that your asset programs depend on, such as compliance providers, [trusted issuers and verification topics](/docs/developer-guides/compliance/configure-trusted-issuers), exchange rates, pricing, and templates. ## Access model [#access-model] DALP uses both off-chain organization permissions and on-chain system roles. Off-chain organization roles control organization-level administration such as organization management, user membership, API keys, and webhook endpoint management. Webhook management is gated by the organization permission for webhook management, so organization owners and admins can manage endpoints while ordinary members cannot. On-chain system roles control asset and system operations that require blockchain authority. The platform settings permissions page reads the default system and shows which users can list or grant system roles. Operator wallet visibility also depends on system-level administrative roles such as admin, system manager, or gas manager. Keep those two layers separate when you review access. A browser user may be allowed to manage organization settings without having every on-chain system role, and a system role does not replace organization membership for off-chain admin actions. ## API keys and automation [#api-keys-and-automation] API keys inherit the permissions of the creating user and are scoped to the organization active at creation time. Create a separate key for each organization and integration workload. Do not reuse one organization key for another organization. API keys authenticate REST API requests. They are not accepted on RPC-only routes. For route and header details, see [API integration getting started](/docs/developer-guides/api-integration/getting-started). For organization scoping rules, see [organization and system scope](/docs/developer-guides/api-integration/organization-system-scope). ## Webhooks and provider operations [#webhooks-and-provider-operations] Webhook endpoints connect DALP events to external systems. Administrators can create endpoints and inspect signing state. The Webhooks area shows delivery history and endpoint settings. Provider configuration sits next to webhooks because provider events often feed compliance and verification workflows. Configure compliance providers, trusted issuers, and verification topics before relying on automated checks in an asset workflow. See [compliance provider paths](/docs/architecture/integrations/compliance-providers) when you need to choose between manual claim issuance and provider-driven ClaimSource issuance. ## Operating checks [#operating-checks] Review these checks before moving a platform from setup into production operations. | Check | Why it matters | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Active organization | Confirms administrators, API keys, users, and provider records operate in the intended organization. | | Administrator list | Confirms only the expected users can manage organization and system controls. | | Role assignments | Confirms on-chain system authority matches the operating model for minting, pausing, compliance, gas, and asset administration. | | API key inventory | Confirms machine credentials are scoped, rotated, and separated by workload. | | Webhook endpoint health | Confirms downstream systems receive signed events and failed deliveries are visible. | | Provider status | Confirms compliance provider integrations and verification topics are ready before asset workflows depend on them. | | Operator wallet balance | Confirms operational wallets have enough funds for workflows that require gas or platform-managed transactions. | ## Related pages [#related-pages] * [Platform overview](/docs/developer-guides/platform-setup/platform-overview) * [First admin setup](/docs/developer-guides/platform-setup/first-admin-setup) * [Add admins](/docs/developer-guides/platform-setup/add-admins) * [Change admin roles](/docs/developer-guides/platform-setup/change-admin-roles) * [API integration getting started](/docs/developer-guides/api-integration/getting-started) * [Organization and system scope](/docs/developer-guides/api-integration/organization-system-scope) * [Webhook endpoints](/docs/developer-guides/api-integration/webhook-endpoints) * [Configure trusted issuers](/docs/developer-guides/compliance/configure-trusted-issuers) * [Authentication](/docs/architecture/security/authentication) * [Authorization](/docs/architecture/security/authorization)