> ## Documentation Index > Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt > Use this file to discover all available pages before exploring further. # SDK — define a customer role for a business account > Defines a role that inherits a built-in one. The role lives only in the signed authorization document, so there is no separate role resource. Requires step-up authentication. ## OpenAPI ````yaml https://app.dynamic.xyz/api-docs/public-api.yaml post /sdk/{environmentId}/businessAccounts/{businessAccountId}/roles openapi: 3.0.1 info: title: Dashboard API description: Dashboard API documentation version: 1.0.0 servers: - url: https://app.dynamicauth.com/api/v0 - url: https://app.dynamic.xyz/api/v0 - url: http://localhost:3333/api/v0 security: [] tags: - name: Analytics description: Query usage analytics and event counts for your environment. - name: SDK description: SDK-facing endpoints consumed by embedded Dynamic clients. - name: Server description: Server-side SDK endpoints authenticated by environment API tokens. - name: Organizations description: >- Manage organizations — the top-level container for all environments and projects. - name: Projects description: Manage projects that group related environments under an organization. - name: Environments description: >- Manage environments (live and sandbox) where your authentication configuration lives. - name: Users description: List, search, and manage authenticated users within an environment. - name: Invites description: >- Manage invitation links that grant specific external users access to your environment. - name: Tokens description: >- Create and manage API tokens used to authenticate requests to the Dynamic API. - name: Origins description: >- Configure allowed origins (CORS) for SDK and API access to your environment. - name: Allowlists description: >- Manage allowlists to control which wallet addresses or email addresses can access your environment. - name: Wallets description: View and manage wallets linked to users in your environment. - name: Members description: Manage team members and their roles within an organization. - name: Sessions description: View and revoke active user sessions within an environment. - name: Settings description: Read and update environment-level configuration settings. - name: Exchanges description: >- Configure exchange integrations (Coinbase, Binance, etc.) for fiat on-ramp within your environment. - name: Yield description: List yield vaults registered for your environment. - name: Providers description: >- List, enable, disable, and configure authentication providers (OAuth, email, wallet, SMS, etc.) for your environment. - name: Captcha description: >- Configure captcha verification (provider, site key, secret key) for your environment. - name: Gates description: >- Define access gates that restrict environment entry to users who meet specific criteria. - name: Chains description: >- Manage the blockchain networks available for wallet connection in your environment. - name: Exports description: Export user and wallet data from your environment as downloadable files. - name: Events description: Browse the event log of actions performed within your environment. - name: Webhooks description: >- Create and manage webhooks to receive real-time events (user.created, wallet.linked, etc.) at your endpoint. - name: Custom Fields description: >- Define and manage custom metadata fields collected from users at sign-up or login. - name: MfaSettings description: >- Configure multi-factor authentication (MFA) policies for your organization. - name: Mfa description: Manage MFA enrollment and verification for individual users. - name: CustomHostnames description: >- Configure custom hostnames for white-labeling the Dynamic authentication experience. - name: TestAccount description: >- Manage test accounts used for automated testing and QA within an environment. - name: NameServices description: >- Configure name service integrations (ENS, Unstoppable Domains, etc.) for human-readable wallet addresses. - name: GlobalWallets description: >- Manage global wallets shared across multiple environments in an organization. - name: GlobalWalletConnections description: Configure which environments can access and use global wallets. - name: GlobalWalletAccessControl description: Control which users and roles can access and operate global wallets. - name: UserApiTokens description: >- Create and manage user-scoped API tokens for programmatic access on behalf of a user. - name: Waas description: Wallet-as-a-Service endpoints for creating and managing embedded wallets. - name: WalletConnect description: Configure WalletConnect integration settings for your environment. - name: Checkout description: >- Accept crypto payments and deposits from any wallet. Settle in any token you choose. - name: Flow description: >- Accept crypto payments, deposits, and withdrawals. Amount and destination are fixed server-side at create; the post-create lifecycle is driven with a capability session token. - name: FlowAnalytics description: >- Query aggregated analytics and paginated transaction lists for the Flow product. - name: Gasless description: >- Query billing summaries and paginated transaction lists for sponsored (gasless) transactions. - name: Custom Networks description: >- Add and manage custom EVM-compatible networks beyond the built-in chain list. - name: Chainalysis description: >- Configure Chainalysis integration for blockchain address screening and risk assessment. - name: Visits description: Track and query user visit activity within your environment. - name: ExternalJwt description: >- Configure external JWT providers so existing auth tokens can be used with Dynamic. - name: SDK Views description: >- Manage SDK view configurations that customize the appearance of Dynamic modals and flows. - name: DeeplinkUrls description: Configure deep link URLs for mobile app integration with the Dynamic SDK. - name: OrganizationSettings description: >- Read and update organization-level settings such as approval workflow configuration. - name: AdminActions description: >- Manage admin action requests that require approval from another administrator. - name: ClientGrant description: | OAuth 2.0 Device Authorization Grant flow (RFC 8628) used by first-party Dynamic clients (CLI, MCP server, demo apps, IDE plugins) to obtain a revocable, 30-day client JWT without ever seeing the user's dashboard session token. - name: AuthorizedClients description: | Manage first-party clients (CLI / MCP / demo / IDE plugins) authorized to act as a dashboard user. Surfaced under Profile → Authorized Clients. - name: Kyb description: >- Verify a business's identity via AI Prise passthrough and check KYB tier status. - name: BusinessAccounts description: >- Administer the business accounts (multi-operator wallet containers) that end users create in an environment. - name: ScreeningPolicies description: | Author per-vendor address screening policies that map TRM and Chainalysis signals to block, alert, or allow, plus per-address exceptions. The sanctions floor sits underneath every policy and is not configurable. paths: /sdk/{environmentId}/businessAccounts/{businessAccountId}/roles: post: tags: - SDK summary: SDK — define a customer role for a business account description: | Defines a role that inherits a built-in one. The role lives only in the signed authorization document, so there is no separate role resource. Requires step-up authentication. operationId: sdkDefineBusinessAccountRole parameters: - $ref: '#/components/parameters/environmentId' - $ref: '#/components/parameters/businessAccountId' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/DefineBusinessAccountRoleSdkRequest' responses: '201': description: Role defined; the new document version returned content: application/json: schema: $ref: '#/components/schemas/BusinessAccountMutationVersion' '202': $ref: '#/components/responses/BusinessAccountApprovalsPending' '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/BusinessAccountForbidden' '404': $ref: '#/components/responses/NotFound' '409': $ref: '#/components/responses/Conflict' '500': $ref: '#/components/responses/InternalServerError' security: - bearerAuth: [] components: parameters: environmentId: in: path name: environmentId required: true description: ID of the environment schema: $ref: '#/components/schemas/uuid' businessAccountId: in: path name: businessAccountId required: true description: ID of the business account schema: $ref: '#/components/schemas/uuid' schemas: DefineBusinessAccountRoleSdkRequest: type: object description: > SDK defineRole body. A customer role always inherits a built-in one, which is what lets capability lookups and existing rules resolve through it. required: - inherits - role properties: role: type: string description: Lowercase letters, numbers, hyphens and underscores. inherits: type: string enum: - admin - viewer autoExecute: $ref: '#/components/schemas/BusinessAccountAutoExecute' intent: $ref: '#/components/schemas/BusinessAccountMutationIntent' intentSignature: type: string BusinessAccountMutationVersion: type: object description: The new version of the signed authorization document. required: - version properties: version: type: integer uuid: type: string pattern: ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ minLength: 36 maxLength: 36 example: 95b11417-f18f-457f-8804-68e361f9164f BusinessAccountAutoExecute: type: boolean default: true description: > Whether the change applies the moment its quorum is met, or waits for an explicit execute. Read only on the first call, where it is stamped into the intent you sign; after that the signed intent is the authority. Defaults to true, because a change holding all its consent while waiting for a button press tends to be forgotten, and the deadline covers execution too. BusinessAccountMutationIntent: type: object description: > The initiator's proposal, signed with their session key. Built by the API, not the client — sign these exact bytes verbatim, because re-serializing can change them and invalidate the signature. `autoExecute` is inside the signed bytes, so an approver consents to it and nothing can flip it afterwards. additionalProperties: true BusinessAccountApprovalsPending: type: object description: > The action is governed and has not been authorized yet. Not a refusal: the caller may perform it, they have simply not collected the consent it requires. `INTENT_REQUIRED` means nothing is signed yet — sign `intent` and resend. `APPROVALS_REQUIRED` means the intent is signed and recorded as `proposalId`, and `approvalRequirements` says what each rule still needs. One schema for both, rather than a oneOf, so a generated client has a single type to read `reason` off. required: - intent - reason properties: reason: type: string enum: - INTENT_REQUIRED - APPROVALS_REQUIRED intent: $ref: '#/components/schemas/BusinessAccountMutationIntent' message: type: string description: > Why the action did not apply, ready to show a user. A 202 carries no `error`, so a client rendering only that field would show nothing for the commonest case — executing before the approvals are in. example: >- This proposal cannot be executed yet: addMember needs 1 more approval (1 of 2). proposalId: type: string format: uuid description: > The proposal collecting approvals. Absent for `INTENT_REQUIRED` — an unsigned intent is not evidence, so no proposal is opened for one. approvalRequirements: type: array description: > Set for `APPROVALS_REQUIRED`. Every matching requirement, met or not, so a client can render progress per rule. items: $ref: '#/components/schemas/BusinessAccountApprovalRequirementStatus' BadRequest: type: object properties: error: description: Human-readable error message type: string Unauthorized: type: object properties: error: description: Human-readable error message describing the authentication failure type: string example: No jwt provided! BusinessAccountForbidden: allOf: - $ref: '#/components/schemas/Forbidden' - type: object description: > Carries the requirement tallies when the caller is authorized but consent is outstanding, which is a different thing from being refused outright. properties: approvalRequirements: type: array items: $ref: '#/components/schemas/BusinessAccountApprovalRequirementStatus' NotFound: type: object required: - error - code properties: error: description: Human-readable error message type: string example: Not Found code: description: Machine-readable error code type: string example: not_found Conflict: type: object properties: error: description: Human-readable error message type: string example: 'Conflict: invalid state transition' InternalServerError: type: object properties: error: description: Human-readable error message type: string example: Internal Server Error BusinessAccountApprovalRequirementStatus: type: object description: > One governance requirement and how close it is to being met. Every matching requirement is reported, not only the unmet ones, so a client can show per-rule progress rather than a rule appearing only once it is short. Computed inside the enclave: eligibility resolves from the signed document, so whether a given approval counts depends on roles that are not readable outside it. A client cannot derive these numbers from the approval list. required: - action - approved - required - requirementId - satisfied properties: action: type: string description: > The change type this rule governs. Requirement ids are unique per action only, so a change set spanning two actions can report the same id twice. example: addMember requirementId: type: string required: type: integer approved: type: integer description: > Approvals that COUNT toward this requirement — not the raw approval count. An approver outside the eligible pool, or one demoted since they approved, is not included. satisfied: type: boolean description: > Authoritative. `approved >= required` is not sufficient: a mandatory approver role with nobody's approval leaves this false with the count already met. unmetMandatoryRoles: type: array description: > Mandatory approver roles still lacking an approval, present only when they are what is holding the requirement back. items: type: string Forbidden: type: object properties: error: description: Human-readable error message type: string example: Access Forbidden responses: BusinessAccountApprovalsPending: description: > Governed and not yet authorized — sign the intent, or collect the approvals `approvalRequirements` names, then resend. Not a failure. content: application/json: schema: $ref: '#/components/schemas/BusinessAccountApprovalsPending' BadRequest: description: Bad Request content: application/json: schema: $ref: '#/components/schemas/BadRequest' Unauthorized: description: Unauthorized content: application/json: schema: $ref: '#/components/schemas/Unauthorized' BusinessAccountForbidden: description: > Forbidden. Carries the outstanding approval requirements when the caller is authorized but consent is incomplete. content: application/json: schema: $ref: '#/components/schemas/BusinessAccountForbidden' NotFound: description: Not Found content: application/json: schema: $ref: '#/components/schemas/NotFound' Conflict: description: Conflict content: application/json: schema: $ref: '#/components/schemas/Conflict' InternalServerError: description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/InternalServerError' securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT ````