Skip to content
Akedly
Command reference

TOTP

Akedly CLI command reference: TOTP.

totp users list

Inspect existing TOTP enrollments and their verified/active status without exposing enrollment secrets.

When to use

  • Confirm whether an identifier has an existing verified enrollment, or get the totpID for status/deletion actions.

How it works

  1. Login-authenticated owner-scoped read returns the full newest-first list, unpaged and unfiltered.

Prerequisites

  • A CLI Login with totp:read. Existing TOTP enrollments may be managed here, but the CLI has no TOTP enrollment-create action.

Expected outcome

Each public row includes identifier, verified, status, pipeline binding, verification counters and dates; secret/QR setup material is omitted.

Next steps

  • Use request-auth only for an Active verified enrollment; use set-status to reactivate verified users.

Usage

sh
akedly totp users list

Inspect this command offline before preparing an operation:

sh
akedly describe "totp users list" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:read.

Server request: GET /totp/list/:userID.

Owner parameters resolved from the CLI Login: userID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

List your TOTP users and enrollment metadata without enrollment secrets. The authenticated account owner is resolved automatically; no owner id is accepted. The server returns the full unpaged, unfiltered list, newest first. Read-only logins are supported.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Inspect existing TOTP enrollments and their verified/active status without exposing enrollment secrets.

sh
akedly totp users list

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "totpID": "65a1b2c3d4e5f67890123456",
      "identifier": "person@example.invalid",
      "verified": true,
      "status": "Active",
      "pipelineID": "65a1b2c3d4e5f67890123457",
      "lastVerificationAt": "2026-10-29T12:00:00.000Z",
      "verificationCount": 2,
      "createdAt": "2026-10-29T12:00:00.000Z"
    }
  ]
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp users list

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.

totp history list

Review retained TOTP authentication requests and their stored lifecycle/billing reconciliation state.

When to use

  • Find the request UUID, expiry, billing outcome, or Mongo row ID needed to inspect one retained request.

How it works

  1. Login-authenticated owner-scoped read returns all retained rows newest first; it does not reconcile status and is not permanent history.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Rows contain Mongo _id plus distinct UUID requestID, state, billing, expiration and optional enrollment/pipeline summaries.

Next steps

  • For one retained row use its _id (not requestID) with totp history get. Deletion blockers depend on stored status/reconciliation, not computed isExpired alone.

Usage

sh
akedly totp history list

Inspect this command offline before preparing an operation:

sh
akedly describe "totp history list" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:read.

Server request: GET /totp/history/:userID.

Owner parameters resolved from the CLI Login: userID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Read your TOTP verification history. The authenticated account owner is resolved automatically; no owner id is accepted. The server returns every retained request unpaged and unfiltered, newest first. Settled requests are deleted after a short retention period, so this is a recent window, not a permanent record. Use each row's _id with akedly totp history get; requestID is a different UUID. Dates and computed isExpired pass through unchanged; this read does not reconcile request status. Read-only logins are supported.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Review retained TOTP authentication requests and their stored lifecycle/billing reconciliation state.

sh
akedly totp history list

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "_id": "65a1b2c3d4e5f67890123456",
      "requestID": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
      "identifier": "person@example.invalid",
      "status": "Pending",
      "verified": false,
      "billingAmount": 0,
      "billed": false,
      "createdAt": "2026-10-29T12:00:00.000Z",
      "verificationDate": null,
      "expirationDate": "2026-10-29T12:05:00.000Z",
      "totpUser": null,
      "pipeline": null,
      "verificationTimeSeconds": null,
      "isExpired": false
    },
    {
      "_id": "65a1b2c3d4e5f67890123457",
      "requestID": "e7ce2fd0-0209-41de-9c66-4bb7e524528a",
      "identifier": "person@example.invalid",
      "status": "Verified",
      "verified": true,
      "billingAmount": 0.375,
      "billed": true,
      "createdAt": "2026-10-29T12:00:00.000Z",
      "verificationDate": "2026-10-29T12:00:42.000Z",
      "expirationDate": "2026-10-29T12:05:00.000Z",
      "totpUser": {
        "identifier": "person@example.invalid",
        "verified": true,
        "status": "Active",
        "verificationCount": 3,
        "lastVerificationAt": "2026-10-29T12:00:42.000Z"
      },
      "pipeline": {
        "name": "Example TOTP",
        "type": "Test",
        "active": true
      },
      "verificationTimeSeconds": 42,
      "isExpired": false
    }
  ],
  "message": "TOTP verification history fetched successfully"
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp history list

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

isExpired is a computed read-time property; it does not change stored status or settle billing. Settled history is retained only for a limited period.

Rows may have null or populated TOTP-user/pipeline summaries; verificationDate and verification duration are null while pending, and billingAmount is numeric (including fractional currency amounts).

Common error guidance.

totp history get

Inspect one retained TOTP auth request with its enrollment, pipeline and company context.

When to use

  • Use the 24-hex Mongo _id from totp history list when diagnosing a request; UUID requestID is a separate verification identifier.

How it works

  1. Authenticated owner-scoped GET fetches the row by _id; deleted/expired-retained-away or foreign IDs return not found.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns one formatted history record including company, current populated enrollment/pipeline summaries and computed isExpired.

Next steps

  • If deleted by retention, use available account aggregates/support records; this endpoint does not restore history.

Usage

sh
akedly totp history get <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp history get" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the _id from akedly totp history list.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:read.

Server request: GET /totp/auth-request/:userID/:authRequestID.

Owner parameters resolved from the CLI Login: userID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Read an owned TOTP authentication request using its 24-hex Mongo _id from akedly totp history list, not its UUID requestID. The authenticated account owner is resolved automatically; no owner id is accepted. Dates and computed isExpired pass through unchanged; this read does not reconcile request status. An id that belongs to another account or was removed by retention returns 404. Read-only logins are supported.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Inspect one retained TOTP auth request with its enrollment, pipeline and company context.

sh
akedly totp history get 65a1b2c3d4e5f67890123456

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "_id": "65a1b2c3d4e5f67890123457",
    "requestID": "e7ce2fd0-0209-41de-9c66-4bb7e524528a",
    "identifier": "person@example.invalid",
    "status": "Verified",
    "verified": true,
    "billingAmount": 0.375,
    "billed": true,
    "createdAt": "2026-10-29T12:00:00.000Z",
    "verificationDate": "2026-10-29T12:00:42.000Z",
    "expirationDate": "2026-10-29T12:05:00.000Z",
    "totpUser": {
      "identifier": "person@example.invalid",
      "verified": true,
      "status": "Active",
      "verificationCount": 3,
      "lastVerificationAt": "2026-10-29T12:00:42.000Z"
    },
    "pipeline": {
      "name": "Example TOTP",
      "type": "Test",
      "active": true
    },
    "verificationTimeSeconds": 42,
    "isExpired": false,
    "company": {
      "name": "Synthetic Company",
      "logo": "https://example.invalid/logo.png"
    }
  },
  "message": "TOTP authentication request fetched successfully"
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp history get <id>

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

isExpired is a computed read-time property; it does not change stored status or settle billing. Settled history is retained only for a limited period.

Populated enrollment and pipeline can be objects or null; company may also be null. Pending/unverified records may omit verificationDate or have it null; billingAmount may be fractional.

Common error guidance.

totp analytics

Read high-level TOTP enrollment and verification aggregates for your account.

When to use

  • Use for a quick current summary, not as a complete permanent monthly audit.

How it works

  1. Login-authenticated read counts current users and verification counters; monthly count uses retained Verified requests created this server-local month.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns five numeric aggregates; active counts can include unfinished enrollments, and monthly can undercount after history retention.

Next steps

  • Use users list to separate verified from unfinished enrollments and history list for retained request details.

Usage

sh
akedly totp analytics

Inspect this command offline before preparing an operation:

sh
akedly describe "totp analytics" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:read.

Server request: GET /totp/analytics/:userID.

Owner parameters resolved from the CLI Login: userID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Read your TOTP user and verification aggregates. The authenticated account owner is resolved automatically; no owner id is accepted. totalTotpUsers includes unfinished enrollments; activeTotpUsers counts status Active, which also includes unfinished enrollments (check verified in akedly totp users list); totalVerifications sums your current users' verification counters; averageVerificationsPerUser is totalVerifications divided by totalTotpUsers, rounded to two decimals. monthlyVerifications counts retained Verified requests created in the server's current local month, so it can be lower than the month's true total once settled requests are deleted. There are no date filters. Read-only logins are supported.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Read high-level TOTP enrollment and verification aggregates for your account.

sh
akedly totp analytics

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "totalTotpUsers": 3,
    "activeTotpUsers": 2,
    "totalVerifications": 2,
    "monthlyVerifications": 1,
    "averageVerificationsPerUser": 0.67
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp analytics

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

monthlyVerifications counts retained Verified requests for the server-local month and can undercount settled requests removed by retention.

Common error guidance.

totp pipelines list

Inspect your separate TOTP hosted-flow pipelines and their callback settings.

When to use

  • Before creating/updating a pipeline, selecting a pipeline for an auth request, or checking a binding.

How it works

  1. Owner-scoped login GET returns the full unpaged newest-first pipeline records, including callback metadata.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns raw pipeline metadata with Mongo _id, type, active state and callback settings; no enrollment token is minted.

Next steps

  • Use _id with pipeline update/delete or request-auth --pipeline-id.

Usage

sh
akedly totp pipelines list

Inspect this command offline before preparing an operation:

sh
akedly describe "totp pipelines list" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:read.

Server request: GET /totp/pipelines/:userID.

Owner parameters resolved from the CLI Login: userID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

List the signed-in owner's TOTP pipelines, separate from OTP delivery pipelines. The server returns the full unpaged, unfiltered list, newest first, with raw pipeline metadata and callback fields. No setup token is minted. Read-only logins are supported.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Inspect your separate TOTP hosted-flow pipelines and their callback settings.

sh
akedly totp pipelines list

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "_id": "65a1b2c3d4e5f67890123457",
      "userID": "65a1b2c3d4e5f67890123458",
      "uid": "e7ce2fd0-0209-41de-9c66-4bb7e524528a",
      "name": "Example TOTP",
      "frontendCallbackURL": "https://example.invalid/totp",
      "type": "Test",
      "active": true,
      "createdAt": "2026-10-29T12:00:00.000Z",
      "description": "Synthetic fixture",
      "backendCallbackURL": "https://example.invalid/totp-hook",
      "mobileRedirectURL": "",
      "customScheme": "",
      "updatedAt": "2026-10-29T12:00:00.000Z"
    }
  ]
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp pipelines list

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.

totp pipelines create

Create a TOTP pipeline configuration for hosted TOTP enrollment/authentication; it is not an OTP delivery pipeline.

When to use

  • When configuring TOTP callback destinations and environment before using hosted setup.

How it works

  1. Login-authenticated POST automatically assigns the account owner; requires name and, by default, a frontend or mobile callback; validates URL/deep-link schemes.

Prerequisites

  • A writable CLI Login with totp:create. This creates only a TOTP pipeline configuration; this CLI does not expose enrollment creation.

Expected outcome

Returns the created pipeline including its new _id, default Test type and active state. No enrollment, message, or charge occurs.

Next steps

  • Inspect with totp pipelines list, then configure the hosted flow in your app.

Usage

sh
akedly totp pipelines create

Inspect this command offline before preparing an operation:

sh
akedly describe "totp pipelines create" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--nametext—yesCommand-specific option; see the full command details below. Manifest body field: name.
--descriptiontext—noCommand-specific option; see the full command details below. Manifest body field: description.
--redirect-urltext—noCommand-specific option; see the full command details below. Manifest body field: frontendCallbackURL.
--webhook-urltext—noCommand-specific option; see the full command details below. Manifest body field: backendCallbackURL.
--mobile-redirect-urltext—noCommand-specific option; see the full command details below. Manifest body field: mobileRedirectURL.
--custom-schemetext—noCommand-specific option; see the full command details below. Manifest body field: customScheme.
--environmentenumlive | testnoCommand-specific option; see the full command details below. Manifest body field: type.
--statusenumactive | inactivenoCommand-specific option; see the full command details below. Manifest body field: active.
--dry-runboolean switch—noPreview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—noShow offline command help.
--outputenumjson | humannoSelect JSON or human output.
--fieldsdot-paths—noSelect comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:create.

Server request: POST /totp/pipelines.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

write: Non-idempotent writes are not automatically retried. guarded-write: when an update carries the revision read from the server, its write is not automatically retried after network errors or HTTP 429/502/503/504. It may already be saved; inspect the resource before rerunning. A rerun reads current settings again. The explicit CLI_RATE_LIMITED refusal exception below still applies. recommendation-read: the recommendation request made while planning --recommended-limits is not automatically retried after network errors or HTTP 429/502/503/504. If planning fails, no update is sent; rerun the command to request a new recommendation. The explicit CLI_RATE_LIMITED refusal exception below still applies. This label does not change the retry policy of the standalone rate-recommendations command.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Create a TOTP pipeline with required --name, separate from OTP delivery pipelines. The authenticated owner is injected automatically. --environment is live|test (server default test); --status is active|inactive (default active; an explicit inactive is kept). Results show Live or Test and an active field. Optional description and callback/scheme fields are strings; none clears an optional text field. By default, the server requires a frontend or mobile callback; nonempty frontend/backend callbacks must be absolute HTTP(S) URLs, mobile redirects must be absolute URLs with a permitted scheme, and customScheme must be a bare permitted scheme starting with a letter and using letters, digits, +, . or -. Existing dashboard-rule modes and admin exceptions apply to these shape checks. New or changed restricted URL schemes and reserved customScheme words are refused regardless of rule mode or admin status. No enrollment, message or charge is created. An ambiguous network or server failure is not retried; run akedly totp pipelines list before retrying. Read-only logins are refused. --dry-run checks the flags locally and prints the body without credentials or requests; the server applies the URL and scheme rules only on the real call. An inactive pipeline's hosted setup page is refused; existing verified users can still request authentication.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Create a TOTP pipeline configuration for hosted TOTP enrollment/authentication; it is not an OTP delivery pipeline.

sh
akedly totp pipelines create --name 'Example TOTP' --redirect-url https://example.invalid/totp --environment test

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP pipeline created successfully",
  "data": {
    "_id": "65a1b2c3d4e5f67890123457",
    "userID": "65a1b2c3d4e5f67890123458",
    "uid": "e7ce2fd0-0209-41de-9c66-4bb7e524528a",
    "name": "Example TOTP",
    "frontendCallbackURL": "https://example.invalid/totp",
    "type": "Test",
    "active": true,
    "createdAt": "2026-10-29T12:00:00.000Z"
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp pipelines create --name Example --redirect-url https://example.invalid/totp --environment live

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Model-optional description, callback/scheme fields and updatedAt are omitted when not stored; do not assume blank strings or updatedAt exist. The CLI does not create a TOTP enrollment.

Own recovery guidance

CodeHint
TOTP_CALLBACK_REQUIREDSupply --redirect-url <http(s) URL> or --mobile-redirect-url <deep link> with akedly totp pipelines create or update.
TOTP_CALLBACK_URL_INVALIDUse an absolute http(s) URL for --redirect-url or --webhook-url. Restricted schemes such as javascript:, data:, file:, ftp:, ws: and intent: are always refused.
TOTP_MOBILE_REDIRECT_INVALIDUse an absolute http(s) URL or an allowed app deep link such as myapp://path for --mobile-redirect-url. Reserved schemes such as javascript:, data:, ftp:, intent:, about:, tel: and ms-* are refused.
TOTP_CUSTOM_SCHEME_INVALIDUse a bare --custom-scheme starting with a letter and containing only letters, numbers, +, . or -, such as myapp. Choose a non-reserved app scheme; reserved words such as javascript, data, ftp, intent, about, tel and ms-* are refused.

Common error guidance.

totp pipelines update

Change selected settings on an owned TOTP pipeline while preserving omitted fields.

When to use

  • When an existing pipeline needs callback, environment, status, or descriptive settings changed.

How it works

  1. PUT to the 24-hex pipeline _id; at least one editable field is required. Use none to clear optional callback/scheme/description fields; callback policy is checked when relevant settings change.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns the updated full pipeline and updatedAt; this does not enroll a user or send/charge.

Next steps

  • Check totp pipelines list and confirm hosted callbacks before using the pipeline.

Usage

sh
akedly totp pipelines update <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp pipelines update" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the _id from akedly totp pipelines list.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--nametext—Command-specific option; see the full command details below. Manifest body field: name.
--descriptiontext—Command-specific option; see the full command details below. Manifest body field: description.
--redirect-urltext—Command-specific option; see the full command details below. Manifest body field: frontendCallbackURL.
--webhook-urltext—Command-specific option; see the full command details below. Manifest body field: backendCallbackURL.
--mobile-redirect-urltext—Command-specific option; see the full command details below. Manifest body field: mobileRedirectURL.
--custom-schemetext—Command-specific option; see the full command details below. Manifest body field: customScheme.
--environmentenumlive | testCommand-specific option; see the full command details below. Manifest body field: type.
--statusenumactive | inactiveCommand-specific option; see the full command details below. Manifest body field: active.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:update.

Server request: PUT /totp/pipelines/:pipelineID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Update an owned TOTP pipeline using its 24-hex _id from akedly totp pipelines list. Supply at least one editable field; omitted fields are preserved. Use none to clear description or a callback/scheme field; name must be nonempty. --environment is live|test and --status is active|inactive; results show Live or Test and an active field. By default, the server requires a frontend or mobile callback; nonempty frontend/backend callbacks must be absolute HTTP(S) URLs, mobile redirects must be absolute URLs with a permitted scheme, and customScheme must be a bare permitted scheme starting with a letter and using letters, digits, +, . or -. Existing dashboard-rule modes and admin exceptions apply to these shape checks. New or changed restricted URL schemes and reserved customScheme words are refused regardless of rule mode or admin status. Callback rules evaluate stored values merged with the patch only when a callback/scheme field changes; unrelated or unchanged legacy saves remain valid. updatedAt can advance on repeated updates. No enrollment, message or charge is created. Read-only logins are refused. --dry-run checks the flags locally and prints the patch without credentials or requests; the server applies the URL and scheme rules only on the real call. An inactive pipeline's hosted setup page is refused; existing verified users can still request authentication.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Change selected settings on an owned TOTP pipeline while preserving omitted fields.

sh
akedly totp pipelines update 65a1b2c3d4e5f67890123457 --status inactive

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP pipeline updated successfully",
  "data": {
    "_id": "65a1b2c3d4e5f67890123457",
    "userID": "65a1b2c3d4e5f67890123458",
    "uid": "e7ce2fd0-0209-41de-9c66-4bb7e524528a",
    "name": "Example TOTP",
    "frontendCallbackURL": "https://example.invalid/totp",
    "type": "Test",
    "active": false,
    "createdAt": "2026-10-29T12:00:00.000Z",
    "description": "Synthetic fixture",
    "backendCallbackURL": "https://example.invalid/totp-hook",
    "mobileRedirectURL": "",
    "customScheme": "",
    "updatedAt": "2026-10-29T12:01:00.000Z"
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp pipelines update <id> --status inactive

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Own recovery guidance

CodeHint
TOTP_CALLBACK_REQUIREDSupply --redirect-url <http(s) URL> or --mobile-redirect-url <deep link> with akedly totp pipelines create or update.
TOTP_CALLBACK_URL_INVALIDUse an absolute http(s) URL for --redirect-url or --webhook-url. Restricted schemes such as javascript:, data:, file:, ftp:, ws: and intent: are always refused.
TOTP_MOBILE_REDIRECT_INVALIDUse an absolute http(s) URL or an allowed app deep link such as myapp://path for --mobile-redirect-url. Reserved schemes such as javascript:, data:, ftp:, intent:, about:, tel: and ms-* are refused.
TOTP_CUSTOM_SCHEME_INVALIDUse a bare --custom-scheme starting with a letter and containing only letters, numbers, +, . or -, such as myapp. Choose a non-reserved app scheme; reserved words such as javascript, data, ftp, intent, about, tel and ms-* are refused.

Common error guidance.

totp pipelines delete

Remove an owned TOTP pipeline configuration and stop hosted setup links for it.

When to use

  • Only when the pipeline should no longer be offered and its impact on bound users is understood.

How it works

  1. Confirmed login-authenticated DELETE hard-deletes the pipeline. Bound TOTP users and authentication requests are retained; verified users may still request auth after the bound pipeline is deleted.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns deleted pipeline id and name. No send or charge occurs.

Next steps

  • Inspect users and pipeline lists; a deleted bound ID may remain on enrollment and key scope may affect later requests.

Usage

sh
akedly totp pipelines delete <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp pipelines delete" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the _id from akedly totp pipelines list.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--yesboolean switch—Confirm this action where consent is required.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:delete.

Server request: DELETE /totp/pipelines/:pipelineID.

Shared server-guard guidance.

Consent

--yes. --dry-run bypasses confirmation where supported. Destructive: true. Spends money: false. Real send: false.

Retry

write: Non-idempotent writes are not automatically retried. guarded-write: when an update carries the revision read from the server, its write is not automatically retried after network errors or HTTP 429/502/503/504. It may already be saved; inspect the resource before rerunning. A rerun reads current settings again. The explicit CLI_RATE_LIMITED refusal exception below still applies. recommendation-read: the recommendation request made while planning --recommended-limits is not automatically retried after network errors or HTTP 429/502/503/504. If planning fails, no update is sent; rerun the command to request a new recommendation. The explicit CLI_RATE_LIMITED refusal exception below still applies. This label does not change the retry policy of the standalone rate-recommendations command.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Hard-delete an owned TOTP pipeline with --yes, using its 24-hex _id from akedly totp pipelines list. Only the pipeline is deleted: bound TOTP users and authentication requests are not deleted, and existing verified users can still request authentication after their bound pipeline is removed. No message or charge is created. An ambiguous network or server failure is not retried; run akedly totp pipelines list before retrying. Read-only logins are refused. --dry-run prints the request without credentials, consent or requests. Hosted setup links for the deleted pipeline stop working.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Remove an owned TOTP pipeline configuration and stop hosted setup links for it.

sh
akedly totp pipelines delete 65a1b2c3d4e5f67890123457 --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP pipeline deleted successfully",
  "data": {
    "deletedPipeline": {
      "id": "65a1b2c3d4e5f67890123457",
      "name": "Example TOTP"
    }
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp pipelines delete <id> --yes

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.

totp users request-auth

Open a pending TOTP authentication request for an existing verified enrollment.

When to use

  • When a verified Active user needs a fresh auth challenge. CLI enrollment creation and TOTP verification are not available.

How it works

  1. Login-authenticated POST preserves identifier spelling, infers bound pipeline unless overridden consistently, and records a separate expiring request; it sends nothing and charges only if later verified. Requires account/subscription/quota/key admission.

Prerequisites

  • A writable CLI Login with totp:create, active account/current subscription/admission quota, a usable scoped server-selected API key, and an existing Active, verified enrollment. The CLI does not create enrollments or verify a TOTP code.

Expected outcome

Returns authRequestID UUID and expiresAt. Ambiguous failures may have created a request; each retry can create another request and eventual independent charge.

Next steps

  • Inspect history, match requestID, then use row _id for history get. Verification is through the documented TOTP API, not this CLI.

Usage

sh
akedly totp users request-auth

Inspect this command offline before preparing an operation:

sh
akedly describe "totp users request-auth" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--identifiertext—yesCommand-specific option; see the full command details below. Manifest body field: identifier.
--pipeline-idid—noCommand-specific option; see the full command details below. Manifest body field: pipelineID.
--dry-runboolean switch—noPreview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—noShow offline command help.
--outputenumjson | humannoSelect JSON or human output.
--fieldsdot-paths—noSelect comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:create.

Server request: POST /totp/dashboard/request-auth.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

write: Non-idempotent writes are not automatically retried. guarded-write: when an update carries the revision read from the server, its write is not automatically retried after network errors or HTTP 429/502/503/504. It may already be saved; inspect the resource before rerunning. A rerun reads current settings again. The explicit CLI_RATE_LIMITED refusal exception below still applies. recommendation-read: the recommendation request made while planning --recommended-limits is not automatically retried after network errors or HTTP 429/502/503/504. If planning fails, no update is sent; rerun the command to request a new recommendation. The explicit CLI_RATE_LIMITED refusal exception below still applies. This label does not change the retry policy of the standalone rate-recommendations command.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Open a pending authentication request for an Active verified TOTP enrollment using --identifier and optional --pipeline-id. Identifier spelling and case are preserved; omission infers the enrollment's pipeline. An active, verified account, current subscription, sufficient quota for admission and a usable server-selected account API key with matching scope are required. An Active verified enrollment's existing pipeline binding decides where the request is recorded: --pipeline-id must match the enrollment's bound id when one is stored, even if that pipeline was deleted. Using that same bound id after deletion is still allowed, with the request recorded without a pipeline. An explicit well-formed --pipeline-id that does not exist is refused with TOTP_PIPELINE_NOT_FOUND for an unbound enrollment, or when no Active verified enrollment matches the identifier, or TOTP_PIPELINE_BINDING_MISMATCH if it differs from a bound id; check the enrollment's bound pipelineID in akedly totp users list. A recorded request's pipeline (name, type, active) in akedly totp history list is null when it was recorded with no pipeline or under a deleted one. An unbound enrollment can use an existing owned explicit pipeline. The server-selected key must cover the target pipeline when scope enforcement is on; a selected-scope key that cannot cover it can cause NO_USABLE_API_KEY or API_KEY_SCOPE_DENIED, while shadow mode can allow scope fallback. Verified users stay usable after their bound pipeline is deactivated with a key covering that pipeline; after it is deleted, opening requests requires an all-pipelines key when scope enforcement is enabled. Invalid and foreign pipeline ids are still refused. When other pipeline and admission checks pass, an unverified, Inactive or Suspended enrollment returns 'TOTP user not found or not verified'; check verified and status in akedly totp users list. For a verified enrollment intentionally made Inactive or Suspended, reactivate with akedly totp users set-status <totpID> --status active; setting active does not verify an unfinished setup. This command sends nothing to the identifier, charges nothing now and needs no --yes; later verification can bill. Each call creates a separate request with no safe replay. Returned authRequestID is the UUID requestID: run akedly totp history list, match requestID, then use the row's Mongo _id with akedly totp history get <id>. Verification uses the documented TOTP verify-auth API (POST /api/v1/totp/verify-auth/<authRequestID> with the current code in the token field) before expiresAt; use the UUID authRequestID, not the history _id. The CLI has no verification command. A coded TOTP_AUTH_REQUEST_RATE_LIMITED refusal keeps its cooldown and is not retried; wait for the reported cooldown before retrying. An ambiguous failure may follow creation, so inspect history before opening another. Read-only logins are refused. --dry-run validates offline and sends nothing.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Open a pending TOTP authentication request for an existing verified enrollment.

sh
akedly totp users request-auth --identifier person@example.invalid

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP authentication requested",
  "data": {
    "authRequestID": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
    "expiresAt": "2026-10-29T12:05:00.000Z"
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp users request-auth --identifier <identifier>

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

authRequestID is the UUID requestID; history get takes the separate 24-hex Mongo _id. Verification is not exposed by this CLI.

Own recovery guidance

CodeHint
API_KEY_INDEX_UNAVAILABLEAPI-key credential indexes are unavailable; ask Akedly support to restore them before retrying. No authentication request was created by this refusal.
TOTP_PIPELINE_ID_INVALIDUse the 24-hex _id from akedly totp pipelines list with --pipeline-id.
TOTP_PIPELINE_NOT_FOUNDThe requested TOTP pipeline was not found. If no Active verified enrollment matches this identifier, check the identifier and the pipeline; otherwise omit --pipeline-id to use the enrollment's own binding (or none when it is unbound), or use an existing owned pipeline. Inspect akedly totp users list and akedly totp pipelines list.
TOTP_PIPELINE_OWNERSHIP_MISMATCHRun akedly totp pipelines list and choose a pipeline owned by this account.
TOTP_PIPELINE_INACTIVEThe requested pipeline is inactive and no Active verified enrollment was found. Inspect akedly totp users list; activating a pipeline does not verify an enrollment.
TOTP_PIPELINE_BINDING_MISMATCHInspect the enrollment with akedly totp users list and use its bound TOTP pipeline, or omit --pipeline-id to infer it.
TOTP_AUTH_REQUEST_RATE_LIMIT_UNAVAILABLEThe TOTP request limiter is unavailable. Ask Akedly support to restore it before retrying; no authentication request was created by this refusal.
TOTP_AUTH_REQUEST_RATE_LIMIT_RECOVERY_REQUIREDThe TOTP request limiter needs recovery. Ask Akedly support before retrying; no authentication request was created by this refusal.

Common error guidance.

totp users set-status

Enable, disable or suspend an existing TOTP enrollment without deleting it.

When to use

  • Stop new authentication requests temporarily, or re-enable a previously verified enrollment.

How it works

  1. Authenticated PATCH by totpID changes only status. Active does not make an unfinished setup verified; existing requests remain open and can still be verified/billed.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Returns the updated public enrollment row. No message or charge occurs.

Next steps

  • Recheck verified and status with totp users list.

Usage

sh
akedly totp users set-status <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp users set-status" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the totpID from akedly totp users list.

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--statusenumactive | inactive | suspendedyesCommand-specific option; see the full command details below. Manifest body field: status.
--dry-runboolean switch—noPreview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—noShow offline command help.
--outputenumjson | humannoSelect JSON or human output.
--fieldsdot-paths—noSelect comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:update.

Server request: PATCH /totp/status/:totpID.

Shared server-guard guidance.

Consent

none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.

Retry

idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Set an owned TOTP user's status with --status active, inactive or suspended (results show Active, Inactive or Suspended) using its 24-hex totpID from akedly totp users list. Only status changes: Active does not verify an unfinished enrollment; Inactive and Suspended prevent new authentication requests while preserving the record and history. Requests already open stay verifiable, and billable on success, until they expire about five minutes after creation; a status change does not cancel them. No message or charge occurs and no --yes is required. Repeating the same status has the same effect. Inspect akedly totp users list afterwards. Read-only logins are refused. --dry-run sends nothing.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Enable, disable or suspend an existing TOTP enrollment without deleting it.

sh
akedly totp users set-status 65a1b2c3d4e5f67890123456 --status inactive

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP user status updated successfully",
  "data": {
    "totpID": "65a1b2c3d4e5f67890123456",
    "identifier": "person@example.invalid",
    "verified": true,
    "status": "Inactive",
    "pipelineID": "65a1b2c3d4e5f67890123457",
    "lastVerificationAt": "2026-10-29T12:00:00.000Z",
    "verificationCount": 2,
    "createdAt": "2026-10-29T12:00:00.000Z"
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp users set-status <id> --status active

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.

totp users delete

Permanently remove a TOTP enrollment and linked auth-request history.

When to use

  • When an enrollment and its history should be erased and requests are settled/reconciled.

How it works

  1. Confirmed login-authenticated DELETE; any linked Pending or unresolved Failed requests can block with reconciliation-pending. User and history cleanup are separate writes and a failed response may follow partial completion.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Success identifies deleted user; no message or charge occurs. Hosted QR images are not removed.

Next steps

  • Inspect users and history before retrying; resolve reconciliation blockers or contact support.

Usage

sh
akedly totp users delete <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp users delete" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the totpID from akedly totp users list.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--yesboolean switch—Confirm this action where consent is required.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:delete.

Server request: DELETE /totp/dashboard/delete/:totpID.

Shared server-guard guidance.

Consent

--yes. --dry-run bypasses confirmation where supported. Destructive: true. Spends money: false. Real send: false.

Retry

write: Non-idempotent writes are not automatically retried. guarded-write: when an update carries the revision read from the server, its write is not automatically retried after network errors or HTTP 429/502/503/504. It may already be saved; inspect the resource before rerunning. A rerun reads current settings again. The explicit CLI_RATE_LIMITED refusal exception below still applies. recommendation-read: the recommendation request made while planning --recommended-limits is not automatically retried after network errors or HTTP 429/502/503/504. If planning fails, no update is sent; rerun the command to request a new recommendation. The explicit CLI_RATE_LIMITED refusal exception below still applies. This label does not change the retry policy of the standalone rate-recommendations command.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Permanently delete an owned TOTP user and its linked authentication-request history using the 24-hex totpID from akedly totp users list; requires --yes. This cannot be undone. No message or charge occurs. TOTP_DELETE_RECONCILIATION_PENDING (409) blocks deletion when any linked request is not Expired or fully reconciled Verified/billed with a cleared or compensated verification counter; any Pending request blocks, including one just opened; Failed requests can block too. Ordinary unverified, unbilled requests expire about five minutes after creation and normally become Expired on the next five-minute reconciliation run, within about ten minutes of creation; job delays or billing/counter recovery can extend that wait. Check the stored status in akedly totp history list; computed isExpired alone does not unblock deletion. Ask Akedly support if a request stays Pending or Failed beyond that normal window, or is Verified and still blocks. Deletion and history cleanup are separate writes, so a failed response can follow partial completion; inspect users and history before retrying. Hosted QR images are not removed. Read-only logins are refused. --dry-run sends nothing.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Permanently remove a TOTP enrollment and linked auth-request history.

sh
akedly totp users delete 65a1b2c3d4e5f67890123456 --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP user deleted successfully",
  "data": {
    "deletedTotpUser": {
      "id": "65a1b2c3d4e5f67890123456",
      "identifier": "person@example.invalid"
    }
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp users delete <id> --yes

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.

totp users setup-delete

Remove only an unfinished unverified TOTP setup and its linked request history.

When to use

  • Clean up an abandoned enrollment setup; this cannot delete a verified user.

How it works

  1. Confirmed owner-scoped DELETE checks verified:false; pending/reconciliation-blocked linked requests prevent removal.

Prerequisites

  • A stored CLI Login for this region with the command permission; the server account must be eligible for the requested operation.

Expected outcome

Success identifies deleted TOTP user; no message or charge occurs.

Next steps

  • If 404, verify this is an unverified setup. Check users/history before retry after any ambiguous response.

Usage

sh
akedly totp users setup-delete <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "totp users setup-delete" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Use the totpID from akedly totp users list.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--yesboolean switch—Confirm this action where consent is required.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: totp:delete.

Server request: DELETE /totp/dashboard/setup-delete/:totpID.

Shared server-guard guidance.

Consent

--yes. --dry-run bypasses confirmation where supported. Destructive: true. Spends money: false. Real send: false.

Retry

write: Non-idempotent writes are not automatically retried. guarded-write: when an update carries the revision read from the server, its write is not automatically retried after network errors or HTTP 429/502/503/504. It may already be saved; inspect the resource before rerunning. A rerun reads current settings again. The explicit CLI_RATE_LIMITED refusal exception below still applies. recommendation-read: the recommendation request made while planning --recommended-limits is not automatically retried after network errors or HTTP 429/502/503/504. If planning fails, no update is sent; rerun the command to request a new recommendation. The explicit CLI_RATE_LIMITED refusal exception below still applies. This label does not change the retry policy of the standalone rate-recommendations command.

Output

Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.

Full command details

Remove only an owned unverified TOTP setup using its 24-hex totpID from akedly totp users list; requires --yes. The deletion itself checks verified:false; an already verified or missing setup returns 404. No setupDeletionToken is needed on this authenticated command. Linked authentication-request history is removed after deletion; reconciliation can refuse with TOTP_DELETE_RECONCILIATION_PENDING (409). Any Pending request blocks, including one just opened; Failed requests can block too. Ordinary unverified, unbilled requests expire about five minutes after creation and normally become Expired on the next five-minute reconciliation run, within about ten minutes of creation; job delays or billing/counter recovery can extend that wait. Check the stored status in akedly totp history list; computed isExpired alone does not unblock deletion. Ask Akedly support if a request stays Pending or Failed beyond that normal window, or is Verified and still blocks. No message or charge occurs. Hosted QR images are not removed. A failed response can follow partial deletion: inspect users and history before retrying. Read-only logins are refused. --dry-run sends nothing.

Login 429 guidance.

Worked examples

Examples are synthetic illustrations, never live account records. Replace resource IDs with your own authorized resources. Secret values are omitted here; redacted examples illustrate the shape and are not schema-validation fixtures.

Synthetic offline fixture

Remove only an unfinished unverified TOTP setup and its linked request history.

sh
akedly totp users setup-delete 65a1b2c3d4e5f67890123456 --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "TOTP setup deleted successfully",
  "data": {
    "deletedTotpUser": {
      "id": "65a1b2c3d4e5f67890123456",
      "identifier": "person@example.invalid"
    }
  }
}

All IDs, destination, company, dates, callback URL and payload values are synthetic fixtures; example.invalid is reserved for documentation. Do not paste a real OTP, phone, API key, widget Secret, token, or account identifier into an agent test or shared output.

This worked response is illustrative only and was not executed against an account.

Additional command forms

sh
akedly totp users setup-delete <id> --yes

Input and file contracts

The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.

Response contract

Successful response example is synthetic and demonstrates observed field names/types; server-supplied extension fields are preserved.

Common error guidance.