Utilities discovery and configuration
Akedly CLI command reference: Utilities discovery and configuration.
utilities cost-rates
utility costs are estimates; use them to understand likely channel cost and eligibility before setup, not to authorize a send.
When to use
- utility costs are estimates; use them to understand likely channel cost and eligibility before setup, not to authorize a send.
How it works
- Inspect rate fields and eligibility; SMS flat fees may vary by destination and unavailable rates are null.
Prerequisites
- Authenticated account with utilities:read permission.
Expected outcome
No account setting is changed and no send is made.
Next steps
- Compare estimates with account/channel eligibility, then use routing-preview for a non-send route check.
Usage
akedly utilities cost-rates
Inspect this command offline before preparing an operation:
akedly describe "utilities cost-rates" --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: utilities:read.
Server request: GET /utilities/cost-rates.
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 estimated utility prices in EGP, not a send quote or billing guarantee. SMS uses a flat BYO fee that can vary by destination; smsPerSegmentEGP is retired/null. WhatsApp uses a national sample. Unavailable estimates can be null. Check smsEligible: smsFlatFeeEGP is null when SMS is ineligible or has no single price across destinations; when smsFlatFeeVariesByDestination is true, inspect smsFlatFeeMinEGP and smsFlatFeeMaxEGP. Read-only logins are supported.
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 CLI scenario
utility costs are estimates; use them to understand likely channel cost and eligibility before setup, not to authorize a send.
akedly utilities cost-rates
Illustrative response (sensitive values omitted):
{
"status": "success",
"data": {
"currency": "EGP",
"smsPerSegmentEGP": null,
"whatsappPerMessageEGP": 0.75,
"smsFlatFeeEGP": null,
"smsFlatFeeVariesByDestination": false,
"smsFlatFeeMinEGP": null,
"smsFlatFeeMaxEGP": null,
"smsProvider": null,
"smsEligible": false
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities cost-rates
Input and file contracts
The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.
Response contract
Read estimated utility prices in EGP, not a send quote or billing guarantee. SMS uses a flat BYO fee that can vary by destination; smsPerSegmentEGP is retired/null. WhatsApp uses a national sample. Unavailable estimates can be null. Check smsEligible: smsFlatFeeEGP is null when SMS is ineligible or has no single price across destinations; when smsFlatFeeVariesByDestination is true, inspect smsFlatFeeMinEGP and smsFlatFeeMaxEGP. Read-only logins are supported.
Response fields outside the modeled stable fields may be passed through from the server.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
utilities routing-preview
whether an active owned utility pipeline can select BYO SMS for a destination without sending or charging.
When to use
- whether an active owned utility pipeline can select BYO SMS for a destination without sending or charging.
How it works
- Supply a pipeline id and optionally a destination; the server returns a routing preview. It does not assess full channel feasibility, suppression, final budget reservation, or delivery.
Prerequisites
- Authenticated account with utilities:send permission.
Expected outcome
An HTTP 200 with data.route:false is a successful preview and exits 0.
Next steps
- If route is false, inspect the returned reason and review the pipeline BYO-SMS setup; do not interpret this as a delivery failure.
Usage
akedly utilities routing-preview
Inspect this command offline before preparing an operation:
akedly describe "utilities routing-preview" --output json
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--pipeline-id | id | — | yes | Command-specific option; see the full command details below. Manifest body field: pipelineID. |
--phone-number | text | — | no | Command-specific option; see the full command details below. Manifest body field: phone. |
--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: utilities:send.
Server request: POST /utilities/routing-preview.
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
Preview SMS BYO integration selection without sending or charging. Required --pipeline-id identifies an owned, active utility pipeline; optional --phone-number defaults to the saved account phone. This does not check complete WhatsApp/SMS feasibility, suppression, final budget reservation or delivery. HTTP 200 with data.route:false remains a successful preview and exits 0. Requires Full access; read-only logins are refused. --dry-run prints the request only.
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 CLI scenario
whether an active owned utility pipeline can select BYO SMS for a destination without sending or charging.
akedly utilities routing-preview --pipeline-id 64b000000000000000000001 --phone-number +201234567890
Illustrative response (sensitive values omitted):
{
"status": "success",
"data": {
"recipient": "+201234567890",
"route": false,
"reason": "no_active_integration",
"country": "US",
"providerKey": null,
"integrationID": null,
"requiresDurableIdentity": false,
"code": "NO_ACTIVE_INTEGRATION",
"message": "No active BYO-SMS integration covers this destination."
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities routing-preview --pipeline-id <id>
Input and file contracts
The contract below describes typed arguments, file formats, validation boundaries and API mappings. Boolean switches take no value; numeric and comma-separated values are each passed as one argument. Read prerequisites and full command details for state-dependent requirements.
Response contract
Preview SMS BYO integration selection without sending or charging. Required --pipeline-id identifies an owned, active utility pipeline; optional --phone-number defaults to the saved account phone. This does not check complete WhatsApp/SMS feasibility, suppression, final budget reservation or delivery. HTTP 200 with data.route:false remains a successful preview and exits 0. Requires Full access; read-only logins are refused. --dry-run prints the request only.
Response fields outside the modeled stable fields may be passed through from the server.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
HTTP success with route:false is a completed preview, not a send result. reason/country/providerKey/integrationID/code/message are nullable where no selected integration exists.
Own recovery guidance
| Code | Hint |
|---|---|
| INVALID_PIPELINE | Pass --pipeline-id with a 24-hex owned utility pipeline id. |
| INVALID_PHONE | Check --phone-number, or the saved account phone when it is omitted. |
| NO_UTILITY_PIPELINE | Run akedly pipelines create --product utility --name <name> to create a utility pipeline, then akedly pipelines update <id> --status active --yes; or choose an owned, active utility pipeline from akedly pipelines list. |
utilities pipelines channels set
control which utility channels and destinations a pipeline can use for future requests.
When to use
- control which utility channels and destinations a pipeline can use for future requests.
How it works
- Read current config, then submit only selected fields from JSON. Replaced arrays are whole replacements; server canonicalizes countries/order.
Prerequisites
- Authenticated account with utilities:update permission.
- An owned utility pipeline. Enabling WhatsApp requires active WABA and at least one allowed country; enabling SMS or fallback requires eligible BYO-SMS.
Expected outcome
Returns the four resulting settings: channels, channelOrder, allowedCountries and smsFallback.
Next steps
- Verify with pipelines get. WhatsApp needs active WABA/country allowlist; SMS and fallback need eligible BYO-SMS.
Usage
akedly utilities pipelines channels set <id>
Inspect this command offline before preparing an operation:
akedly describe "utilities pipelines channels set" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use an owned utility pipeline id from akedly pipelines list. |
Flags
| Flag | Type | Enum / range | Required | Description |
|---|---|---|---|---|
--ksa | boolean switch | — | no | Select the KSA deployment. |
--file | text | — | yes | Command-specific option; see the full command details below. Manifest body field: allowedCountries, channelOrder, channels, smsFallback. |
--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: utilities:update.
Server request: PUT /utilities/pipelines/:id/channels.
Consent
none. --dry-run bypasses confirmation where supported. Destructive: false. Spends money: false. Real send: false.
Retry
idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.
Output
Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.
Full command details
Update only supplied utility channel settings from required --file, a regular JSON object at most 64 KiB. Allowed fields: channels (object with only whatsapp and sms, each a real JSON boolean), channelOrder (array of whatsapp/sms), allowedCountries (array of two-letter country strings), smsFallback (real JSON boolean). At least one field is required; extra fields and wrong shapes are refused before login. Omitted fields stay unchanged; explicit empty arrays are preserved. A supplied channelOrder or allowedCountries replaces the whole stored list. The server deduplicates order and uppercases/deduplicates countries. allowedCountries is the WhatsApp routing destination allowlist: channel selection excludes other countries, and an empty list selects no WhatsApp destinations. New utility pipelines default to EG, SA, AE, KW, QA, BH and OM. Read current values first with akedly pipelines get <id> --fields data.utilityConfig.channels,data.utilityConfig.channelOrder,data.utilityConfig.allowedCountries,data.utilityConfig.smsFallback; the write response returns those four resulting values. Enabling WhatsApp requires an active WABA; enabling SMS or SMS fallback requires eligible BYO-SMS. By default, newly enabling WhatsApp without countries or clearing its last countries is refused with WHATSAPP_REQUIRES_ALLOWED_COUNTRIES. This configures future sends without sending. Read-only logins are refused. --dry-run prints the validated request without contacting the server.
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 CLI scenario
control which utility channels and destinations a pipeline can use for future requests.
akedly utilities pipelines channels set 64b000000000000000000001 --file channels.json
Input file: channels.json (json).
{
"channels": {
"whatsapp": true
},
"allowedCountries": [
"EG"
]
}
Illustrative response (sensitive values omitted):
{
"status": "success",
"data": {
"channels": {
"whatsapp": true,
"sms": false
},
"channelOrder": [
"whatsapp"
],
"allowedCountries": [
"EG"
],
"smsFallback": false
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities pipelines channels set <id> --file <path>
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
Update only supplied utility channel settings from required --file, a regular JSON object at most 64 KiB. Allowed fields: channels (object with only whatsapp and sms, each a real JSON boolean), channelOrder (array of whatsapp/sms), allowedCountries (array of two-letter country strings), smsFallback (real JSON boolean). At least one field is required; extra fields and wrong shapes are refused before login. Omitted fields stay unchanged; explicit empty arrays are preserved. A supplied channelOrder or allowedCountries replaces the whole stored list. The server deduplicates order and uppercases/deduplicates countries. allowedCountries is the WhatsApp routing destination allowlist: channel selection excludes other countries, and an empty list selects no WhatsApp destinations. New utility pipelines default to EG, SA, AE, KW, QA, BH and OM. Read current values first with akedly pipelines get <id> --fields data.utilityConfig.channels,data.utilityConfig.channelOrder,data.utilityConfig.allowedCountries,data.utilityConfig.smsFallback; the write response returns those four resulting values. Enabling WhatsApp requires an active WABA; enabling SMS or SMS fallback requires eligible BYO-SMS. By default, newly enabling WhatsApp without countries or clearing its last countries is refused with WHATSAPP_REQUIRES_ALLOWED_COUNTRIES. This configures future sends without sending. Read-only logins are refused. --dry-run prints the validated request without contacting the server.
Response fields outside the modeled stable fields may be passed through from the server.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
channelOrder contains strings (`whatsapp`/`sms`); allowedCountries contains uppercase ISO alpha-2 country strings.
Own recovery guidance
| Code | Hint |
|---|---|
| NO_CHANNEL_ENABLED | Enable at least one of channels.whatsapp or channels.sms in --file. |
| WHATSAPP_REQUIRES_WABA | Connect an active WhatsApp Business Account before enabling WhatsApp; check akedly whatsapp status. |
| UTILITY_SMS_REQUIRES_BYO | Connect, test and activate an eligible BYO-SMS integration for this pipeline before enabling SMS or SMS fallback. Check integrations with akedly byo-sms list, and allow BYO-SMS on this pipeline with akedly pipelines update <id> --byo-sms on --yes (inherit follows the account setting, which Akedly sets). |
| INVALID_CHANNEL_ORDER | Use a channelOrder array containing only whatsapp and/or sms. |
| INVALID_ALLOWED_COUNTRIES | Use an allowedCountries array of ISO-3166 alpha-2 country codes. |
| WHATSAPP_REQUIRES_ALLOWED_COUNTRIES | Add at least one allowedCountries code, or turn WhatsApp off in --file. |
utilities pipelines settings set
set or remove a utility pipeline daily spending cap in EGP to bound future send spend.
When to use
- set or remove a utility pipeline daily spending cap in EGP to bound future send spend.
How it works
- Write one positive finite cap or clear existing cap; clear needs confirmation. Uses server-local calendar day.
Prerequisites
- Authenticated account with utilities:update permission.
- An owned utility pipeline; exactly one of positive
--daily-spend-cap-egpor--clear. Clearing also requires--yes.
Expected outcome
Returns updated utility pipeline settings.
Next steps
- Read back through pipelines get; sends at/over cap can be refused.
Usage
akedly utilities pipelines settings set <id>
Inspect this command offline before preparing an operation:
akedly describe "utilities pipelines settings set" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use an owned utility pipeline id from akedly pipelines list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--daily-spend-cap-egp | number | — | Command-specific option; see the full command details below. Manifest body field: dailySpendCapEGP. |
--clear | boolean switch | — | Command-specific option; see the full command details below. Manifest body field: dailySpendCapEGP. |
--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: utilities:update.
Server request: PUT /utilities/pipelines/:id/settings.
Consent
--yes when --clear 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
Set the utility pipeline daily spending cap in EGP with a positive decimal (for example 100 or 0.5; no exponent) --daily-spend-cap-egp, or remove it with --clear --yes. Pass exactly one of --daily-spend-cap-egp or --clear. Setting a cap does not require --yes; clearing removes this protection and requires confirmation. The request contains dailySpendCapEGP as a number or null. This changes future sending limits without sending. Read-only logins are refused. --dry-run prints the validated request without contacting the server. Read the saved cap with akedly pipelines get <id> --fields data.utilityConfig.dailySpendCapEGP. The cap uses server-local calendar days starting at midnight, not a rolling 24-hour window. Paid sends at the cap, or whose reserved charge would exceed it, are refused with SPEND_CAP_EXCEEDED.
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 CLI scenario
set or remove a utility pipeline daily spending cap in EGP to bound future send spend.
akedly utilities pipelines settings set 64b000000000000000000001 --daily-spend-cap-egp 100
Illustrative response (sensitive values omitted):
{
"status": "success",
"data": {
"dailySpendCapEGP": 100
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities pipelines settings set <id> --daily-spend-cap-egp 100
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
Set the utility pipeline daily spending cap in EGP with a positive decimal (for example 100 or 0.5; no exponent) --daily-spend-cap-egp, or remove it with --clear --yes. Pass exactly one of --daily-spend-cap-egp or --clear. Setting a cap does not require --yes; clearing removes this protection and requires confirmation. The request contains dailySpendCapEGP as a number or null. This changes future sending limits without sending. Read-only logins are refused. --dry-run prints the validated request without contacting the server. Read the saved cap with akedly pipelines get <id> --fields data.utilityConfig.dailySpendCapEGP. The cap uses server-local calendar days starting at midnight, not a rolling 24-hour window. Paid sends at the cap, or whose reserved charge would exceed it, are refused with SPEND_CAP_EXCEEDED.
Response fields outside the modeled stable fields may be passed through from the server.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
Own recovery guidance
| Code | Hint |
|---|---|
| INVALID_SPEND_CAP | Pass a positive decimal (for example 100 or 0.5; no exponent) --daily-spend-cap-egp, or --clear --yes to remove the cap. |
| NO_SETTINGS | Pass exactly one of --daily-spend-cap-egp or --clear. |
utilities pipelines signing-secret reveal
retrieve the secret your integration uses to HMAC-sign incoming Utilities API requests.
When to use
- retrieve the secret your integration uses to HMAC-sign incoming Utilities API requests.
How it works
- Reveal initializes a missing secret; preferably write it to a newly reserved mode-0600 file. Revealed secret is not webhook signing secret.
Prerequisites
- Authenticated account with utilities:update permission.
- An owned utility pipeline; choose a new path for
--secret-filebecause output files are exclusive-create.
Expected outcome
Returns secret once until acknowledged, or writes it to the requested file and omits it from stdout.
Next steps
- Deploy it to the client integration, then acknowledge possession; protect output and never paste secret into logs.
Usage
akedly utilities pipelines signing-secret reveal <id>
Inspect this command offline before preparing an operation:
akedly describe "utilities pipelines signing-secret reveal" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use an owned utility pipeline id from akedly pipelines list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--secret-file | text | — | Write the secret to a new mode 0600 file and omit it from output; an existing path is refused. |
--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: utilities:update.
Server request: GET /utilities/pipelines/:id/signing-secret.
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
Sensitive output: secret-sink. Use the supported sink; default output may contain a secret. Supported sinks: --secret-file.
Full command details
Reveal the utility request-signing secret until acknowledged; if absent, the server initializes it. This usk_ secret signs incoming Utilities requests, not outgoing webhook callbacks (which use pipelines webhook-secret). Your backend uses it as-is as the HMAC-SHA256 key when signing Utilities API requests it sends to Akedly with x-akedly-timestamp, x-akedly-nonce and x-akedly-signature headers. Signing is on by default; while enabled, /utilities/send refuses requests until a secret exists. By default it is printed in JSON; --secret-file <new path> exclusively reserves a mode 0600 file before the request, saves the secret there and removes it from output. Existing paths are refused. Prefer --secret-file; stdout can be captured in agent transcripts and logs. Read-only logins are refused. --dry-run prints the request without contacting the server or writing a file.
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 protected file-sink flow
retrieve the secret your integration uses to HMAC-sign incoming Utilities API requests.
akedly utilities pipelines signing-secret reveal 64b000000000000000000001 --secret-file ./signing-secret.txt
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Copy this secret now — it will not be shown again until you regenerate.",
"data": {
"secretFile": "./signing-secret.txt"
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities pipelines signing-secret reveal <id> --secret-file <new path>
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
Reveal the utility request-signing secret until acknowledged; if absent, the server initializes it. This usk_ secret signs incoming Utilities requests, not outgoing webhook callbacks (which use pipelines webhook-secret). Your backend uses it as-is as the HMAC-SHA256 key when signing Utilities API requests it sends to Akedly with x-akedly-timestamp, x-akedly-nonce and x-akedly-signature headers. Signing is on by default; while enabled, /utilities/send refuses requests until a secret exists. By default it is printed in JSON; --secret-file <new path> exclusively reserves a mode 0600 file before the request, saves the secret there and removes it from output. Existing paths are refused. Prefer --secret-file; stdout can be captured in agent transcripts and logs. Read-only logins are refused. --dry-run prints the request without contacting the server or writing a file.
Response fields outside the modeled stable fields may be passed through from the server.
Worked example uses the file sink so it contains no secret value. Never copy raw stdout into logs.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
Worked example uses an exclusive mode-0600 file sink and deliberately contains no secret value. The file is created before the request; an existing path is refused.
utilities pipelines signing-secret acknowledge
record that the integration operator has safely stored the current signing secret, preventing another reveal.
When to use
- record that the integration operator has safely stored the current signing secret, preventing another reveal.
How it works
- Send only the four-character suffix from saved secret file or explicit suffix; full secret is never fetched. Requires confirmation.
Prerequisites
- Authenticated account with utilities:update permission.
- Writable owner account and explicit confirmation where required.
- An owned utility pipeline and current secret; supply exactly one of suffix or saved secret file and
--yes.
Expected outcome
A success message confirming the secret is acknowledged, or already acknowledged; response has no data object.
Next steps
- Keep the secret in its secure runtime store; regenerate only as a coordinated rotation.
Usage
akedly utilities pipelines signing-secret acknowledge <id>
Inspect this command offline before preparing an operation:
akedly describe "utilities pipelines signing-secret acknowledge" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use an owned utility pipeline id from akedly pipelines list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--secret-file | text | — | Command-specific option; see the full command details below. Manifest body field: secretSuffix. |
--secret-suffix | text | — | Command-specific option; see the full command details below. Manifest body field: secretSuffix. |
--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: utilities:update.
Server request: POST /utilities/pipelines/:id/signing-secret/acknowledge.
Consent
--yes. --dry-run bypasses confirmation where supported. Destructive: true. Spends money: false. Real send: false.
Retry
idempotent: Idempotent requests retry network errors and HTTP 429/502/503/504, at most 3 tries, waiting for cooldownSeconds, retryAfter or the Retry-After header (otherwise 1 second) between tries, up to 30 seconds; a longer requested wait is returned as the error.
Output
Output: data. API output is pass-through server data unless the command details describe a CLI shape. Local commands, composites and hand-offs use their documented CLI shapes.
Full command details
Acknowledge holding the utility request-signing secret with --yes and exactly one saved --secret-file or --secret-suffix containing four non-whitespace characters. Only secretSuffix is sent; the full secret is never fetched. By default, the server refuses a missing or wrong suffix from the CLI. Already acknowledged is a successful no-op. Acknowledgement prevents further reveal until regeneration; a concurrent rotation refuses this acknowledgement without marking the new secret acknowledged. Read-only logins are refused. --dry-run validates and prints the masked request without contacting the server or writing a file.
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 CLI scenario
record that the integration operator has safely stored the current signing secret, preventing another reveal.
akedly utilities pipelines signing-secret acknowledge 64b000000000000000000001 --secret-suffix ABCD --yes
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Secret acknowledged"
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Acknowledge a saved utility request-signing secret
Record that the integration receiver has safely saved the current utility request-signing secret; the command reads the file locally and sends only its final four characters.
akedly utilities pipelines signing-secret acknowledge 64b000000000000000000001 --secret-file ./saved-utility-signing-secret.txt --yes
Input file: ./saved-utility-signing-secret.txt (text).
[REDACTED — use your privately saved secret file]
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Secret acknowledged"
}
This is a synthetic secret for private contract validation only; do not execute this sample or render its file content into a human guide.
The CLI sends only `secretSuffix`; it never sends the whole secret. The API success response contains status and message only, with no data object.
Acknowledging the current saved secret is different from rotating it. Regenerate only when coordinating an immediate consumer secret replacement.
Additional command forms
akedly utilities pipelines signing-secret acknowledge <id> --secret-file <saved path> --yes
akedly utilities pipelines signing-secret acknowledge <id> --secret-suffix <last 4 characters> --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
Acknowledge holding the utility request-signing secret with --yes and exactly one saved --secret-file or --secret-suffix containing four non-whitespace characters. Only secretSuffix is sent; the full secret is never fetched. By default, the server refuses a missing or wrong suffix from the CLI. Already acknowledged is a successful no-op. Acknowledgement prevents further reveal until regeneration; a concurrent rotation refuses this acknowledgement without marking the new secret acknowledged. Read-only logins are refused. --dry-run validates and prints the masked request without contacting the server or writing a file.
Response fields outside the modeled stable fields may be passed through from the server.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
The API and CLI return status/message only; there is no data object or acknowledged boolean.
utilities pipelines signing-secret regenerate
rotate the request-signing secret after planned credential rotation or suspected exposure.
When to use
- rotate the request-signing secret after planned credential rotation or suspected exposure.
How it works
- Immediately invalidate old secret, reset acknowledgement and return/store new secret. Requires confirmation; no grace period.
Prerequisites
- Authenticated account with utilities:rotate permission.
- Writable owner account and explicit confirmation where required.
- An owned utility pipeline; coordinate the consumer rollout because old secret becomes invalid immediately;
--yes.
Expected outcome
Returns newly generated secret once or writes it to a new mode-0600 file.
Next steps
- Deploy new secret before sending signed API requests; if response is ambiguous, reveal current secret to a new private file.
Usage
akedly utilities pipelines signing-secret regenerate <id>
Inspect this command offline before preparing an operation:
akedly describe "utilities pipelines signing-secret regenerate" --output json
| Positional | Grammar | Usage guidance |
|---|---|---|
| <id> | ^[a-fA-F0-9]{24}$ | Use an owned utility pipeline id from akedly pipelines list. |
Flags
| Flag | Type | Enum / range | Description |
|---|---|---|---|
--ksa | boolean switch | — | Select the KSA deployment. |
--secret-file | text | — | Write the secret to a new mode 0600 file and omit it from output; an existing path is refused. |
--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: utilities:rotate.
Server request: POST /utilities/pipelines/:id/signing-secret/regenerate.
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
Sensitive output: secret-sink. Use the supported sink; default output may contain a secret. Supported sinks: --secret-file.
Full command details
Rotate the utility request-signing secret with --yes. The old secret stops immediately with no grace period, and acknowledgement resets. Requests signed with the old secret will fail until the new secret is deployed. By default the new secret is printed in JSON; --secret-file <new path> exclusively reserves a mode 0600 file before the request and suppresses it from output. An ambiguous network or server failure is not retried; reveal the current secret to a new file before doing anything else. Prefer --secret-file; stdout can be captured in agent transcripts and logs. Read-only logins are refused. --dry-run prints the request without contacting the server or writing a file. A lost rotation response can mean the old secret already fails; reveal the current secret to a new private file and deploy it before signing requests.
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 protected file-sink flow
rotate the request-signing secret after planned credential rotation or suspected exposure.
akedly utilities pipelines signing-secret regenerate 64b000000000000000000001 --yes --secret-file ./new-signing-secret.txt
Illustrative response (sensitive values omitted):
{
"status": "success",
"message": "Secret regenerated.",
"data": {
"secretFile": "./new-signing-secret.txt"
}
}
Resource identifiers and records are fictional prerequisites, not claims that these resources exist.
Additional command forms
akedly utilities pipelines signing-secret regenerate <id> --secret-file <new path> --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
Rotate the utility request-signing secret with --yes. The old secret stops immediately with no grace period, and acknowledgement resets. Requests signed with the old secret will fail until the new secret is deployed. By default the new secret is printed in JSON; --secret-file <new path> exclusively reserves a mode 0600 file before the request and suppresses it from output. An ambiguous network or server failure is not retried; reveal the current secret to a new file before doing anything else. Prefer --secret-file; stdout can be captured in agent transcripts and logs. Read-only logins are refused. --dry-run prints the request without contacting the server or writing a file. A lost rotation response can mean the old secret already fails; reveal the current secret to a new private file and deploy it before signing requests.
Response fields outside the modeled stable fields may be passed through from the server.
Worked example uses the file sink so it contains no secret value. Never copy raw stdout into logs.
The API response envelope is preserved by the CLI; stable fields are modeled and other server fields remain extensible.
Worked example uses an exclusive mode-0600 file sink and deliberately contains no secret value. The file is created before the request; an existing path is refused.
