Skip to content
Akedly
Command reference

Account and personal settings

Akedly CLI command reference: Account and personal settings.

Build with AI agents

company show

Read your company profile.

When to use

  • Read your company profile.

How it works

  1. Sends GET to /users/company/:userID; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns the current company profile fields; an update changes only supplied fields and none clears a supplied text field.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly company show

Inspect this command offline before preparing an operation:

sh
akedly describe "company show" --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: company_profile:read.

Server request: GET /users/company/: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 company profile.

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 usage

Read your company profile

sh
akedly company show

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "name": "Northwind Demo",
    "description": "Synthetic example company",
    "website": "https://example.invalid",
    "logo": null
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly company show

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

data is the account company profile subdocument. name, description, website, or logo may be omitted when unset; logo is maintained by upload-logo.

The CLI returns the API response without reshaping it.

Common error guidance.

company update

Edit only supplied company fields.

When to use

  • Edit only supplied company fields. none clears a field. Limits: name 120, description 2000 and website 500 characters.

How it works

  1. Sends PUT to /users/company/:userID; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns the current company profile fields; an update changes only supplied fields and none clears a supplied text field.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly company update

Inspect this command offline before preparing an operation:

sh
akedly describe "company update" --output json

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.
--websitetext—Command-specific option; see the full command details below. Manifest body field: website.
--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: company_profile:update.

Server request: PUT /users/company/: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

Edit only supplied company fields. none clears a field. Limits: name 120, description 2000 and website 500 characters.

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 usage

Edit only supplied company fields

sh
akedly company update --name Example

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "name": "Northwind Demo",
    "description": "Synthetic example company",
    "website": "https://example.invalid",
    "logo": null
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly company update --name Example
sh
akedly company update --website none

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

data is the account company profile subdocument. name, description, website, or logo may be omitted when unset; logo is maintained by upload-logo.

The CLI returns the API response without reshaping it.

Common error guidance.

Upload a PNG, JPEG, GIF or WebP up to 3 MiB; the server requires at least 8x8 pixels.

When to use

  • Upload a PNG, JPEG, GIF or WebP up to 3 MiB; the server requires at least 8x8 pixels. Replaces your current company logo immediately; no follow-up update is needed.

How it works

  1. Sends POST to /cloudinary/uploadCompanyLogo; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Upload a PNG, JPEG, GIF or WebP up to 3 MiB; the server requires at least 8x8 pixels. The API response is returned unchanged.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly company upload-logo

Inspect this command offline before preparing an operation:

sh
akedly describe "company upload-logo" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--filetext—yesCommand-specific option; see the full command details below. Manifest body field: fileURL.
--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: company_profile:update.

Server request: POST /cloudinary/uploadCompanyLogo.

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

Upload a PNG, JPEG, GIF or WebP up to 3 MiB; the server requires at least 8x8 pixels. Replaces your current company logo immediately; no follow-up update is needed.

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 usage

Upload a PNG, JPEG, GIF or WebP up to 3 MiB; the server requires at least 8x8 pixels

sh
akedly company upload-logo --file logo.png

Input file: logo.png (base64).

text
iVBORw0KGgoAAAANSUhEUgAAAAgAAAAICAIAAABLbSncAAAAEUlEQVR4nGPQyNuCFTEMLQkAGahSgZLbNF8AAAAASUVORK5CYII=

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Logo uploaded successfully",
  "data": {
    "url": "https://res.cloudinary.com/example/image/upload/company-logo.png"
  }
}

Synthetic illustration only; not executed. The file fixture is an 8×8 PNG accepted by the logo image contract.

Additional command forms

sh
akedly company upload-logo --file logo.png

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

The CLI returns the backend JSON as received; extra backend fields may appear.

Synthetic values are documentation only.

Common error guidance.

announcements list

Read your visible announcements.

When to use

  • Read your visible announcements.

How it works

  1. Sends GET to /announcements; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns visible announcement records with separate nullable seenAt and openedAt markers.

Next steps

  • Use mark-seen when the user has viewed the item in their inbox; use mark-opened when they opened its content. read-all records both markers for selected visible items.

Usage

sh
akedly announcements list

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements 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: announcements:read.

Server request: GET /announcements.

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 visible announcements.

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 usage

Read your visible announcements

sh
akedly announcements list

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "_id": "64b000000000000000000001",
      "title": "Service update",
      "summary": "Synthetic announcement",
      "author": "Akedly",
      "body": "Example body",
      "category": "company",
      "tags": [
        "service"
      ],
      "media": [
        {
          "type": "image",
          "url": "https://example.invalid/service.png",
          "thumbnailUrl": "",
          "caption": "Status illustration"
        }
      ],
      "cta": [
        {
          "label": "Read details",
          "url": "https://example.invalid/status",
          "style": "primary",
          "newTab": true
        }
      ],
      "pinned": false,
      "showAsModal": false,
      "publishedAt": "2026-10-01T12:00:00.000Z",
      "seenAt": null,
      "openedAt": null
    }
  ]
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements 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

Each announcement includes separate seenAt and openedAt timestamps; either can be null. A null marker means the user has not recorded that event.

Audience-invisible or unpublished announcements do not appear.

Common error guidance.

announcements unread-count

Read your unread announcement count.

When to use

  • Read your unread announcement count.

How it works

  1. Sends GET to /announcements/unread-count; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns data.unread: the number of visible announcements without a seen marker.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly announcements unread-count

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements unread-count" --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: announcements:read.

Server request: GET /announcements/unread-count.

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 unread announcement count.

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 usage

Read your unread announcement count

sh
akedly announcements unread-count

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "unread": 1
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements unread-count

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

The CLI returns the backend JSON as received; extra backend fields may appear.

Synthetic values are documentation only.

Common error guidance.

announcements get

Read a visible announcement by its 24-hex id.

When to use

  • Read a visible announcement by its 24-hex id.

How it works

  1. Sends GET to /announcements/:id; the CLI prints the backend response without reshaping it.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns the visible announcement content with separate nullable seenAt and openedAt markers.

Next steps

  • Use mark-seen when the user has viewed the item in their inbox; use mark-opened when they opened its content. read-all records both markers for selected visible items.

Usage

sh
akedly announcements get <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements get" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Required positional argument.

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: announcements:read.

Server request: GET /announcements/:id.

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 a visible announcement by its 24-hex id.

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 usage

Read a visible announcement by its 24-hex id

sh
akedly announcements get 64b000000000000000000001

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "_id": "64b000000000000000000001",
    "title": "Service update",
    "summary": "Synthetic announcement",
    "author": "Akedly",
    "body": "Example body",
    "category": "company",
    "tags": [
      "service"
    ],
    "media": [
      {
        "type": "image",
        "url": "https://example.invalid/service.png",
        "thumbnailUrl": "",
        "caption": "Status illustration"
      }
    ],
    "cta": [
      {
        "label": "Read details",
        "url": "https://example.invalid/status",
        "style": "primary",
        "newTab": true
      }
    ],
    "pinned": false,
    "showAsModal": false,
    "publishedAt": "2026-10-01T12:00:00.000Z",
    "seenAt": null,
    "openedAt": null
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements 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

Each announcement includes separate seenAt and openedAt timestamps; either can be null. A null marker means the user has not recorded that event.

Audience-invisible or unpublished announcements do not appear.

Common error guidance.

announcements mark-seen

Mark this published announcement seen.

When to use

  • Mark this published announcement seen.

How it works

  1. Sets this user’s seenAt marker once; it does not set openedAt.
  2. Seen is the marker used by unread-count.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Mark this published announcement seen. The API response is returned unchanged.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly announcements mark-seen <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements mark-seen" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Required positional argument.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--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: announcements:read.

Server request: POST /announcements/:id/seen.

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

Mark this published announcement seen.

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 usage

Mark this published announcement seen

sh
akedly announcements mark-seen 64b000000000000000000001

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Marked as seen"
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements mark-seen <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

The CLI returns the backend JSON as received; extra backend fields may appear.

Synthetic values are documentation only.

Common error guidance.

announcements mark-opened

Mark this published announcement opened.

When to use

  • Mark this published announcement opened.

How it works

  1. Sets both seenAt and openedAt for this user, with first timestamps preserved.
  2. Opened therefore also counts as seen; opened and seen remain separate timestamps in announcement records.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Mark this published announcement opened. The API response is returned unchanged.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly announcements mark-opened <id>

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements mark-opened" --output json
PositionalGrammarUsage guidance
<id>^[a-fA-F0-9]{24}$Required positional argument.

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--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: announcements:read.

Server request: POST /announcements/:id/opened.

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

Mark this published announcement opened.

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 usage

Mark this published announcement opened

sh
akedly announcements mark-opened 64b000000000000000000001

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Marked as opened"
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements mark-opened <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

The CLI returns the backend JSON as received; extra backend fields may appear.

Synthetic values are documentation only.

Common error guidance.

announcements read-all

Mark 1 to 1000 comma-separated announcement ids as read.

When to use

  • Mark 1 to 1000 comma-separated announcement ids as read. An empty list is refused.

How it works

  1. For 1–1000 supplied IDs, applies only to announcements visible to this user.
  2. Sets both seenAt and openedAt for visible IDs that are not already opened; the marked count reports selected visible records without openedAt before the update.
  3. An empty list is refused by CLI validation.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

Returns data.marked and records both seen and opened for the selected visible announcements; this operation is broader than marking them seen only.

Next steps

  • Read back changed state with its show/list command.

Usage

sh
akedly announcements read-all

Inspect this command offline before preparing an operation:

sh
akedly describe "announcements read-all" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--idsids—yesCommand-specific option; see the full command details below. Manifest body field: ids.
--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: announcements:read.

Server request: POST /announcements/read-all.

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

Mark 1 to 1000 comma-separated announcement ids as read. An empty list is refused.

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 usage

Mark 1 to 1000 comma-separated announcement ids as read

sh
akedly announcements read-all --ids 64b000000000000000000001,64b000000000000000000002

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "marked": 2
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly announcements read-all --ids <id>,<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

read-all sets both seenAt and openedAt, whereas mark-seen sets only seenAt and mark-opened sets both.

data.marked counts selected visible announcements that were not already opened, not a generic unread count.

Common error guidance.

passkeys list

See registered passkey users grouped by phone number, including device count and frozen state.

When to use

  • Review enrollment footprint or confirm whether a phone currently has registered passkeys.

How it works

  1. Login-authenticated owner-scoped read returns a paginated aggregation; optional search filters phone numbers.

Prerequisites

  • A stored CLI Login for this region with the command permission.

Expected outcome

Rows summarize phone, deviceCount, Active/Frozen status, last use, total use count, enrollment date, and pipeline count.

Next steps

  • Use passkeys freeze to pause or resume passkeys for a phone when needed.

Usage

sh
akedly passkeys list

Inspect this command offline before preparing an operation:

sh
akedly describe "passkeys list" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--pageinteger1 to unboundedCommand-specific option; see the full command details below. Query parameter: page.
--limitinteger1 to unboundedCommand-specific option; see the full command details below. Query parameter: limit.
--searchtext—Command-specific option; see the full command details below. Query parameter: search.
--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: passkeys:read.

Server request: GET /passkey/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

Read your registered passkey users.

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

See registered passkey users grouped by phone number, including device count and frozen state.

sh
akedly passkeys list --page 1 --limit 20

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "phone": "+201234567890",
      "deviceCount": 2,
      "status": "Active",
      "lastUsedAt": "2026-10-29T12:00:00.000Z",
      "totalUseCount": 7,
      "enrolledAt": "2026-10-29T12:00:00.000Z",
      "pipelineCount": 1
    }
  ],
  "pagination": {
    "total": 1,
    "page": 1,
    "limit": 20,
    "totalPages": 1
  },
  "message": "Registered passkey users 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 passkeys 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.

passkeys history

Review recent passkey authentication request outcomes and billing fields.

When to use

  • Investigate successful/failed passkey verification activity for your account, optionally searching a phone number.

How it works

  1. Login-authenticated owner-scoped paginated GET returns auth-request records formatted for the history table.

Prerequisites

  • A stored CLI Login for this region with the command permission.

Expected outcome

Rows include request ID, phone, status, verification/billing flags, dates, and optional pipeline summary.

Next steps

  • Compare billed/status details with account transaction and billing records.

Usage

sh
akedly passkeys history

Inspect this command offline before preparing an operation:

sh
akedly describe "passkeys history" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--pageinteger1 to unboundedCommand-specific option; see the full command details below. Query parameter: page.
--limitinteger1 to unboundedCommand-specific option; see the full command details below. Query parameter: limit.
--searchtext—Command-specific option; see the full command details below. Query parameter: search.
--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: passkeys:read.

Server request: GET /passkey/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 passkey verification history.

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 recent passkey authentication request outcomes and billing fields.

sh
akedly passkeys history --page 1 --limit 20

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": [
    {
      "requestID": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
      "_id": "65a1b2c3d4e5f67890123456",
      "userID": "65a1b2c3d4e5f67890123458",
      "phoneNumber": "+201234567890",
      "status": "Verified",
      "method": "passkey",
      "verified": true,
      "billingAmount": 0.25,
      "billed": true,
      "createdAt": "2026-10-29T12:00:00.000Z",
      "verificationDate": "2026-10-29T12:00:00.000Z",
      "expirationDate": "2026-10-29T12:05:00.000Z",
      "pipeline": {
        "name": "Example OTP pipeline",
        "type": "Test",
        "active": true
      },
      "verificationTimeSeconds": 3,
      "isExpired": false
    }
  ],
  "pagination": {
    "total": 1,
    "page": 1,
    "limit": 20,
    "totalPages": 1
  },
  "message": "Passkey 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 passkeys history

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.

passkeys freeze

Temporarily disable or restore passkey authentication for all passkey credentials matching one phone in your account.

When to use

  • Use when a user needs passkeys paused or restored; freezing routes future authentication back to OTP, which may be billable.

How it works

  1. PATCH owner-scoped body with phone and boolean frozen state; confirmation is required. Repeating the selected state is safe and returns modifiedCount.

Prerequisites

  • A stored CLI Login for this region with the command permission.

Expected outcome

Reports normalized phone, requested frozen value, and number of modified credentials.

Next steps

  • Check passkeys list and communicate that OTP may be used while frozen.

Usage

sh
akedly passkeys freeze

Inspect this command offline before preparing an operation:

sh
akedly describe "passkeys freeze" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--phone-numbertext—yesCommand-specific option; see the full command details below. Manifest body field: phoneNumber.
--frozenenumon | offyesCommand-specific option; see the full command details below. Manifest body field: frozen.
--dry-runboolean switch—noPreview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--yesboolean switch—noConfirm this action where consent is required.
--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: passkeys:update.

Server request: PATCH /passkey/freeze.

Shared server-guard guidance.

Consent

--yes. --dry-run bypasses confirmation where supported. Destructive: true. 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

Freeze or unfreeze all passkeys for one end-user phone. --yes is required for either value; freezing sends the user back to potentially billable OTP.

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

Temporarily disable or restore passkey authentication for all passkey credentials matching one phone in your account.

sh
akedly passkeys freeze --phone-number +201234567890 --frozen on --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "phoneNumber": "+201234567890",
    "frozen": true,
    "modifiedCount": 2
  },
  "message": "Passkeys frozen 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 passkeys freeze --phone-number <phone> --frozen on --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.

Freezing makes future verification fall back to OTP, which may be billed.

Common error guidance.

personal-notifications show

Inspect this signed-in person’s platform billing preference, phone setup, email alerts, newsletter preference, and whether platform notifications can currently be delivered.

When to use

  • Before enabling billing alerts, determine whether phone verification and account enrollment are complete.
  • Check a notification state before diagnosing an unavailable or ineligible delivery path.

How it works

  1. Reads the current identity-scoped state through GET /platform-notifications/me.
  2. For an owner, the first read may create the owner contact and default billing subscription; this is a read with that initialization side effect.
  3. Returns setup, contact, preferences, effective state/reason and capabilities; staff-approved identities are refused with SELF_IDENTITY_REQUIRED.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

A full data object describes the authenticated person and account availability. It does not send a notification.

Next steps

  • If contact.state is missing or pending, finish phone setup and account enrollment in the dashboard.
  • Use personal-notifications set only when the response capabilities and prerequisites permit the change.

Usage

sh
akedly personal-notifications show

Inspect this command offline before preparing an operation:

sh
akedly describe "personal-notifications show" --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: none declared.

Server request: GET /platform-notifications/me.

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 personal notification settings. Your first read creates your notification settings if needed. Staff-approved logins are refused with SELF_IDENTITY_REQUIRED.

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 usage

Read your personal notification settings

sh
akedly personal-notifications show

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "account": {
      "displayName": "Demo account"
    },
    "setup": {
      "disclosureVersion": "s3-2026-09"
    },
    "email": {
      "address": "member@example.invalid",
      "role": "teammate",
      "editable": true,
      "readOnlyReason": null,
      "status": "active",
      "catalog": [
        {
          "key": "reports",
          "label": "Reports",
          "desc": "Scheduled usage and delivery reports",
          "category": "Reports & analytics",
          "defaultOn": true,
          "permission": "reports:read"
        },
        {
          "key": "quotaUsage",
          "label": "Quota usage alerts",
          "desc": "When usage crosses a threshold",
          "category": "Usage & billing",
          "defaultOn": true,
          "permission": "billing:read"
        }
      ],
      "types": {
        "reports": true,
        "quotaUsage": true,
        "quotaExpiration": false,
        "templateApproved": false,
        "templateRejected": false,
        "templateCategoryChanged": false,
        "seatTermExpiring": false,
        "seatsChanged": false,
        "memberJoined": false,
        "memberRemoved": false,
        "securityIncidents": false
      },
      "lockedTypes": {}
    },
    "newsletter": {
      "subscribed": false,
      "editable": true,
      "readOnlyReason": null
    },
    "availability": {
      "enabled": true,
      "reason": null
    },
    "contact": {
      "state": "verified",
      "phoneE164": "+201234567890",
      "phoneGeneration": 0,
      "language": "en",
      "verifiedAt": "2026-10-01T12:00:00.000Z",
      "personStopped": false
    },
    "preference": {
      "category": "billing",
      "enabled": true,
      "source": "owner_default",
      "updatedAt": "2026-10-01T12:00:00.000Z"
    },
    "effectiveState": "ready",
    "effectiveReason": null,
    "capabilities": {
      "canEnableBilling": true,
      "canDisableBilling": true,
      "canSetLanguage": true,
      "canReenable": false,
      "canStartVerification": false,
      "canChangePhone": true,
      "canEnrollAccount": false
    }
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly personal-notifications show

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

All successful reads and writes return the full serializeSelfState projection. Fields reflect the current account, the logged-in person’s contact and preferences, effective delivery readiness, and available actions.

The account owner’s email alerts are not editable and owner email notifications remain enabled; teammate state can be role-restricted.

Phone numbers in examples are fictional; actual contact.phoneE164 is returned by the API.

Common error guidance.

personal-notifications set

Change the authenticated person’s platform billing-alert switch, notification language, or both.

When to use

  • Turn the platform billing alerts on/off after verifying contact and account enrollment.
  • Choose English or Arabic for the platform billing notifications.

How it works

  1. PATCHes only supplied preference values and returns the full refreshed self state.
  2. Billing alerts require the platform notification setup/enrollment and eligibility rules; choosing language requires a contact phone.
  3. It does not perform phone verification or account enrollment.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

The API returns the updated preference within the full self-state projection; effective delivery can remain unavailable even when enabled is true.

Next steps

  • Read effectiveState and effectiveReason to distinguish an enabled preference from deliverable notifications.
  • Complete phone setup/enrollment in the dashboard if the API reports setup required.

Usage

sh
akedly personal-notifications set

Inspect this command offline before preparing an operation:

sh
akedly describe "personal-notifications set" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--billing-alertsenumon | offCommand-specific option; see the full command details below. Manifest body field: category, enabled.
--languageenumen | arCommand-specific option; see the full command details below. Manifest body field: language.
--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: none declared.

Server request: PATCH /platform-notifications/me/preferences.

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 personal billing alerts with --billing-alerts and/or notification language with --language. Requires your own person identity. Finish phone setup and account enrollment on the Personal Notifications page of your Akedly dashboard; the CLI cannot do these steps.

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 usage

Set personal billing alerts with --billing-alerts and/or notification language with --language

sh
akedly personal-notifications set --billing-alerts on --language en

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "account": {
      "displayName": "Demo account"
    },
    "setup": {
      "disclosureVersion": "s3-2026-09"
    },
    "email": {
      "address": "member@example.invalid",
      "role": "teammate",
      "editable": true,
      "readOnlyReason": null,
      "status": "active",
      "catalog": [
        {
          "key": "reports",
          "label": "Reports",
          "desc": "Scheduled usage and delivery reports",
          "category": "Reports & analytics",
          "defaultOn": true,
          "permission": "reports:read"
        },
        {
          "key": "quotaUsage",
          "label": "Quota usage alerts",
          "desc": "When usage crosses a threshold",
          "category": "Usage & billing",
          "defaultOn": true,
          "permission": "billing:read"
        }
      ],
      "types": {
        "reports": true,
        "quotaUsage": true,
        "quotaExpiration": false,
        "templateApproved": false,
        "templateRejected": false,
        "templateCategoryChanged": false,
        "seatTermExpiring": false,
        "seatsChanged": false,
        "memberJoined": false,
        "memberRemoved": false,
        "securityIncidents": false
      },
      "lockedTypes": {}
    },
    "newsletter": {
      "subscribed": false,
      "editable": true,
      "readOnlyReason": null
    },
    "availability": {
      "enabled": true,
      "reason": null
    },
    "contact": {
      "state": "verified",
      "phoneE164": "+201234567890",
      "phoneGeneration": 0,
      "language": "en",
      "verifiedAt": "2026-10-01T12:00:00.000Z",
      "personStopped": false
    },
    "preference": {
      "category": "billing",
      "enabled": true,
      "source": "owner_default",
      "updatedAt": "2026-10-01T12:00:00.000Z"
    },
    "effectiveState": "ready",
    "effectiveReason": null,
    "capabilities": {
      "canEnableBilling": true,
      "canDisableBilling": true,
      "canSetLanguage": true,
      "canReenable": false,
      "canStartVerification": false,
      "canChangePhone": true,
      "canEnrollAccount": false
    }
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly personal-notifications set --billing-alerts on --language en

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

All successful reads and writes return the full serializeSelfState projection. Fields reflect the current account, the logged-in person’s contact and preferences, effective delivery readiness, and available actions.

The account owner’s email alerts are not editable and owner email notifications remain enabled; teammate state can be role-restricted.

Phone numbers in examples are fictional; actual contact.phoneE164 is returned by the API.

Common error guidance.

personal-notifications set-email-alerts

Change selected email alert types for the currently signed-in teammate.

When to use

  • A teammate wants to opt into or out of specific account event emails.

How it works

  1. Reads current full state, changes only named alert keys, then writes all catalog types and returns refreshed self state.
  2. Because it writes the full alert map after a prior read, a simultaneous dashboard update can be overwritten.
  3. Account owners always receive these alerts; staff organizations and unavailable/no-address identities are read-only.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

The email.types map in returned data reflects the resulting per-person alert choices; the response is not a simple updated marker.

Next steps

  • Inspect email.types, email.lockedTypes, email.editable, and email.readOnlyReason.
  • If a type is locked by role, ask an organization admin about the role permission; do not retry the same denied update.

Usage

sh
akedly personal-notifications set-email-alerts

Inspect this command offline before preparing an operation:

sh
akedly describe "personal-notifications set-email-alerts" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--typestext—yesCommand-specific option; see the full command details below. Manifest body field: types.
--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: none declared.

Server request: PUT /platform-notifications/me/email-alerts.

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

Change your own email alerts with --types, a comma-separated list of word=on|off pairs using the words below. The CLI reads your current preferences, changes only the words you give and writes all 11 alerts back, so a dashboard change made at the same moment can be overwritten. Dry-run shows <current> for the alerts you did not give. Unknown or repeated words and values other than on or off are refused before any request. The owner always receives every email alert; owner changes are refused with OWNER_ALWAYS_RECEIVES. This changes your own alerts when you are a logged-in teammate, not another person's. Read-only preferences are refused with their existing error code before any update. Words for --types, each followed by the name it prints as in results: reports (reports), quota-usage (quotaUsage), credit-plan-running-out (quotaExpiration), template-approvals (templateApproved), template-rejections (templateRejected), template-category-changes (templateCategoryChanged), seats-term-ending (seatTermExpiring), seat-changes (seatsChanged), member-joined (memberJoined), member-left (memberRemoved), security-incidents (securityIncidents).

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 usage

Change your own email alerts with --types, a comma-separated list of word=on|off pairs using the words below

sh
akedly personal-notifications set-email-alerts --types quota-usage=on,member-left=off

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "account": {
      "displayName": "Demo account"
    },
    "setup": {
      "disclosureVersion": "s3-2026-09"
    },
    "email": {
      "address": "member@example.invalid",
      "role": "teammate",
      "editable": true,
      "readOnlyReason": null,
      "status": "active",
      "catalog": [
        {
          "key": "reports",
          "label": "Reports",
          "desc": "Scheduled usage and delivery reports",
          "category": "Reports & analytics",
          "defaultOn": true,
          "permission": "reports:read"
        },
        {
          "key": "quotaUsage",
          "label": "Quota usage alerts",
          "desc": "When usage crosses a threshold",
          "category": "Usage & billing",
          "defaultOn": true,
          "permission": "billing:read"
        }
      ],
      "types": {
        "reports": true,
        "quotaUsage": true,
        "quotaExpiration": false,
        "templateApproved": false,
        "templateRejected": false,
        "templateCategoryChanged": false,
        "seatTermExpiring": false,
        "seatsChanged": false,
        "memberJoined": false,
        "memberRemoved": false,
        "securityIncidents": false
      },
      "lockedTypes": {}
    },
    "newsletter": {
      "subscribed": false,
      "editable": true,
      "readOnlyReason": null
    },
    "availability": {
      "enabled": true,
      "reason": null
    },
    "contact": {
      "state": "verified",
      "phoneE164": "+201234567890",
      "phoneGeneration": 0,
      "language": "en",
      "verifiedAt": "2026-10-01T12:00:00.000Z",
      "personStopped": false
    },
    "preference": {
      "category": "billing",
      "enabled": true,
      "source": "owner_default",
      "updatedAt": "2026-10-01T12:00:00.000Z"
    },
    "effectiveState": "ready",
    "effectiveReason": null,
    "capabilities": {
      "canEnableBilling": true,
      "canDisableBilling": true,
      "canSetLanguage": true,
      "canReenable": false,
      "canStartVerification": false,
      "canChangePhone": true,
      "canEnrollAccount": false
    }
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly personal-notifications set-email-alerts --types quota-usage=on,member-left=off

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

All successful reads and writes return the full serializeSelfState projection. Fields reflect the current account, the logged-in person’s contact and preferences, effective delivery readiness, and available actions.

The account owner’s email alerts are not editable and owner email notifications remain enabled; teammate state can be role-restricted.

Phone numbers in examples are fictional; actual contact.phoneE164 is returned by the API.

Own recovery guidance

CodeHint
MEMBERSHIP_UNAVAILABLETry again in a moment.
RECIPIENT_UNAVAILABLETry again in a moment.
OWNER_ALWAYS_RECEIVESAccount owners always receive every alert type; change types for a teammate login.
STAFF_ORGStaff accounts have no editable email alerts.
NO_ADDRESSAdd an email address to your account in the dashboard first.

Common error guidance.

personal-notifications set-newsletter

Set the signed-in person’s Akedly newsletter subscription preference.

When to use

  • The person wants to subscribe or unsubscribe their own email address from the newsletter.

How it works

  1. Updates newsletter subscription for the current identity’s resolved address and returns the full refreshed self state.
  2. This is a personal preference and cannot be changed for another teammate.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

data.newsletter.subscribed reflects the current preference along with the rest of self state.

Next steps

  • Read back newsletter.subscribed and editable.

Usage

sh
akedly personal-notifications set-newsletter

Inspect this command offline before preparing an operation:

sh
akedly describe "personal-notifications set-newsletter" --output json

Flags

FlagTypeEnum / rangeRequiredDescription
--ksaboolean switch—noSelect the KSA deployment.
--newsletterenumon | offyesCommand-specific option; see the full command details below. Manifest body field: subscribed.
--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: none declared.

Server request: PUT /platform-notifications/me/newsletter.

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 your own newsletter subscription.

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 usage

Set your own newsletter subscription

sh
akedly personal-notifications set-newsletter --newsletter on

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "account": {
      "displayName": "Demo account"
    },
    "setup": {
      "disclosureVersion": "s3-2026-09"
    },
    "email": {
      "address": "member@example.invalid",
      "role": "teammate",
      "editable": true,
      "readOnlyReason": null,
      "status": "active",
      "catalog": [
        {
          "key": "reports",
          "label": "Reports",
          "desc": "Scheduled usage and delivery reports",
          "category": "Reports & analytics",
          "defaultOn": true,
          "permission": "reports:read"
        },
        {
          "key": "quotaUsage",
          "label": "Quota usage alerts",
          "desc": "When usage crosses a threshold",
          "category": "Usage & billing",
          "defaultOn": true,
          "permission": "billing:read"
        }
      ],
      "types": {
        "reports": true,
        "quotaUsage": true,
        "quotaExpiration": false,
        "templateApproved": false,
        "templateRejected": false,
        "templateCategoryChanged": false,
        "seatTermExpiring": false,
        "seatsChanged": false,
        "memberJoined": false,
        "memberRemoved": false,
        "securityIncidents": false
      },
      "lockedTypes": {}
    },
    "newsletter": {
      "subscribed": true,
      "editable": true,
      "readOnlyReason": null
    },
    "availability": {
      "enabled": true,
      "reason": null
    },
    "contact": {
      "state": "verified",
      "phoneE164": "+201234567890",
      "phoneGeneration": 0,
      "language": "en",
      "verifiedAt": "2026-10-01T12:00:00.000Z",
      "personStopped": false
    },
    "preference": {
      "category": "billing",
      "enabled": true,
      "source": "owner_default",
      "updatedAt": "2026-10-01T12:00:00.000Z"
    },
    "effectiveState": "ready",
    "effectiveReason": null,
    "capabilities": {
      "canEnableBilling": true,
      "canDisableBilling": true,
      "canSetLanguage": true,
      "canReenable": false,
      "canStartVerification": false,
      "canChangePhone": true,
      "canEnrollAccount": false
    }
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly personal-notifications set-newsletter --newsletter on

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

All successful reads and writes return the full serializeSelfState projection. Fields reflect the current account, the logged-in person’s contact and preferences, effective delivery readiness, and available actions.

The account owner’s email alerts are not editable and owner email notifications remain enabled; teammate state can be role-restricted.

Phone numbers in examples are fictional; actual contact.phoneE164 is returned by the API.

Common error guidance.

personal-notifications reenable

Restore this person’s platform notification capability after they previously stopped notifications.

When to use

  • The person has asked to re-enable platform notifications after opting out.

How it works

  1. Re-enables the existing identity-scoped contact/subscription state and returns full refreshed self state.
  2. It does not send an immediate message; future eligible notifications may resume.

Prerequisites

  • A valid CLI login and required command permission. Organization-admin access is required where enforced.
  • Any targeted resource must already exist.

Expected outcome

The full self-state shows current contact stop state, preference, effective state/reason, and capability flags.

Next steps

  • Verify effectiveState and capabilities.canReenable; complete setup or address the reported eligibility reason if delivery is not ready.

Usage

sh
akedly personal-notifications reenable

Inspect this command offline before preparing an operation:

sh
akedly describe "personal-notifications reenable" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--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: none declared.

Server request: POST /platform-notifications/me/reenable.

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

Turn notifications back on for yourself. Finish phone setup and account enrollment on the Personal Notifications page of your Akedly dashboard; the CLI cannot do these steps.

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 usage

Turn notifications back on for yourself

sh
akedly personal-notifications reenable

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "account": {
      "displayName": "Demo account"
    },
    "setup": {
      "disclosureVersion": "s3-2026-09"
    },
    "email": {
      "address": "member@example.invalid",
      "role": "teammate",
      "editable": true,
      "readOnlyReason": null,
      "status": "active",
      "catalog": [
        {
          "key": "reports",
          "label": "Reports",
          "desc": "Scheduled usage and delivery reports",
          "category": "Reports & analytics",
          "defaultOn": true,
          "permission": "reports:read"
        },
        {
          "key": "quotaUsage",
          "label": "Quota usage alerts",
          "desc": "When usage crosses a threshold",
          "category": "Usage & billing",
          "defaultOn": true,
          "permission": "billing:read"
        }
      ],
      "types": {
        "reports": true,
        "quotaUsage": true,
        "quotaExpiration": false,
        "templateApproved": false,
        "templateRejected": false,
        "templateCategoryChanged": false,
        "seatTermExpiring": false,
        "seatsChanged": false,
        "memberJoined": false,
        "memberRemoved": false,
        "securityIncidents": false
      },
      "lockedTypes": {}
    },
    "newsletter": {
      "subscribed": false,
      "editable": true,
      "readOnlyReason": null
    },
    "availability": {
      "enabled": true,
      "reason": null
    },
    "contact": {
      "state": "verified",
      "phoneE164": "+201234567890",
      "phoneGeneration": 0,
      "language": "en",
      "verifiedAt": "2026-10-01T12:00:00.000Z",
      "personStopped": false
    },
    "preference": {
      "category": "billing",
      "enabled": true,
      "source": "owner_default",
      "updatedAt": "2026-10-01T12:00:00.000Z"
    },
    "effectiveState": "ready",
    "effectiveReason": null,
    "capabilities": {
      "canEnableBilling": true,
      "canDisableBilling": true,
      "canSetLanguage": true,
      "canReenable": false,
      "canStartVerification": false,
      "canChangePhone": true,
      "canEnrollAccount": false
    }
  }
}

Synthetic illustration only; not executed.

Additional command forms

sh
akedly personal-notifications reenable

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

All successful reads and writes return the full serializeSelfState projection. Fields reflect the current account, the logged-in person’s contact and preferences, effective delivery readiness, and available actions.

The account owner’s email alerts are not editable and owner email notifications remain enabled; teammate state can be role-restricted.

Phone numbers in examples are fictional; actual contact.phoneE164 is returned by the API.

Common error guidance.