Subject pages

228 commands. Each command is assigned exactly once.

• Core, login and configuration: 14 commands.

• API keys: 7 commands.

• Pipelines, bans and webhook verification: 24 commands.

• Widgets: 12 commands.

• OTP: 7 commands.

• Account and personal settings: 17 commands.

• Team and team notifications: 18 commands.

• Billing, pricing, seats and customer requests: 24 commands.

• Analytics and transactions: 25 commands.

• Reports: 9 commands.

• WhatsApp: 14 commands.

• BYO SMS: 14 commands.

• Meta events: 2 commands.

• Utilities discovery and configuration: 7 commands.

• Utilities templates: 11 commands.

• Utilities operations and sandbox: 11 commands.

• TOTP: 12 commands.

Agent rules

• Discover command names with akedly commands --fields name,help. Before planning a task, run akedly describe "<canonical command name>" --output json for that command’s purpose, prerequisites, typed inputs, file contents, response schema, examples and recovery rules. Describe is offline and needs no login. Load only the commands needed for the task; agent-guide is the optional complete handbook.

• Set AKEDLY_OUTPUT=json for agents. JSON stdout is one document; warnings and progress use stderr. Setting tips are advice only and arrive on stderr after a command succeeds, in JSON as {"event":"tip","action","flag","tip"}, where action names the command that wrote the setting (inside quickstart, the step) and a context tip has no flag.

• Use --yes only when the person asked for that action. Destructive, money-spending and real-send commands require --yes; some other commands require it when a listed flag is supplied. --dry-run bypasses confirmation.

• Human output prints each value on one line and escapes control characters, line breaks, U+2028, U+2029 and bidirectional embedding, override and isolate controls as \uXXXX; Arabic text and --json are unaffected, and human agent-guide output remains raw Markdown.

• Never print secrets, API keys, CLI Login credentials or live OTP fields into chat. Keep output private; use a secret-file sink or --save where supported.

• Prefer dev-mode Test Pairs. Real sends can be billed. Enable dev mode explicitly; dashboard test commands never enable it or bypass flags.

• Read code, hint and the exit code before deciding the next action. Use --help for flags and examples; --dry-run sends no write and writes no guide or secret file. It makes the same planning reads as a real run, including the public verification-method catalog, current settings and revisions, permissions, linked resources and requested traffic recommendations. Authenticated planning reads need the same permissions as a real run. A widget-only create preview makes no requests; a create with linked pipeline settings checks that pipeline and permissions. Secrets and setup tokens are masked in previews.

Credentials and region

Sending Commands use AKEDLY_API_KEY or a saved API key, never a CLI Login. --api-key <eight-character prefix> selects a saved key before the environment key; otherwise the region default is used. Never put a full Secret on the command line. V1.2 and status send x-api-key; V1 create and V2 attempt carry the key in the JSON body. Public activation and verification send no credentials.

Auth: login uses the CLI Login created by akedly login. Auth: api-key uses the Sending Command credential described above. Auth: public sends no credentials.

Login names the CLI Login after this machine; pass --machine-name <name> (up to 60 characters) to choose a different name. The approval page prefills its editable Login name field (up to 60 characters) with that name, so the approver can change it before approving; the CLI Logins page shows the approved name.

--ksa selects the KSA deployment for any server command. Region precedence: --ksa, then AKEDLY_REGION (egypt or ksa), then the stored region, then Egypt. Login ignores the stored region and defaults to Egypt unless --ksa or AKEDLY_REGION selects KSA. An invalid AKEDLY_REGION exits 64 before network access.

Flags and output

Flag tables use the effective flags from the CLI manifest, including its server and global flags. A boolean switch takes no value; true/false enums take an explicit value. Required means unconditionally required by the manifest; conditional, alternative and handler-specific requirements remain in the full command details. Defaults absent from manifest metadata are not guessed; consult those details for runtime or server defaults.

akedly commands --json returns a bare array without an envelope. --fields a,b.c selects those paths from each root-array element, retaining order; otherwise paths start at the response root. Missing paths are omitted. Inside an envelope, select list elements with paths such as data.0.name. Teammate and organization identifiers print as memberId, ownerMemberId, organizationId and organizationRole in every command’s output, and --fields uses those names. Output: data means pass-through API data, which can contain personal data; local commands, composites and hand-offs return their documented CLI shapes. secret-sink, live-otp and echo-scrub are privacy classifications, not permission to publish output.

secret-sink: Use the supported sink; default output may contain a secret. live-otp: Responses may contain live OTP fields; keep them private. echo-scrub: echo-scrub masks secret-shaped text, credential fields, secret query parameters and JSON secret fields inside strings in the response, such as a webhook receiver echo or BYO-SMS steps; keep the output private anyway.

Pagination

--all cannot be combined with --page. It requests pages in order, verifies the server page matches the requested page, deduplicates _id, and stops after 1000 pages. A nonterminal page with no new ids is refused; a terminal duplicate-only page completes. The first envelope is returned with all rows and the final pagination. Offset pagination can skip or duplicate rows while data changes; deduplication cannot recover skipped rows. Mid-loop failure returns pagesFetched without partial rows. Each page uses the login request budget.

Retry rules

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.

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.

Login scheme: a 429 without a server code is displayed as CLI_RATE_LIMITED; that display label does not make a non-idempotent request retry. Other server codes are preserved. Only a server response explicitly coded CLI_RATE_LIMITED gets the pre-operation retry exception, because that refusal sends nothing (at most 3 tries).

Local command; no HTTP retry.

The final send POST of a send command is never retried, except that under the login scheme a refusal coded CLI_RATE_LIMITED, which sends nothing, is retried as described above. A challenge GET inside a send command is a retried read.

These are transport classes, not a guarantee that an entire multi-step action repeats safely. Command-specific help and recovery instructions still apply. A browser hand-off prints or opens a link; it does not itself require --yes. Consult each command’s consent row. Destructive, Spends money and Real send are consent classes that decide when --yes is required; a false flag value does not mean the command has no server-side effect. Read the full command details for side effects.

Server guards

Important server guards and prerequisites are described in each command’s full details. The manifest does not encode a complete server guard inventory.

Errors

Use the shared root hints and exit codes when their codes are returned. This is fallback guidance, not a promise that every listed code can occur for a command. Preserve the actual code and HTTP status; inspect state before repeating an uncertain write.

Own hints take precedence where defined. Root hints below are used only when the corresponding code is returned; they do not assert that a command can return every code. API error shapes vary; the CLI normalizes them. Read the actual code, HTTP status, hint and exit status.

Exit 1 covers codes outside this table. HTTP 429 exits 69 even for a code not in the table.