CLI Reference

Global

o2idctl <command>

Command	Aliases
init
config
login
users	user
applications	application, apps, app
roles	role
agents	agent
resource-servers	resource-server, resourceservers, resourceserver
connections	connection
authenticators	authenticator
flows	flow
logs	log
export
import
help	-h, --help
version	--version

init

Guided first-time setup — walks through the same steps as config add, config use, and login in one narrated flow, for someone connecting o2idctl to an O2ID instance for the first time.

o2idctl init

Prompts:

Prompt	Default	Description
API base URL	http://localhost:8080	Base URL for an O2ID API instance
Profile name	local	Name used later with o2idctl config use <profile>
Log in now via your browser?	Y	Runs the same browser login login does

Unlike config add, init always activates the profile it creates for the current terminal session — there's no "is this your first profile?" check, since the whole point of init is setting one up. Run config add (not init again) when you want to add another profile later.

config add

Interactively creates a saved profile with an API base URL and name.

o2idctl config add

Prompts:

Prompt	Default	Description
API base URL	http://localhost:8080	Base URL for an O2ID API instance, optionally with a tenant
Profile name	local	Name used later with o2idctl config use <profile>

Press enter at either prompt to accept the default shown in brackets. If this is the first profile you've saved, it also asks whether to use it as the current terminal session's default — the same selection config use makes.

API base URL accepts a tenant appended as /t/{tenant} — http://localhost:8080 targets the system tenant (the default), while http://localhost:8080/t/acme targets acme. Every root tenant needs its own separate login — there's no shared credential across tenants, even on the same O2ID instance — so targeting a second tenant means adding a second profile with that tenant in its API base URL, the same way targeting a second instance does. See Multi-Tenancy.

config list

Lists every saved profile (name, API base URL, tenant, whether it holds credentials, and whether it's the active profile for this terminal session), along with the resolved config directory ($O2IDCTL_CONFIG_DIR, or o2id under your OS's user config directory by default).

o2idctl config list

config get

Shows one profile's details.

o2idctl config get <profile>

config update

Interactively updates a profile's API base URL (and, with it, the tenant — see config add above), defaulting to its current value.

o2idctl config update <profile>

config delete

Removes a saved profile. If the current terminal session had it selected, the selection is cleared.

o2idctl config delete <profile>

config use

Selects a saved profile for the current terminal session.

o2idctl config use <profile>

login

Logs in via the device authorization grant: prints a code and a URL, then polls until you approve it in a browser (on this device or another one) — and stores the resulting access and refresh tokens on the currently-selected profile. Every other command requires this to have been run at least once — see Using o2idctl for the full login flow and the API Reference for how roles/scopes gate each endpoint.

o2idctl login

Users

Every users command below requires the users:read, users:create, users:update, or users:delete scope, depending on the operation.

users create

Creates a new user. Which attributes are valid, and which are required, comes from the user's type — there's no fixed --email flag.

o2idctl users create [--user-type <type>] --attribute <key=value> [--attribute <key=value> ...] [--display-name <name>] [--password <password>]

Option	Required	Description
--user-type <type>	No	Key of the user type this user belongs to. Defaults to the built-in user type
--attribute <key=value>	No	An attribute value, keyed by the user type's schema. Repeatable
--display-name <name>	No	User display name
--password <password>	No	User password

users get

Fetches a single user by its internal ID.

o2idctl users get <id>

users list

Lists all users.

o2idctl users list

users update

Updates a user, addressed by its internal ID. Requires the users:update scope. --display-name and --user-type are independently optional — omit either to leave it unchanged. --attribute behaves differently: supplying any --attribute replaces the entire attribute map with just what was passed on this call, so omitted attributes are dropped rather than preserved — include every attribute you want to keep, not just the one you're changing.

o2idctl users update <id> [--display-name <name>] [--user-type <type>] [--attribute <key=value> ...]

Option	Required	Description
--display-name <name>	No	Replacement display name. Left unchanged if omitted
--user-type <type>	No	Replacement user type key. Left unchanged if omitted
--attribute <key=value>	No	An attribute value, repeatable. If passed at all, replaces the entire attribute set

users delete

Permanently deletes a user, addressed by its internal ID. Requires the users:delete scope. This cannot be undone.

o2idctl users delete <id>

users set-password

Sets a user's password, addressed by its internal ID. Requires the users:update-credentials scope.

o2idctl users set-password <id> --password <password>

Option	Required	Description
--password <password>	Yes	Replacement password. Takes effect immediately — the user's existing sessions and tokens are unaffected, but the new password is required for the next login

users authenticator-enrollments

Lists a user's authenticator enrollments.

o2idctl users authenticator-enrollments <id>

users enroll-authenticator

Creates a TOTP enrollment for a user and returns setup material (an otpauthUrl/secret to show the user in your own enrollment UI). Verifying the enrollment with a code needs the user's own authenticator app in the moment, so it isn't a CLI command — call POST /users/{id}/authenticator-enrollments/{enrollmentId}/verify directly from whatever collected the code (see the API Reference).

o2idctl users enroll-authenticator <id> --authenticator <authenticator-id>

users assign

Assigns a role to a user. Assigning a role the user already holds is a no-op. Requires the roles:assign scope.

o2idctl users assign --user <userId> --role <roleId>

Option	Required	Description
--user <userId>	Yes	Internal user ID
--role <roleId>	Yes	Internal role ID

users unassign

Removes a role from a user. Unassigning a role the user doesn't hold is a no-op. Requires the roles:assign scope.

o2idctl users unassign --user <userId> --role <roleId>

Option	Required	Description
--user <userId>	Yes	Internal user ID
--role <roleId>	Yes	Internal role ID

User Types

Every user-types command below requires the users:read, users:create, or users:update scope, depending on the operation. See User types for the full field-schema model.

user-types create

Creates a new user type.

o2idctl user-types create --key <key> --username-field <field> --field <key:type[:required][:opt1,opt2]> [--field ...]

Option	Required	Description
--key <key>	Yes	Unique key identifying this type
--username-field <field>	Yes	Name of the field O2ID resolves as the login identifier
--field <spec>	Yes	A field declaration: key:type[:required][:opt1,opt2]. type is one of string, number, bool, select, email, username. Repeatable

user-types get

Fetches a single user type by its key.

o2idctl user-types get <key>

user-types list

Lists all user types, including the built-in user type.

o2idctl user-types list

user-types update

Updates a user type's field schema, addressed by its key. --username-field can't be changed once a type is created.

o2idctl user-types update <key> --field <spec> [--field ...]

Option	Required	Description
--field <spec>	Yes	A field declaration, same syntax as create. Repeatable. If passed at all, replaces the entire schema — a call that omits the username field fails validation, so re-list every field you want to keep

user-types delete

Deletes a user type. Rejected if any user is still assigned this type; the built-in user type can never be deleted.

o2idctl user-types delete <key>

Applications

Every applications command below requires the applications:read, applications:create, applications:update, or applications:delete scope, depending on the operation.

applications create

Registers a new OAuth 2.0 client application. Confidential unless --public is passed.

o2idctl applications create --name <name> [--public] [--callback-url <url> ...] [--scope <scope> ...] [--api <resource-server-identifier> [--scope <scope> ...] ...] [--trusted] [--access-token-lifetime <duration> ...]

Option	Required	Description
--name <name>	Yes	Application name
--public	No	Creates a public client (no client secret) instead of the default confidential one
--callback-url <url>	No	OAuth redirect URI. Repeat for multiple callback URLs
--scope <scope>	No	RBAC scope this application's tokens may carry. Repeat for multiple scopes. Omit for none (deny-by-default). Only applies when it appears before any --api — shorthand for --api o2id-management-api
--api <resource-server-identifier>	No	Authorizes this application against a resource server, by its identifier (not internal ID). Repeat for multiple resource servers
--scope <scope> (after --api)	No	Scope to grant on the most recent --api. Repeat for multiple scopes on that resource server
--trusted	No	Marks the application first-party, skipping the user consent screen. Omit for third-party (consent required)
--access-token-lifetime <duration>	No	Access token lifetime override, e.g. 5m
--refresh-token-lifetime <duration>	No	Refresh token lifetime override, e.g. 720h
--authorization-code-lifetime <duration>	No	Authorization code lifetime override
--session-lifetime <duration>	No	Session lifetime override
--login-transaction-lifetime <duration>	No	Login transaction lifetime override
--consent-transaction-lifetime <duration>	No	Consent transaction lifetime override

See Application settings for the built-in defaults and how 0/inherit clears an override.

applications get

Fetches a single application by its internal ID.

o2idctl applications get <id>

applications list

Lists all registered applications.

o2idctl applications list

applications update

Updates an application's details such as name, callback URLs, etc. Any field you omit is left unchanged.

o2idctl applications update <id> [--name <name>] [--callback-url <url> ...] [--scope <scope> ...] [--regenerate-secret|--public] [--trusted|--untrusted] [--access-token-lifetime <duration>|inherit ...]

Option	Required	Description
--name <name>	No	Replacement application name
--callback-url <url>	No	Replacement OAuth redirect URI. Repeat for multiple callback URLs. Replaces the full list — a partial list isn't merged with the existing one
--scope <scope>	No	Replacement RBAC scope. Repeat for multiple scopes. Replaces the full list — a partial list isn't merged with the existing one
--regenerate-secret	No	Generates a new client secret (returned once, in the response's clientSecret field), invalidating the old one, and makes the application confidential if it wasn't already
--public	No	Clears the client secret and makes the application public
--trusted / --untrusted	No	Marks the application first-party (skips consent) or third-party (consent required)
--access-token-lifetime <duration>	No	Access token lifetime override. Pass 0 or inherit to clear
--refresh-token-lifetime <duration>	No	Refresh token lifetime override. Pass 0 or inherit to clear
--authorization-code-lifetime <duration>	No	Authorization code lifetime override. Pass 0 or inherit to clear
--session-lifetime <duration>	No	Session lifetime override. Pass 0 or inherit to clear
--login-transaction-lifetime <duration>	No	Login transaction lifetime override. Pass 0 or inherit to clear
--consent-transaction-lifetime <duration>	No	Consent transaction lifetime override. Pass 0 or inherit to clear

applications delete

Permanently deletes an application. This cannot be undone.

o2idctl applications delete <id>

applications resource-servers

Lists the resource servers an application is authorized for, and the scope subset granted on each. Requires applications:read. See Resource Servers.

o2idctl applications resource-servers <app-id>

applications authorize-resource-server

Authorizes an application to mint or introspect tokens for a resource server, granting it the given subset of that resource server's own defined scopes. Re-running this replaces any previously granted scopes for the pair, rather than merging with them. Requires applications:authorize-resource-servers.

o2idctl applications authorize-resource-server <app-id> <resource-server-identifier> [--scope <scope> ...]

Option	Required	Description
--scope <scope>	No	One of the resource server's own defined scopes to grant. Repeat for multiple scopes. Omit for none

applications deauthorize-resource-server

Removes an application's authorization for a resource server entirely. Requires applications:authorize-resource-servers.

o2idctl applications deauthorize-resource-server <app-id> <resource-server-identifier>

Roles

Every roles command below requires the roles:read, roles:create, roles:update, or roles:delete scope, depending on the operation. See Managing Roles for the role/scope model and the API Reference for the scope each endpoint requires.

roles create

Creates a role with a set of scopes.

o2idctl roles create --name <name> [--scope <scope> ...]

Option	Required	Description
--name <name>	Yes	Role name
--scope <scope>	No	Scope granted by this role. Repeat for multiple scopes

roles get

Fetches a single role by its internal ID.

o2idctl roles get <id>

roles list

Lists all roles.

o2idctl roles list

roles update

Replaces an existing role's name and/or scopes.

o2idctl roles update <id> --name <name> [--scope <scope> ...]

Option	Required	Description
--name <name>	Yes	Replacement role name
--scope <scope>	No	Replacement scope. Repeat for multiple scopes

roles delete

Permanently deletes a role. Fails if the role is still assigned to any user.

o2idctl roles delete <id>

AI Agents

Every agents command below requires the agents:read, agents:create, agents:update, or agents:delete scope, depending on the operation. See Managing AI Agents for what an AI agent is and the API Reference for the scope each endpoint requires.

agents create

Registers a new AI agent identity with a set of allowed scopes.

o2idctl agents create --name <name> [--scope <scope> ...]

Option	Required	Description
--name <name>	Yes	AI agent name
--scope <scope>	No	RBAC scope this AI agent's tokens may carry. Repeat for multiple scopes. Omit for none (deny-by-default)

agents get

Fetches a single AI agent by its internal ID.

o2idctl agents get <id>

agents list

Lists all registered AI agents.

o2idctl agents list

agents update

Updates an AI agent's name, allowed scopes, and/or registered public key. A field you omit is left unchanged.

o2idctl agents update <id> [--name <name>] [--scope <scope> ...] [--public-key <path>]

Option	Required	Description
--name <name>	No	Replacement AI agent name
--scope <scope>	No	Replacement RBAC scope. Repeat for multiple scopes. Replaces the full list — a partial list isn't merged with the existing one
--public-key <path>	No	Path to a JSON Web Key (RSA only) file. Registers the key this AI agent uses to authenticate itself via private_key_jwt, without a human present. There's currently no way to clear a registered key back to "none"

agents delete

Permanently deletes an AI agent. This cannot be undone.

o2idctl agents delete <id>

Resource Servers

Every resource-servers command below (aside from the scopes sub-group) requires the resourceservers:read, resourceservers:create, resourceservers:update, or resourceservers:delete scope, depending on the operation. See Resource Servers for what a resource server is and how an application gets authorized for one, and the API Reference for the scope each endpoint requires.

resource-servers create

Registers a new resource server (API). Its own scopes/permissions are managed separately — see resource-servers scopes below.

o2idctl resource-servers create --name <name> --identifier <identifier>

Option	Required	Description
--name <name>	Yes	Resource server name
--identifier <identifier>	Yes	The value callers pass as resource/audience to target this resource server

resource-servers get

Fetches a single resource server by its internal ID.

o2idctl resource-servers get <id>

resource-servers list

Lists all registered resource servers.

o2idctl resource-servers list

resource-servers update

Updates a resource server's name and/or identifier. A field you omit is left unchanged.

o2idctl resource-servers update <id> [--name <name>] [--identifier <identifier>]

Option	Required	Description
--name <name>	No	Replacement resource server name
--identifier <identifier>	No	Replacement identifier

resource-servers delete

Permanently deletes a resource server. This cannot be undone, and any application authorizations naming it become unreachable, since resolving the identifier is the first step in every check that consults them.

o2idctl resource-servers delete <id>

resource-servers scopes create

Defines a new scope/permission on a resource server. The value must be unique among that resource server's own scopes.

o2idctl resource-servers scopes create --resource-id <resource-id> --value <value> \
  [--display-name <name>] [--description <text>]

Option	Required	Description
--resource-id <resource-id>	Yes	The resource server this scope belongs to
--value <value>	Yes	The scope itself, granted and checked exactly as written, e.g. read:messages
--display-name <name>	No	Human-readable name. Purely descriptive
--description <text>	No	Human-readable description. Purely descriptive

o2idctl resource-servers scopes create --resource-id <resource-id> \
  --value read:messages --display-name "Read Messages" --description "Allows reading messages"

resource-servers scopes list

Lists the scopes a resource server defines.

o2idctl resource-servers scopes list --resource-id <resource-id>

resource-servers scopes get

Fetches a single scope by its own ID — no --resource-id needed, since a scope's ID is already globally unique.

o2idctl resource-servers scopes get <scope-id>

resource-servers scopes update

Updates a scope's value, display name, and/or description, addressed by its own ID alone. A field you omit is left unchanged. Renaming --value doesn't retroactively update any application authorization already granted under the old value — the same way renaming any OAuth scope string is a breaking change in any system.

o2idctl resource-servers scopes update <scope-id> [--value <value>] [--display-name <name>] [--description <text>]

Option	Required	Description
--value <value>	No	Replacement scope value. Must still be unique among its resource server's other scopes
--display-name <name>	No	Replacement display name
--description <text>	No	Replacement description

resource-servers scopes delete

Permanently deletes a scope, addressed by its own ID alone. This cannot be undone.

o2idctl resource-servers scopes delete <scope-id>

Connections

Every connections command below requires the connections:read, connections:create, connections:update, or connections:delete scope, depending on the operation. See Managing Connections for what a connection is, and the API Reference for the scope each endpoint requires.

connections types

Lists the connection types compiled into this O2ID instance, along with each one's configSchema — which fields to pass via --field when creating a connection, and which of those are secret.

o2idctl connections types

connections create

Creates a connection: a configured, credentialed instance of a connection type.

o2idctl connections create --type <type> --name <name> [--field <key>=<value> ...] [--enabled true|false]

Option	Required	Description
--type <type>	Yes	A type value from connections types
--name <name>	Yes	Connection name, unique within the tenant
--field <key>=<value>	No, repeatable	One config or secret field, per the type's configSchema. The value is parsed as JSON when possible (so --field port=8080 and --field verifyTls=true carry a number/bool, not a string), otherwise treated as a plain string
--enabled <true|false>	No	Defaults to true

connections get

Fetches a single connection by its ID. Secret field values are never included in the response — only which secret keys are set.

o2idctl connections get <id>

connections list

Lists every connection in the current tenant.

o2idctl connections list

connections update

Updates a connection's name, fields, and/or enabled state. A field you omit is left unchanged; --field values are merged key-by-key into the existing field set, so rotating one secret doesn't require resubmitting every other credential.

o2idctl connections update <id> [--name <name>] [--field <key>=<value> ...] [--enabled true|false]

connections delete

Permanently deletes a connection. This cannot be undone, and any authenticator still pointing at it via connectionId will fail to resolve.

o2idctl connections delete <id>

connections test

Runs the connection type's own live validation (e.g. an authenticated no-op call to the provider) without changing anything persisted. Always returns normally — a failed check is a normal outcome reported as {"valid": false, "error": "..."}, not a CLI error.

o2idctl connections test <id>

Authenticators

Every authenticators command below requires the authenticators:read, authenticators:create, authenticators:update, or authenticators:delete scope, depending on the operation. See Managing Authenticators for what an authenticator is, and the API Reference for the scope each endpoint requires.

authenticators list types

Lists the authenticator factor types compiled into this O2ID instance, along with each one's configSchema — which fields to pass via --field when creating an authenticator, and which of those are secret.

o2idctl authenticators list types

authenticators create

Creates an authenticator: a tenant-configured instance of a factor type.

o2idctl authenticators create --type <type> --display-name <name> [--connection-id <id>] [--field <key>=<value> ...] [--enabled true|false]

Option	Required	Description
--type <type>	Yes	A type value from authenticators list types
--display-name <name>	Yes	Authenticator display name, unique within the tenant
--connection-id <id>	No	An existing connection's ID, for delivery-based factor types (e.g. email/SMS one-time codes) that send through a connection
--field <key>=<value>	No, repeatable	One config or secret field, per the type's configSchema. Parsed as JSON when possible, otherwise a plain string — same rule as connections create --field
--enabled <true|false>	No	Defaults to true

authenticators get

Fetches a single authenticator by its ID. Secret field values are never included in the response — only which secret keys are set.

o2idctl authenticators get <id>

authenticators list

Lists every authenticator in the current tenant.

o2idctl authenticators list

authenticators update

Updates an authenticator's display name, connection, fields, and/or enabled state. A field you omit is left unchanged; --field values are merged key-by-key into the existing field set.

o2idctl authenticators update <id> [--display-name <name>] [--connection-id <id>] [--field <key>=<value> ...] [--enabled true|false]

authenticators delete

Permanently deletes an authenticator. This cannot be undone.

o2idctl authenticators delete <id>

Flows

Every flows authoring command below requires the flows:read, flows:create, flows:update, or flows:delete scope, depending on the operation. See Managing Flows for flow definition examples and Flow Definition Schema for the full node reference.

flows meta

Lists supported system triggers, supported node types, and condition context variables.

o2idctl flows meta

flows create

Creates a flow from a JSON definition file.

o2idctl flows create --name <name> --trigger <trigger> --definition-file <file> [--allowed-client <client_id> ...] [--disabled]

flows get

Fetches a single flow by ID.

o2idctl flows get <id>

flows list

Lists flows in the current tenant.

o2idctl flows list

flows update

Updates flow metadata or replaces the definition from a JSON file.

o2idctl flows update <id> [--name <name>] [--trigger <trigger>] [--definition-file <file>] [--allowed-client <client_id> ...] [--enabled|--disabled]

flows validate

Validates a flow definition — either one already stored under a flow ID, or one that hasn't been created yet.

o2idctl flows validate <id>
o2idctl flows validate --definition-file <file>
o2idctl flows validate --definition '<json>'

flows activate

Enables a flow and makes it the active flow for its trigger.

o2idctl flows activate <id>

o2idctl has no command to drive a flow run step by step — a flow run is meant to be driven by a real client (the login portal, or any app calling POST /flow-runs/POST /flow-runs/{id}/submit directly), not typed in one field at a time from a terminal. Use flows validate to check a definition before activating it, and the login portal (or your own OAuth client) to exercise it for real. See Flows.

Verifiable Credentials

Every verifiable-credentials command below requires the verifiablecredentials:read, verifiablecredentials:create, verifiablecredentials:update, or verifiablecredentials:delete scope, depending on the operation. See Managing Verifiable Credentials for what a verifiable credential is and its supported formats.

verifiable-credentials create

Defines a new verifiable credential.

o2idctl verifiable-credentials create --identifier <id> --name <name> --format <format> --signing-alg <alg> \
  [--claim <name>[:<displayName>[:<selectivelyDisclosable>]] ...] [--enabled true|false]

Option	Required	Description
--identifier <id> (alias --vct)	Yes	Verifiable credential identifier, unique per tenant — becomes the vct claim on the wire
--name <name>	Yes	Human-readable name
--format <format>	Yes	dc+sd-jwt, jwt_vc_json, or mso_mdoc (ISO 18013-5 — requires --signing-alg ES256)
--signing-alg <alg>	Yes	RS256 or ES256
--claim <spec>	No, repeatable	Three colon-separated fields in order — name[:displayName[:selectivelyDisclosable]]. Leave a field empty to skip it while still setting a later one, e.g. department::true (no display name, selectively disclosable).
--enabled <bool>	No	Defaults to true

verifiable-credentials get

Fetches a single verifiable credential by its internal ID.

o2idctl verifiable-credentials get <id>

verifiable-credentials list

Lists all verifiable credentials defined for the current tenant.

o2idctl verifiable-credentials list

verifiable-credentials update

Updates a verifiable credential. A field you omit is left unchanged.

o2idctl verifiable-credentials update <id> [--identifier <id>] [--name <name>] [--format <format>] \
  [--signing-alg <alg>] [--enabled true|false] \
  [--add-claim <name>[:<displayName>[:<selectivelyDisclosable>]] ...] \
  [--remove-claim <claimId> ...] \
  [--update-claim <claimId>:<name>[:<displayName>[:<selectivelyDisclosable>]] ...]

Unlike create's --claim, the three claim flags above edit the existing claim list one claim at a time instead of replacing it — existing claims you don't target with --remove-claim/--update-claim are left alone. All three are repeatable and combinable in one call; find a claim's ID via verifiable-credentials get <id>.

verifiable-credentials delete

Permanently deletes a verifiable credential. This cannot be undone.

o2idctl verifiable-credentials delete <id>

Verifiable Credential Offers

verifiable-credential-offers create requires the verifiablecredentialoffers:create scope. See Issuing Verifiable Credentials for the full OID4VCI pre-authorized_code flow this kicks off.

verifiable-credential-offers create

Creates a single-use OID4VCI pre-authorized_code offer for the calling user's own identity.

o2idctl verifiable-credential-offers create --verifiable-credential-id <id> [--claim <key>=<value> ...]

Option	Required	Description
--verifiable-credential-id <id>	Yes	The verifiable credential to issue
--claim <key>=<value>	No, repeatable	Must be a subset of the verifiable credential's own defined claims; parsed as JSON when valid JSON, otherwise a plain string

Prints the OID4VCI credential_offer JSON object — including the pre-authorized_code grant — for QR/deep-link display.

Config Export & Import

export requires the tenant:export scope, import the tenant:import scope. Both act on whichever tenant the selected profile targets, or O2IDCTL_TENANT for a single invocation. See Config Export & Import for what a dump contains and how references are remapped.

export

Writes the current tenant's configuration — resource servers and their scopes, roles, connections, authenticators, applications, flows and tenant settings — as one JSON document.

o2idctl export [--out dump.json] [--include-secrets [--secrets-out dump.secrets.json]]

Option	Required	Description
--out <file>	No	Write the dump here instead of stdout
--include-secrets	No	Also fetch connection/authenticator secrets, in plaintext, into a separate file
--secrets-out <file>	No	Where those secrets go; defaults to <out>.secrets.json. Requires --include-secrets

Secrets are excluded by default, so the dump is safe to commit. With --include-secrets you must give --out or --secrets-out: plaintext secrets are never written to stdout alongside the dump. Application client secrets can never be exported — only their hash is stored.

import

Re-creates an exported configuration in the current tenant, which must already exist. The whole import runs as one transaction: if anything fails, nothing is created.

o2idctl import --in dump.json [--secrets dump.secrets.json] [--on-conflict fail|skip|overwrite]

Option	Required	Description
--in <file>	Yes	The dump written by export
--secrets <file>	No	The secrets file written by export --include-secrets
--on-conflict <policy>	No	fail (default), skip, or overwrite when a resource already exists in the target

Prints per-resource-type counts and the old-to-new ID mapping, plus the client secret of every application it created (the only time those are ever shown), any connection whose credentials the dump couldn't carry, and any flow that doesn't validate yet — those are imported inactive.