Team and team notifications
Akedly CLI command reference: Team and team notifications.
team permissions list
List the permission catalog for custom roles.
When to use
- List the permission catalog for custom roles. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
How it works
- Sends GET to /rbac/catalog; 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
List the permission catalog for custom roles. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team permissions list
Inspect this command offline before preparing an operation:
akedly describe "team permissions list" --output json
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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 /rbac/catalog.
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 permission catalog for custom roles. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
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
List the permission catalog for custom roles
akedly team permissions list
Illustrative response (sensitive values omitted):
{
"version": "2026-10",
"permissions": [
{
"key": "pipelines:read",
"description": "Read pipelines"
}
]
}
Synthetic illustration only; not executed.
Additional command forms
akedly team permissions 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
The CLI returns the backend JSON as received; extra backend fields may appear.
Synthetic values are documentation only.
team roles list
List global roles and your organization's custom roles; use custom-role IDs for updates/deletion and role keys for member assignments.
When to use
- List global roles and your organization's custom roles; use custom-role IDs for updates/deletion and role keys for member assignments. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role.
How it works
- Sends GET to /rbac/roles; 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
List global roles and your organization's custom roles; use custom-role IDs for updates/deletion and role keys for member assignments. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team roles list
Inspect this command offline before preparing an operation:
akedly describe "team roles list" --output json
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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 /rbac/roles.
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 global roles and your organization's custom roles; use custom-role IDs for updates/deletion and role keys for member assignments. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role.
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
List global roles and your organization's custom roles; use custom-role IDs for updates/deletion and role keys for member assignments
akedly team roles list
Illustrative response (sensitive values omitted):
{
"roles": [
{
"id": "64b000000000000000000011",
"key": "support_lead",
"name": "Support Lead",
"description": "Handles support",
"permissions": [
"pipelines:read"
],
"orgId": "org_fixture",
"scope": "org",
"isSystem": false,
"createdBy": "user_fixture_owner",
"createdAt": "2026-10-01T12:00:00.000Z",
"updatedAt": "2026-10-01T12:00:00.000Z"
}
]
}
Synthetic illustration only; not executed.
Additional command forms
akedly team roles 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 role is the backend serializeRole DTO. Use role.id in update/delete commands; scope is org or global and isSystem is a boolean.
Global built-in roles are not editable/deletable through customer organization role commands.
Synthetic example only.
team roles create
Create a custom role using an explicit immutable key and comma-separated permissions from team permissions list.
When to use
- Create a custom role using an explicit immutable key and comma-separated permissions from team permissions list. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role.
How it works
- Sends POST to /rbac/roles; 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
Create a custom role using an explicit immutable key and comma-separated permissions from team permissions list. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team roles create
Inspect this command offline before preparing an operation:
akedly describe "team roles create" --output json
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--key | text | — | yes | Command-specific option; see the full command details below. Manifest body field: key. |
--name | text | — | yes | Command-specific option; see the full command details below. Manifest body field: name. |
--description | text | — | no | Command-specific option; see the full command details below. Manifest body field: description. |
--permissions | text | — | yes | Command-specific option; see the full command details below. Manifest body field: permissions. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--yes | boolean switch | — | no | Confirm this action where consent is required. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | 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 /rbac/roles.
Consent
--yes. --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 custom role using an explicit immutable key and comma-separated permissions from team permissions list. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role. Needs --yes because the role grants permissions to every member assigned to it.
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
Create a custom role using an explicit immutable key and comma-separated permissions from team permissions list
akedly team roles create --key support --name Support --permissions pipelines:read --yes
Illustrative response (sensitive values omitted):
{
"role": {
"id": "64b000000000000000000011",
"key": "support_lead",
"name": "Support Lead",
"description": "Handles support",
"permissions": [
"pipelines:read"
],
"orgId": "org_fixture",
"scope": "org",
"isSystem": false,
"createdBy": "user_fixture_owner",
"createdAt": "2026-10-01T12:00:00.000Z",
"updatedAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Additional command forms
akedly team roles create --key support --name Support --permissions pipelines:read --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
Each role is the backend serializeRole DTO. Use role.id in update/delete commands; scope is org or global and isSystem is a boolean.
Global built-in roles are not editable/deletable through customer organization role commands.
Synthetic example only.
team roles update
Update only supplied fields of an organization role by its 24-hex id.
When to use
- Update only supplied fields of an organization role by its 24-hex id. Global roles cannot be edited; key is immutable. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
--permissionsreplaces the role's whole permission list; list every key to keep. Use the id from team roles list. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role. Example: akedly team roles update <id>--nameSupport--permissionspipelines:read.
How it works
- Sends PATCH to /rbac/roles/: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
Update only supplied fields of an organization role by its 24-hex id. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team roles update <id>
Inspect this command offline before preparing an operation:
akedly describe "team roles update" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Required positional argument. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--name | text | — | Command-specific option; see the full command details below. Manifest body field: name. |
--description | text | — | Command-specific option; see the full command details below. Manifest body field: description. |
--permissions | text | — | Command-specific option; see the full command details below. Manifest body field: permissions. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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 /rbac/roles/:id.
Consent
--yes when --name or --description or --permissions is given. --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 only supplied fields of an organization role by its 24-hex id. Global roles cannot be edited; key is immutable. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. --permissions replaces the role's whole permission list; list every key to keep. Use the id from team roles list. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role. Every update needs --yes because it changes the role for every member who has it. Example: akedly team roles update <id> --name Support --permissions pipelines:read --yes.
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
Update only supplied fields of an organization role by its 24-hex id
akedly team roles update 64b000000000000000000001 --permissions pipelines:read --yes
Illustrative response (sensitive values omitted):
{
"role": {
"id": "64b000000000000000000011",
"key": "support_lead",
"name": "Support Lead",
"description": "Handles support",
"permissions": [
"pipelines:read"
],
"orgId": "org_fixture",
"scope": "org",
"isSystem": false,
"createdBy": "user_fixture_owner",
"createdAt": "2026-10-01T12:00:00.000Z",
"updatedAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Additional command forms
akedly team roles update <id> --permissions pipelines:read --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
Each role is the backend serializeRole DTO. Use role.id in update/delete commands; scope is org or global and isSystem is a boolean.
Global built-in roles are not editable/deletable through customer organization role commands.
Synthetic example only.
team roles delete
Delete an organization role by its 24-hex id.
When to use
- Delete an organization role by its 24-hex id. Reassign its members first. Members left on a deleted role lose its permissions (deny-all, unless a global role has the same key). Global roles cannot be deleted. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Use the id from team roles list. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role.
How it works
- Sends DELETE to /rbac/roles/: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
Delete an organization role by its 24-hex id. The API response is returned unchanged.
Next steps
- Verify the target using the corresponding list command before taking follow-up action.
Usage
akedly team roles delete <id>
Inspect this command offline before preparing an operation:
akedly describe "team roles delete" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Required positional argument. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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: DELETE /rbac/roles/:id.
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
Delete an organization role by its 24-hex id. Reassign its members first. Members left on a deleted role lose its permissions (deny-all, unless a global role has the same key). Global roles cannot be deleted. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. Use the id from team roles list. Global roles are managed by Akedly; create a custom organization role instead of editing a built-in role.
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
Delete an organization role by its 24-hex id
akedly team roles delete 64b000000000000000000001 --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"id": "64b000000000000000000011"
}
Synthetic illustration only; not executed.
Additional command forms
akedly team roles 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
The CLI returns the backend JSON as received; extra backend fields may appear.
Synthetic values are documentation only.
team members list
List members and pending invitations for your active organization.
When to use
- List members and pending invitations for your active organization. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
How it works
- Sends GET to /rbac/members; the CLI prints the backend response, with member ID fields named memberId.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
List members and pending invitations for your active organization. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team members list
Inspect this command offline before preparing an operation:
akedly describe "team members list" --output json
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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 /rbac/members.
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 members and pending invitations for your active organization. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. memberId in the output is the member's ID; team members set-role and remove, and team-notifications members set-types and reenable, take either that ID or the member's email.
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
List members and pending invitations for your active organization
akedly team members list
Illustrative response (sensitive values omitted):
{
"orgId": "org_fixture",
"ownerMemberId": "user_fixture_owner",
"enterpriseMode": false,
"members": [
{
"memberId": "user_fixture_member",
"email": "member@example.invalid",
"firstName": "Alex",
"lastName": "Example",
"imageUrl": null,
"role": "org:member",
"akedlyRole": "support_lead",
"isOwner": false,
"createdAt": "2026-10-01T12:00:00.000Z"
}
],
"invitations": [
{
"id": "inv_fixture_01",
"email": "invitee@example.invalid",
"role": "org:member",
"akedlyRole": "member",
"status": "pending",
"createdAt": "2026-10-01T12:00:00.000Z"
}
]
}
Synthetic illustration only; not executed.
Additional command forms
akedly team members 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
Members and invitations are normalized organization records. role is the organization role (org:admin/org:member); akedlyRole is the Akedly role slug.
enterpriseMode is a boolean. Use member.memberId or the member's email with members set-role/remove and the team-notifications members commands, and invitation.id with invitations revoke.
Synthetic identities only.
imageUrl is omitted when the image is hosted by the sign-in service; the CLI does not print those addresses.
team members set-role
Assign admin, org:admin, member, org:member or a role key to a member.
When to use
- Assign admin, org:admin, member, org:member or a role key to a member. The organization owner is protected from role changes. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. admin (org:admin) also manages the team; member (org:member) has full access to every other feature; a role key from team roles list limits access to that role's permissions.
How it works
- Sends PATCH to /rbac/members/:memberId; the CLI prints the backend response, with member ID fields named memberId.
- <member> is an email or a memberId; an email is first matched (case-insensitively, exactly) against GET /rbac/members, before consent and also under
--dry-run. No match stops with MEMBER_NOT_FOUND and more than one with MEMBER_AMBIGUOUS, before any write. - Changes the member role and resulting permissions without removing membership.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Assign admin, org:admin, member, org:member or a role key to a member. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team members set-role <member>
Inspect this command offline before preparing an operation:
akedly describe "team members set-role" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <member> | ^(?:[A-Za-z0-9_]{1,128}|[^\s@/?#%]{1,64}@[^\s@/?#%]{1,253})$ | Use the member's email or their memberId from akedly team members list. |
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--role | text | — | yes | Command-specific option; see the full command details below. Manifest body field: role. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--yes | boolean switch | — | no | Confirm this action where consent is required. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | 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 /rbac/members/:memberId.
Consent
--yes. --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
Assign admin, org:admin, member, org:member or a role key to a member. The organization owner is protected from role changes. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. admin (org:admin) also manages the team; member (org:member) has full access to every other feature; a role key from team roles list limits access to that role's permissions. Needs --yes because it changes what the member can do. <member> is the member's email or their memberId from akedly team members list; an email is looked up in your organization's member list first.
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
Assign admin, org:admin, member, org:member or a role key to a member
akedly team members set-role member@example.invalid --role support --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"memberId": "user_fixture_member",
"role": "support_lead"
}
Synthetic illustration only; not executed.
Additional command forms
akedly team members set-role <member> --role support --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
The CLI returns the backend JSON as received; extra backend fields may appear.
Synthetic values are documentation only.
team members remove
Remove a member from your active organization.
When to use
- Remove a member from your active organization. The organization owner cannot be removed. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
How it works
- Sends DELETE to /rbac/members/:memberId; the CLI prints the backend response, with member ID fields named memberId.
- <member> is an email or a memberId; an email is first matched (case-insensitively, exactly) against GET /rbac/members, before consent and also under
--dry-run. No match stops with MEMBER_NOT_FOUND and more than one with MEMBER_AMBIGUOUS, before any write. - Removes organization membership and associated access, but does not delete the Akedly account.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Remove a member from your active organization. The API response is returned unchanged.
Next steps
- Verify the target using the corresponding list command before taking follow-up action.
Usage
akedly team members remove <member>
Inspect this command offline before preparing an operation:
akedly describe "team members remove" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <member> | ^(?:[A-Za-z0-9_]{1,128}|[^\s@/?#%]{1,64}@[^\s@/?#%]{1,253})$ | Use the member's email or their memberId from akedly team members list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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: DELETE /rbac/members/:memberId.
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 a member from your active organization. The organization owner cannot be removed. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. <member> is the member's email or their memberId from akedly team members list; an email is looked up in your organization's member list first.
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
Remove a member from your active organization
akedly team members remove member@example.invalid --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"memberId": "user_fixture_member"
}
Synthetic illustration only; not executed.
Additional command forms
akedly team members remove <member> --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
The CLI returns the backend JSON as received; extra backend fields may appear.
Synthetic values are documentation only.
team members invite
Send a real invitation email.
When to use
- Send a real invitation email. Requires an explicit role key or admin/member alias; no role is selected by default. This command does not retry an ambiguous network/server failure; check team members list before sending again. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. admin (org:admin) also manages the team; member (org:member) has full access to every other feature; a role key from team roles list limits access to that role's permissions.
How it works
- Sends POST to /rbac/members/invitations; the CLI prints the backend response, with member ID fields named memberId.
- Creates a pending organization invitation that may email the invitee; membership begins only after acceptance.
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 created pending invitation as a normalized record; an invitation email may be sent, but access starts only on acceptance.
Next steps
- Check pending/accepted state before retrying; an ambiguous failure may follow a delivered email.
Usage
akedly team members invite
Inspect this command offline before preparing an operation:
akedly describe "team members invite" --output json
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--email | text | — | yes | Command-specific option; see the full command details below. Manifest body field: email. |
--role | text | — | yes | Command-specific option; see the full command details below. Manifest body field: role. |
--yes | boolean switch | — | no | Confirm this action where consent is required. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | 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 /rbac/members/invitations.
Consent
--yes. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: true.
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
Send a real invitation email. Requires an explicit role key or admin/member alias; no role is selected by default. This command does not retry an ambiguous network/server failure; check team members list before sending again. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors. admin (org:admin) also manages the team; member (org:member) has full access to every other feature; a role key from team roles list limits access to that role's permissions.
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
Send a real invitation email
akedly team members invite --email ops@example.invalid --role support_lead --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"invitation": {
"id": "inv_fixture_01",
"email": "invitee@example.invalid",
"role": "org:member",
"akedlyRole": "support_lead",
"status": "pending",
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Requires --yes; may send a real email when executed.
Additional command forms
akedly team members invite --email <email> --role <roleKey> --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
Invitation is the normalized pending organization invitation; acceptance creates membership. role is the organization role and akedlyRole is the Akedly role slug.
The command may send an invitation email. Synthetic example only.
team invitations revoke
Revoke a pending invitation in your active organization.
When to use
- Revoke a pending invitation in your active organization. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
How it works
- Sends DELETE to /rbac/members/invitations/:invitationId; 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
Revoke a pending invitation in your active organization. The API response is returned unchanged.
Next steps
- Verify the target using the corresponding list command before taking follow-up action.
Usage
akedly team invitations revoke <invitationId>
Inspect this command offline before preparing an operation:
akedly describe "team invitations revoke" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <invitationId> | ^[A-Za-z0-9_]{1,128}$ | Use the invitation id from akedly team members list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-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: DELETE /rbac/members/invitations/:invitationId.
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
Revoke a pending invitation in your active organization. Needs team-management access in your active organization. Membership checks are cached for 60 seconds, so a recently demoted admin may retain access during that window. Upstream sign-in service failures can appear as code-less HTTP 502 errors.
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
Revoke a pending invitation in your active organization
akedly team invitations revoke inv_fixture_01 --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"invitationId": "inv_fixture_01"
}
Synthetic illustration only; not executed.
Additional command forms
akedly team invitations revoke <invitationId> --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
The CLI returns the backend JSON as received; extra backend fields may appear.
Synthetic values are documentation only.
team-notifications list
List notification recipients, their type settings, consent state and account limits.
When to use
- List notification recipients, their type settings, consent state and account limits. This endpoint returns the complete list and has no pagination or filter flags. Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply.
How it works
- Sends GET to /notification-subscriptions; the CLI prints the backend response, with member ID fields named memberId.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
List notification recipients, their type settings, consent state and account limits. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team-notifications list
Inspect this command offline before preparing an operation:
akedly describe "team-notifications list" --output json
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-paths | — | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:read.
Server request: GET /notification-subscriptions.
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 notification recipients, their type settings, consent state and account limits. This endpoint returns the complete list and has no pagination or filter flags. Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply.
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
List notification recipients, their type settings, consent state and account limits
akedly team-notifications list
Illustrative response (sensitive values omitted):
{
"status": "success",
"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"
}
],
"limits": {
"max": 20,
"used": 1,
"remaining": 19
},
"data": [
{
"_id": "64b000000000000000000020",
"email": "ops@example.invalid",
"status": "active",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": null,
"deliveryStatus": null,
"invitedBy": "owner",
"source": "manual",
"memberId": null,
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
]
}
Synthetic illustration only; not executed.
Additional command forms
akedly team-notifications 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
data is a recipient array, catalog describes all supported alert types, and limits is {max,used,remaining}.
Each recipient is the serialized subscription record; notification recipients are separate from organization memberships.
A manual recipient limit applies to account-entered addresses; org_member rows are membership-managed.
team-notifications add
Send a real third-party consent email to add a recipient; they remain pending until they accept.
When to use
- Send a real third-party consent email to add a recipient; they remain pending until they accept. Server limits: 20 manual recipients and 20 consent invitations in a rolling 24-hour window. Pass
--typesas comma-separated word=on|off pairs using the words below. For a fresh recipient, words you leave out default to reports and quota-usage on and every other alert off; for a declined or deactivated recipient being invited again, words you leave out keep that recipient's earlier choices. The CLI refuses unknown or repeated words and values other than on or off, instead of letting the server silently drop them. At least one alert must end up on; otherwise the server returns HTTP 400 before saving or sending. If invitations from this account were reported, sending is paused: the server answers HTTP 403 (shown as PERMISSION_DENIED) and support must restore it.
How it works
- Sends POST to /notification-subscriptions; the CLI prints the backend response, with member ID fields named memberId.
- Sends a consent email; recipient stays pending until acceptance. This recipient list is separate from team membership.
- Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Creates/updates a manual pending recipient and sends a consent email; the response includes the serialized recipient and delivery/consent lifecycle fields.
Next steps
- Check pending/accepted state before retrying; an ambiguous failure may follow a delivered email.
Usage
akedly team-notifications add
Inspect this command offline before preparing an operation:
akedly describe "team-notifications add" --output json
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--email | text | — | yes | Command-specific option; see the full command details below. Manifest body field: email. |
--types | text | — | yes | Command-specific option; see the full command details below. Manifest body field: types. |
--yes | boolean switch | — | no | Confirm this action where consent is required. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:create.
Server request: POST /notification-subscriptions.
Consent
--yes. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: true.
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
Send a real third-party consent email to add a recipient; they remain pending until they accept. Server limits: 20 manual recipients and 20 consent invitations in a rolling 24-hour window. Pass --types as comma-separated word=on|off pairs using the words below. For a fresh recipient, words you leave out default to reports and quota-usage on and every other alert off; for a declined or deactivated recipient being invited again, words you leave out keep that recipient's earlier choices. The CLI refuses unknown or repeated words and values other than on or off, instead of letting the server silently drop them. At least one alert must end up on; otherwise the server returns HTTP 400 before saving or sending. If invitations from this account were reported, sending is paused: the server answers HTTP 403 (shown as PERMISSION_DENIED) and support must restore it. 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).
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
Send a real third-party consent email to add a recipient; they remain pending until they accept
akedly team-notifications add --email ops@example.invalid --types reports=on,security-incidents=on --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Recipient added and consent invite sent",
"data": {
"_id": "64b000000000000000000020",
"email": "member@example.invalid",
"status": "pending",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": null,
"deliveryStatus": null,
"invitedBy": "owner",
"source": "manual",
"memberId": "user_fixture_member",
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Requires --yes; may send a real email when executed.
Additional command forms
akedly team-notifications add --email <email> --types reports=on,security-incidents=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
data is the serialized notification subscription record with contact address, consent lifecycle, source, selected alert types and nullable delivery/identity fields.
This notification recipient is not a team membership record.
A successful API call means the consent email send was accepted by the mail transport; eventual delivery/bounce is reflected later in deliveryStatus.
team-notifications update
Change only the alerts you name for a recipient; alerts you leave out stay as they are, with no read or merge.
When to use
- Change only the alerts you name for a recipient; alerts you leave out stay as they are, with no read or merge.
--typestakes comma-separated word=on|off pairs using the words below; unknown or repeated words and values other than on or off are refused before any request. Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply. On a teammate's row the role rule applies: turning on an alert their role does not allow is refused with HTTP 409, any other value for such an alert is ignored, and HTTP 503 means team membership could not be checked; retry shortly.
How it works
- Sends PATCH to /notification-subscriptions/:id; the CLI prints the backend response, with member ID fields named memberId.
- Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Change only the alerts you name for a recipient; alerts you leave out stay as they are, with no read or merge. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team-notifications update <id>
Inspect this command offline before preparing an operation:
akedly describe "team-notifications update" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use the _id of the recipient from akedly team-notifications list. |
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--types | text | — | yes | Command-specific option; see the full command details below. Manifest body field: types. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:update.
Server request: PATCH /notification-subscriptions/:id.
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 only the alerts you name for a recipient; alerts you leave out stay as they are, with no read or merge. --types takes comma-separated word=on|off pairs using the words below; unknown or repeated words and values other than on or off are refused before any request. Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply. On a teammate's row the role rule applies: turning on an alert their role does not allow is refused with HTTP 409, any other value for such an alert is ignored, and HTTP 503 means team membership could not be checked; retry shortly. 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).
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 only the alerts you name for a recipient; alerts you leave out stay as they are, with no read or merge
akedly team-notifications update 64b000000000000000000001 --types quota-usage=on,member-left=off
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Notification types updated",
"data": {
"_id": "64b000000000000000000020",
"email": "ops@example.invalid",
"status": "active",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": null,
"deliveryStatus": "delivered",
"invitedBy": "owner",
"source": "manual",
"memberId": null,
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Additional command forms
akedly team-notifications update <id> --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
data is the serialized notification subscription record with contact address, consent lifecycle, source, selected alert types and nullable delivery/identity fields.
This notification recipient is not a team membership record.
team-notifications resend
Send a real third-party consent email again for a pending recipient.
When to use
- Send a real third-party consent email again for a pending recipient. The server caps consent invitations at 20 in a rolling 24-hour window. The recipient remains pending until acceptance. If invitations from this account were reported, sending is paused: the server answers HTTP 403 (shown as PERMISSION_DENIED) and support must restore it. Resending replaces the earlier link, which stops working. A recipient who is not pending gets HTTP 400.
How it works
- Sends POST to /notification-subscriptions/:id/resend; the CLI prints the backend response, with member ID fields named memberId.
- Sends a consent email; recipient stays pending until acceptance. This recipient list is separate from team membership.
- Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Reissues consent for a pending manual recipient; the response includes the serialized record. The earlier link is invalidated.
Next steps
- Check pending/accepted state before retrying; an ambiguous failure may follow a delivered email.
Usage
akedly team-notifications resend <id>
Inspect this command offline before preparing an operation:
akedly describe "team-notifications resend" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use the _id of the recipient from akedly team-notifications list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-paths | — | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:update.
Server request: POST /notification-subscriptions/:id/resend.
Consent
--yes. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: true.
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
Send a real third-party consent email again for a pending recipient. The server caps consent invitations at 20 in a rolling 24-hour window. The recipient remains pending until acceptance. If invitations from this account were reported, sending is paused: the server answers HTTP 403 (shown as PERMISSION_DENIED) and support must restore it. Resending replaces the earlier link, which stops working. A recipient who is not pending gets HTTP 400.
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
Send a real third-party consent email again for a pending recipient
akedly team-notifications resend 64b000000000000000000001 --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Consent invite resent",
"data": {
"_id": "64b000000000000000000020",
"email": "ops@example.invalid",
"status": "pending",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": "2026-10-03T12:00:00.000Z",
"deliveryStatus": null,
"invitedBy": "owner",
"source": "manual",
"memberId": null,
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Requires --yes; may send a real email when executed.
Additional command forms
akedly team-notifications resend <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
data is the serialized notification subscription record with contact address, consent lifecycle, source, selected alert types and nullable delivery/identity fields.
This notification recipient is not a team membership record.
A successful API call means the consent email send was accepted by the mail transport; eventual delivery/bounce is reflected later in deliveryStatus.
team-notifications remove
Remove an eligible manually added notification email recipient from this account.
When to use
- Remove a manual recipient. Team-managed recipients and declined/deactivated records cannot be removed here.
How it works
- DELETEs the selected subscription row.
- Does not remove a team member or account; team-managed recipient rows and declined/deactivated records are protected.
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 response is status success with a message only.
Next steps
- Confirm the recipient no longer appears in team-notifications list.
Usage
akedly team-notifications remove <id>
Inspect this command offline before preparing an operation:
akedly describe "team-notifications remove" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use the _id of the recipient from akedly team-notifications list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--yes | boolean switch | — | Confirm this action where consent is required. |
--dry-run | boolean switch | — | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-paths | — | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:delete.
Server request: DELETE /notification-subscriptions/:id.
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 a manual recipient. Team-managed recipients and declined/deactivated records cannot be removed here.
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
Remove a manual recipient
akedly team-notifications remove 64b000000000000000000001 --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Recipient removed"
}
Synthetic illustration only; not executed.
Additional command forms
akedly team-notifications remove <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 removal returns only status and message; it does not return a removed flag or recipient object.
This removes an eligible manual recipient row. Team-managed or stopped/tombstoned records cannot be removed here.
team-notifications members set-types
Set only the email alerts you name for a teammate, with --types as comma-separated word=on|off pairs using the words below.
When to use
- Set only the email alerts you name for a teammate, with
--typesas comma-separated word=on|off pairs using the words below. Alerts you leave out keep their value on an existing row; a first-time teammate gets the server defaults. Turning on an alert the teammate's role does not allow is refused with HTTP 409; any other value for such an alert (off, or on when it is already on) is ignored and the stored value is kept. The account owner cannot be changed (HTTP 409), and a teammate who unsubscribed is refused with HTTP 409 until you run akedly team-notifications members reenable. The owner is protected, and alerts you turn on must be allowed by the teammate's role. Unknown or repeated words and values other than on or off are refused before any request. Requires both team_notifications permission and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply. If the refusal says 'This person asked us to stop emailing them', the teammate unsubscribed; respect that opt-out. Only with the teammate's consent, an organization admin can run akedly team-notifications members reenable <member>--typesreports=on--yes.
How it works
- Sends PUT to /notification-subscriptions/members/:memberId/types; the CLI prints the backend response, with member ID fields named memberId.
- <member> is an email or a memberId; an email is first matched (case-insensitively, exactly) against GET /rbac/members, before consent and also under
--dry-run. No match stops with MEMBER_NOT_FOUND and more than one with MEMBER_AMBIGUOUS, before any write. - Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
Prerequisites
- A valid CLI login and required command permission. Organization-admin access is required where enforced.
- Any targeted resource must already exist.
Expected outcome
Set only the email alerts you name for a teammate, with --types as comma-separated word=on|off pairs using the words below. The API response is returned unchanged.
Next steps
- Read back changed state with its show/list command.
Usage
akedly team-notifications members set-types <member>
Inspect this command offline before preparing an operation:
akedly describe "team-notifications members set-types" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <member> | ^(?:[A-Za-z0-9_]{1,128}|[^\s@/?#%]{1,64}@[^\s@/?#%]{1,253})$ | Use the member's email or their memberId from akedly team members list. |
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--types | text | — | yes | Command-specific option; see the full command details below. Manifest body field: types. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:update.
Server request: PUT /notification-subscriptions/members/:memberId/types.
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 only the email alerts you name for a teammate, with --types as comma-separated word=on|off pairs using the words below. Alerts you leave out keep their value on an existing row; a first-time teammate gets the server defaults. Turning on an alert the teammate's role does not allow is refused with HTTP 409; any other value for such an alert (off, or on when it is already on) is ignored and the stored value is kept. The account owner cannot be changed (HTTP 409), and a teammate who unsubscribed is refused with HTTP 409 until you run akedly team-notifications members reenable. The owner is protected, and alerts you turn on must be allowed by the teammate's role. Unknown or repeated words and values other than on or off are refused before any request. Requires both team_notifications permission and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply. If the refusal says 'This person asked us to stop emailing them', the teammate unsubscribed; respect that opt-out. Only with the teammate's consent, an organization admin can run akedly team-notifications members reenable <member> --types reports=on --yes. <member> is the member's email or their memberId from akedly team members list; an email is looked up in your organization's member list first. 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).
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 only the email alerts you name for a teammate, with --types as comma-separated word=on|off pairs using the words below
akedly team-notifications members set-types member@example.invalid --types template-approvals=on,template-rejections=on
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Notification types updated",
"data": {
"_id": "64b000000000000000000020",
"email": "member@example.invalid",
"status": "active",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": null,
"deliveryStatus": "delivered",
"invitedBy": "owner",
"source": "org_member",
"memberId": "user_fixture_member",
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
Additional command forms
akedly team-notifications members set-types <member> --types template-approvals=on,template-rejections=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
data is the serialized notification subscription record with contact address, consent lifecycle, source, selected alert types and nullable delivery/identity fields.
This notification recipient is not a team membership record.
team-notifications members reenable
Turn email alerts back on for a teammate who unsubscribed, with required --types as comma-separated word=on|off pairs using the words below; at least one word must be on.
When to use
- Turn email alerts back on for a teammate who unsubscribed, with required
--typesas comma-separated word=on|off pairs using the words below; at least one word must be on. Fails with HTTP 409 if the teammate has not unsubscribed. Nothing is sent now, but they will be emailed again for the alerts that are on, starting with the next alert; they can unsubscribe again from any email. Requires--yes, like the dashboard's confirmation. Alerts you leave out stay as they are. Unknown or repeated words and values other than on or off are refused before any request. Requires both team_notifications:update and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds.
How it works
- Sends POST to /notification-subscriptions/members/:memberId/reenable; the CLI prints the backend response, with member ID fields named memberId.
- <member> is an email or a memberId; an email is first matched (case-insensitively, exactly) against GET /rbac/members, before consent and also under
--dry-run. No match stops with MEMBER_NOT_FOUND and more than one with MEMBER_AMBIGUOUS, before any write. - No email is sent now; selected future alerts resume. Use only with the teammate’s consent.
- Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
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 re-enabled teammate recipient record. It sends no email immediately; selected future alerts may resume.
Next steps
- Check pending/accepted state before retrying; an ambiguous failure may follow a delivered email.
Usage
akedly team-notifications members reenable <member>
Inspect this command offline before preparing an operation:
akedly describe "team-notifications members reenable" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <member> | ^(?:[A-Za-z0-9_]{1,128}|[^\s@/?#%]{1,64}@[^\s@/?#%]{1,253})$ | Use the member's email or their memberId from akedly team members list. |
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--types | text | — | yes | Command-specific option; see the full command details below. Manifest body field: types. |
--dry-run | boolean switch | — | no | Preview without sending the write or creating output files; planning reads may still occur. Bypass consent. |
--yes | boolean switch | — | no | Confirm this action where consent is required. |
--help | boolean switch | — | no | Show offline command help. |
--output | enum | json | human | no | Select JSON or human output. |
--fields | dot-paths | — | no | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:update.
Server request: POST /notification-subscriptions/members/:memberId/reenable.
Consent
--yes. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: true.
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
Turn email alerts back on for a teammate who unsubscribed, with required --types as comma-separated word=on|off pairs using the words below; at least one word must be on. Fails with HTTP 409 if the teammate has not unsubscribed. Nothing is sent now, but they will be emailed again for the alerts that are on, starting with the next alert; they can unsubscribe again from any email. Requires --yes, like the dashboard's confirmation. Alerts you leave out stay as they are. Unknown or repeated words and values other than on or off are refused before any request. Requires both team_notifications:update and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds. <member> is the member's email or their memberId from akedly team members list; an email is looked up in your organization's member list first. 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).
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 email alerts back on for a teammate who unsubscribed, with required --types as comma-separated word=on|off pairs using the words below; at least one word must be on
akedly team-notifications members reenable member@example.invalid --types reports=on --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Email alerts re-enabled",
"data": {
"_id": "64b000000000000000000020",
"email": "member@example.invalid",
"status": "active",
"types": {
"reports": true,
"quotaUsage": true,
"quotaExpiration": false,
"templateApproved": false,
"templateRejected": false,
"templateCategoryChanged": false,
"seatTermExpiring": false,
"seatsChanged": false,
"memberJoined": false,
"memberRemoved": false,
"securityIncidents": false
},
"consentedAt": "2026-10-01T12:00:00.000Z",
"declinedAt": null,
"unsubscribedAt": null,
"expiresAt": null,
"deliveryStatus": "delivered",
"invitedBy": "owner",
"source": "org_member",
"memberId": "user_fixture_member",
"deactivatedAt": null,
"createdAt": "2026-10-01T12:00:00.000Z"
}
}
Synthetic illustration only; not executed.
This re-enables future selected alerts after the teammate unsubscribed; it sends no email immediately and requires --yes plus the teammate’s consent.
Additional command forms
akedly team-notifications members reenable <member> --types reports=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
data is the serialized notification subscription record with contact address, consent lifecycle, source, selected alert types and nullable delivery/identity fields.
This notification recipient is not a team membership record.
team-notifications members newsletter
Read each organization member’s own newsletter subscription state without changing it.
When to use
- Read teammate newsletter subscription state; it is personal preference data and cannot be changed on their behalf. Requires both team_notifications permission and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply.
How it works
- Sends GET to /notification-subscriptions/members/newsletter; the CLI prints the backend response, with member ID fields named memberId.
- Notification recipients are email subscription records, not organization members; member-specific commands address an organization member and enforce their notification role/consent state.
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 an array of memberId/subscribed pairs. This is personal preference information, not a team notification recipient roster.
Next steps
- Share only with operators who need to see teammates’ newsletter preferences.
Usage
akedly team-notifications members newsletter
Inspect this command offline before preparing an operation:
akedly describe "team-notifications members newsletter" --output json
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--help | boolean switch | — | Show offline command help. |
--output | enum | json | human | Select JSON or human output. |
--fields | dot-paths | — | Select comma-separated safe dot paths; apply to each element of a root array. |
Authentication, permission and guards
Auth: login. Permission: team_notifications:read.
Server request: GET /notification-subscriptions/members/newsletter.
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 teammate newsletter subscription state; it is personal preference data and cannot be changed on their behalf. Requires both team_notifications permission and organization-admin access; non-admin members are refused (ORG_ADMIN_REQUIRED, or PERMISSION_DENIED when permission enforcement is on and their role lacks the team_notifications permission). Team membership checks can remain cached for 60 seconds; recently changed access may take that long to apply.
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 teammate newsletter subscription state; it is personal preference data and cannot be changed on their behalf
akedly team-notifications members newsletter
Illustrative response (sensitive values omitted):
{
"status": "success",
"data": [
{
"memberId": "user_fixture_member",
"subscribed": false
}
]
}
Synthetic illustration only; not executed.
Additional command forms
akedly team-notifications members newsletter
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 returned row contains the teammate's memberId and subscribed boolean; the API does not expose or change another person’s newsletter preference.
No matching current member rows produce an empty data array.