Skip to main content
Project settings are the configurable knobs for an environment — modal styling, embedded wallet behavior, sign-in modes, KYC toggles, SDK feature flags. They’re addressable as a single dot-notation tree under dyn settings.
What you need: The CLI installed and authenticated, with an environment selected. See Getting started. dyn settings reads and writes the active environment — confirm it with dyn status first.

​
Discover settings

dyn settings list is the canonical discovery surface — every path with its description. Use it instead of guessing paths: 
dyn settings list                       # every available path + description
dyn settings list | grep -i embedded    # narrow to a subtree

​
Read a value

dyn settings show sdk.embeddedWallets    # read a subtree
dyn settings show design.modal.border    # read a single leaf

​
Write a value

dyn settings set performs a read-modify-write on a single leaf — it changes only the path you name and leaves the rest of the tree untouched: 
dyn settings set security.deviceRegistrationRequired false
dyn settings set sdk.embeddedWallets.automaticEmbeddedWalletCreation true
Writes apply immediately to the active environment. On live, that affects real users. Confirm with dyn status, and test on sandbox first.

​
Collections live outside the settings tree

The settings tree holds scalar and object configuration. Collections — lists of records you add, remove, or toggle — are managed through their own resource commands, not dyn settings. Each resource is a command group with its own actions: 
dyn providers list        # login, messaging, and integration providers
dyn exchanges list        # exchange integrations
dyn custom-networks list  # organization-defined EVM networks
So to change a login provider you reach for dyn providers …, not settings.providers. The actions a resource supports vary by what the API allows — run dyn <resource> --help to see them:
  • dyn providers — full lifecycle: create, get, update, delete, plus enable / disable.
  • dyn exchanges — create, get, delete, and enable / disable. There is no in-place update; change an exchange by toggling it or recreating it.
  • dyn custom-networks — create, get, update, delete. These are defined at the organization level, so they are shared across the org’s environments rather than scoped to a single environment.
Most environment-scoped collections are also managed declaratively by config as code: dyn export / dyn apply reconcile providers, webhooks, allowlists, gates, origins, and deeplink URLs alongside the settings tree. Use the per-resource commands for a quick one-off change; use config as code to review and apply many at once. Exchanges and custom networks are not reconciled — manage them with their own commands.

​
Single setting vs. config as code

  • dyn settings set — change one leaf, read-modify-write. Best for a quick, targeted change.
  • dyn apply -f file.yaml — reconcile many fields at once from a file. The reconciler deep-merges your partial YAML onto the current state before applying. Best for multi-field changes and config you want to review in git.