> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dynamic.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SDK — replace the approval requirements for a business account

> Replaces the governance section wholesale, matching the enclave: a caller
sending one action's rules drops the others. Requires step-up
authentication, because governance decides what every other mutation
requires.




## OpenAPI

````yaml https://app.dynamic.xyz/api-docs/public-api.yaml put /sdk/{environmentId}/businessAccounts/{businessAccountId}/governance
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}/governance:
    put:
      tags:
        - SDK
      summary: SDK — replace the approval requirements for a business account
      description: >
        Replaces the governance section wholesale, matching the enclave: a
        caller

        sending one action's rules drops the others. Requires step-up

        authentication, because governance decides what every other mutation

        requires.
      operationId: sdkSetBusinessAccountGovernance
      parameters:
        - $ref: '#/components/parameters/environmentId'
        - $ref: '#/components/parameters/businessAccountId'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/SetBusinessAccountGovernanceSdkRequest'
      responses:
        '200':
          description: Governance replaced; 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:
    SetBusinessAccountGovernanceSdkRequest:
      type: object
      description: >
        SDK setGovernance body. Replaces the whole section, so an absent
        governance field is refused rather than read as a request to delete
        every requirement — send an empty object to clear.
      required:
        - governance
      properties:
        governance:
          $ref: '#/components/schemas/BusinessAccountGovernance'
        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
    BusinessAccountGovernance:
      type: object
      description: >
        Approval requirements keyed by governed action. Replaced wholesale, so a
        caller changing one action must send the others back unchanged.
      additionalProperties:
        type: array
        items:
          $ref: '#/components/schemas/BusinessAccountApprovalRequirement'
    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
    BusinessAccountApprovalRequirement:
      type: object
      description: >
        One approval rule. Requirements are independent constraints and all
        matching ones apply, so rule order carries no meaning. The enclave is
        authoritative and rejects any field it does not recognise.
      required:
        - id
        - requiredApprovals
        - schemaVersion
      properties:
        schemaVersion:
          type: integer
          description: Version of the requirement schema, not a revision count.
          example: 1
        id:
          type: string
          description: Stable handle, named in a denial and used to edit the rule.
        when:
          $ref: '#/components/schemas/BusinessAccountRequirementCondition'
        eligibleInitiatorRoles:
          type: array
          description: Who may propose. Absent, the capability table applies.
          items:
            type: string
        eligibleApproverRoles:
          type: array
          description: Who may approve. Absent, owners and admins.
          items:
            type: string
        mandatoryApproverRoles:
          type: array
          description: Roles that must each be represented among the approvers.
          items:
            type: string
        approverCapabilities:
          type: array
          description: Extra conditions an approver must satisfy.
          items:
            type: string
            enum:
              - signerOnTargetWallet
        requiredApprovals:
          type: integer
          description: How many approvals are needed, excluding the initiator.
        approvalWindowSeconds:
          type: integer
          description: >
            How long approvals may be collected, measured from the signed
            intent. Defaults to 24 hours and is capped at 30 days.
        executionWindowSeconds:
          type: integer
          description: >
            How long a satisfied set stays spendable, measured from the last
            approval. Absent means no execution deadline.
    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
    BusinessAccountRequirementCondition:
      type: object
      description: >
        Narrows when a requirement applies. Every field must match, and a field
        the change does not carry never matches.
      properties:
        role:
          type: string
          description: Matches the role being granted, through inheritance.
        newRole:
          type: string
          description: Matches the role being moved to, through inheritance.
        walletIds:
          type: array
          description: Matches the wallet the change targets.
          items:
            $ref: '#/components/schemas/uuid'
        targetUserIds:
          type: array
          description: Matches the user the change targets.
          items:
            $ref: '#/components/schemas/uuid'
        initiatorRoles:
          type: array
          description: Matches the role the caller holds.
          items:
            type: string
        initiatorUserIds:
          type: array
          description: Matches the caller.
          items:
            $ref: '#/components/schemas/uuid'
  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

````