Skip to content
Akedly
Command reference

WhatsApp

Akedly CLI command reference: WhatsApp.

whatsapp connect

Connect a customer-owned WABA through Meta embedded signup. Connection confirmation is not phone registration, business verification, or send readiness.

When to use

  • Connect or refresh a WABA; use --wait for the supported 10-second status poll.

How it works

  1. Reads the baseline WhatsApp status, then prints the dashboard signup link. With --wait it polls status every ten seconds until account linkage/onboarding changes or timeout; it cannot observe abandoned/failed Meta onboarding.

Prerequisites

  • Browser access to complete Meta signup.

Expected outcome

A handoff URL, and optionally confirmed account-linkage change.

Next steps

  • Complete signup, then inspect status and diagnose; finish number, business, billing and template readiness.

Usage

sh
akedly whatsapp connect

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp connect" --output json

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--waitboolean switch—Command-specific option; see the full command details below.
--timeoutseconds—Command-specific option; see the full command details below.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Dashboard path: /admin/whatsapp-connect. Status check: whatsapp status.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Print the dashboard WhatsApp sign-up link without opening a browser. Optionally --wait polls whatsapp status, which calls Meta, every ten seconds; the wait defaults to ten minutes and --timeout sets it. Completion confirms only an account connection or refreshed onboarding, not registered numbers, business verification or sending readiness; check akedly whatsapp status and akedly whatsapp diagnose. An already connected account without new onboarding times out. The CLI cannot see abandoned or failed Meta onboarding. For multiple numbers use akedly whatsapp set-primary.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Connect or refresh a WABA; use --wait for the supported 10-second status poll.

sh
akedly whatsapp connect

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "handoff": {
      "action": "whatsapp connect",
      "path": "/admin/whatsapp-connect",
      "url": "https://app.akedly.io/admin/whatsapp-connect",
      "requested": "Connect WhatsApp in the dashboard."
    }
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp connect --wait

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

This is the CLI handoff document, not a Meta API response. --wait adds waited outcome/polls/elapsedSeconds after observed connection change; a timeout is an error.

Examples are synthetic and do not establish that the dashboard signup was completed.

Common error guidance.

whatsapp status

Read live connected WABA state, phone inventory and setup checklist; connected is account-level, not sending readiness.

When to use

  • After signup, phone sync/primary selection, or uncertain disconnect.

How it works

  1. Fetches Meta account/phone state and refreshes persisted state.

Prerequisites

  • Account login; absence of a WABA is a valid result.

Expected outcome

Connected state plus phones/checklist, or connected:false.

Next steps

  • Use diagnose for live recommendations and sending-status for DB-only recent attempts.

Usage

sh
akedly whatsapp status

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp status" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Server request: GET /meta-tech-provider/status.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Read the connected account status, phone numbers and setup checklist. This GET calls Meta live and updates stored phone/account state; do not poll it repeatedly yourself; akedly whatsapp connect --wait is the supported poller, every ten seconds. It covers only the connected account and returns connected false when none exists. Read-only logins are supported. connected is account-level only; inspect phone state and setupChecklist for sending readiness.

Login 429 guidance.

Worked examples

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

Synthetic request and response

After signup, phone sync/primary selection, or uncertain disconnect.

sh
akedly whatsapp status

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "connected": false
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp status

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp sending-status

Read persisted own-WABA readiness and recent send outcomes without contacting Meta.

When to use

  • Investigate sending health without refreshing Meta state.

How it works

  1. Reads DB summary capped at ten own-WABA attempts.

Prerequisites

  • Login; WABA may be absent.

Expected outcome

Checklist and recent failure/attempt counters.

Next steps

  • Follow up with status/diagnose for blockers.

Usage

sh
akedly whatsapp sending-status

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp sending-status" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Server request: GET /meta-tech-provider/sending-status.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Read database-only sending readiness and recent own-WABA attempts/failures for the connected account. No live Meta check is made; recent activity is limited to ten own-WABA attempts. Read-only logins are supported.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Investigate sending health without refreshing Meta state.

sh
akedly whatsapp sending-status

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "checklistComplete": false,
    "userWabaId": null,
    "lastMessage": {
      "sentFromOwnWaba": true,
      "deliveryStatus": "failed",
      "fallbackTriggered": false,
      "sentAt": "2026-01-01T00:00:00.000Z"
    },
    "lastSuccessFromOwnWaba": null,
    "recentOwnWabaAttempts": 1,
    "recentRealFailures": 1,
    "recentRecipientFailures": 0,
    "recentFallbacks": 1,
    "failedCodes": [
      {
        "code": "example_sender_error",
        "description": "Sender-side WhatsApp error",
        "count": 1
      }
    ],
    "alertLevel": "warning",
    "hasActivity": true
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp sending-status

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp diagnose

Run live Meta setup checks and actionable recommendations for an active WABA.

When to use

  • After setup changes or unexplained readiness trouble.

How it works

  1. Calls Meta; POST is read-like, no --yes; dry-run makes no calls.

Prerequisites

  • Active connected WABA.

Expected outcome

Health, checks and recommendations.

Next steps

  • Fix blockers and re-check sending-status.

Usage

sh
akedly whatsapp diagnose

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp diagnose" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Server request: POST /meta-tech-provider/diagnose.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Diagnose the connected account with live Meta checks and return recommendations; this POST is read-like and needs no --yes. An active WABA is required. Dry-run makes no calls. Read-only logins are supported.

Login 429 guidance.

Worked examples

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

Synthetic request and response

After setup changes or unexplained readiness trouble.

sh
akedly whatsapp diagnose

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "overallHealth": "yellow",
    "checks": {
      "wabaAccount": {
        "status": "ok",
        "accountStatus": "active"
      },
      "businessVerification": {
        "status": "warning",
        "verificationStatus": "unknown",
        "verificationOutcome": "not_verified"
      },
      "billing": {
        "status": "ok",
        "detail": "No payment-method blocks reported by Meta",
        "metaBillingUrl": "https://business.facebook.com/billing_hub/accounts?asset_id=123456789&placement=whatsapp_ads"
      },
      "phoneNumbers": {
        "status": "ok",
        "details": []
      },
      "template": {
        "status": "warning",
        "templateName": "akedly_otp",
        "templateStatus": "PENDING",
        "sendEligible": false
      },
      "messageDelivery": {
        "status": "ok",
        "recentTotal": 0,
        "failedCount": 0,
        "recipientFailedCount": 0,
        "failedCodes": []
      }
    },
    "recommendations": [
      "Complete Meta Business Verification to unlock full messaging capabilities."
    ]
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp diagnose

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp sync-phone-numbers

Refresh Meta phone inventory; a missing previous primary can move OTP sends to another number or Akedly’s shared number.

When to use

  • After phone changes in Meta.

How it works

  1. Synchronizes Meta results into account phone state.

Prerequisites

  • Active WABA.

Expected outcome

Phone inventory, completeness and optional selection change.

Next steps

  • Review status; set primary if needed.

Usage

sh
akedly whatsapp sync-phone-numbers

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp sync-phone-numbers" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: POST /meta-tech-provider/sync-phone-numbers.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Refresh phone numbers from Meta for the connected active WABA. This can change or clear the selected OTP sending number; review whatsapp status afterwards. No --yes is required. Read-only logins are refused. Use akedly whatsapp set-primary to restore a cleared sending number.

Login 429 guidance.

Worked examples

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

Synthetic request and response

After phone changes in Meta.

sh
akedly whatsapp sync-phone-numbers

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Phone numbers synced successfully",
  "data": {
    "phoneNumbers": [
      {
        "phoneNumberId": "123456789",
        "displayPhoneNumber": "+201234567890",
        "verifiedName": "Example business",
        "qualityRating": "GREEN",
        "status": "CONNECTED",
        "nameStatus": "APPROVED",
        "isActive": true,
        "isPrimary": true,
        "isDefault": false,
        "registrationRetryCount": 0,
        "registeredAt": "2026-01-01T00:00:00.000Z"
      }
    ],
    "complete": true,
    "selectionChanged": null
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp sync-phone-numbers

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp set-primary

Choose the WABA phone used for OTP sends.

When to use

  • Select/restore primary phone after sync or adding a number.

How it works

  1. Checks Meta phoneNumberId belongs to active WABA, then saves primary.

Prerequisites

  • PhoneNumberId from status; active WABA.

Expected outcome

Phone list with primary state.

Next steps

  • Verify status.

Usage

sh
akedly whatsapp set-primary <phoneNumberId>

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp set-primary" --output json
PositionalGrammarUsage guidance
<phoneNumberId>^[0-9]+$Use the phoneNumberId from akedly whatsapp status.

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: PUT /meta-tech-provider/phone-numbers/:phoneNumberId/primary.

Shared server-guard guidance.

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

Select a phone belonging to the connected active WABA as the OTP sending phone. Use the Meta phoneNumberId from whatsapp status, not a Mongo id. Needs --yes because WhatsApp OTP messages start sending from this phone. Read-only logins are refused. A phone not on the connected WABA is refused with HTTP 404: Phone number not found in this WABA.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Select/restore primary phone after sync or adding a number.

sh
akedly whatsapp set-primary 123456789 --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Primary phone number updated",
  "data": {
    "phoneNumbers": [
      {
        "phoneNumberId": "123456789",
        "displayPhoneNumber": "+201234567890",
        "verifiedName": "Example business",
        "qualityRating": "GREEN",
        "status": "CONNECTED",
        "nameStatus": "APPROVED",
        "isActive": true,
        "isPrimary": true,
        "isDefault": false,
        "registrationRetryCount": 0,
        "registeredAt": "2026-01-01T00:00:00.000Z"
      }
    ]
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp set-primary <phoneNumberId> --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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp retry-register-phone

Retry Meta registration with a new random PIN for one connected WABA phone.

When to use

  • Recover a known failed registration; no automatic retries.

How it works

  1. Verifies ownership and retries with Meta.

Prerequisites

  • PhoneNumberId from status; active WABA.

Expected outcome

Registration success for that phone.

Next steps

  • On ambiguous failure inspect status before retry; Meta ownership check unavailable means wait then retry.

Usage

sh
akedly whatsapp retry-register-phone <phoneNumberId>

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp retry-register-phone" --output json
PositionalGrammarUsage guidance
<phoneNumberId>^[0-9]+$Use the phoneNumberId from akedly whatsapp status.

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: POST /meta-tech-provider/retry-register-phone/:phoneNumberId.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Retry registration of a phone belonging to your WABA using a new random PIN through Meta. Uses the Meta phoneNumberId from whatsapp status. No --yes is required; automatic retries are disabled. After an ambiguous failure check whatsapp status before retrying. Read-only logins are refused. If Meta cannot confirm the phone right now, the server answers 503 WABA_PHONE_CHECK_UNAVAILABLE; wait a few minutes and retry. A 404 means the phone is not on this WABA.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Recover a known failed registration; no automatic retries.

sh
akedly whatsapp retry-register-phone 123456789

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "Phone number registered successfully",
  "data": {
    "phoneNumberId": "123456789"
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp retry-register-phone <phoneNumberId>

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp retry-template

Retry missing/unusable built-in OTP language variants without recreating usable variants.

When to use

  • Repair built-in OTP template provisioning.

How it works

  1. Identifies retryable variants and provisions only missing ones.

Prerequisites

  • Connected WABA.

Expected outcome

Per-language results; can be a no-op.

Next steps

  • Inspect language states and status.

Usage

sh
akedly whatsapp retry-template

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp retry-template" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: POST /meta-tech-provider/retry-template.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Retry missing or unusable built-in OTP language variants for the connected account. Existing usable variants are not recreated; if none are missing this is a no-op. Uses Meta provisioning and requires no --yes. Read-only logins are refused.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Repair built-in OTP template provisioning.

sh
akedly whatsapp retry-template

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "All OTP template variants already exist",
  "data": {
    "templateName": "akedly_otp",
    "created": [],
    "templates": [
      {
        "language": "en",
        "ok": true,
        "alreadyPresent": true
      },
      {
        "language": "ar",
        "ok": true,
        "alreadyPresent": true
      }
    ]
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp retry-template

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp disconnect

Remove linked WABA/token and return OTP WhatsApp routing to Akedly’s default number.

When to use

  • Intentionally stop own-WABA usage; destructive, requires consent flag.

How it works

  1. Clears WABA/phone links; no reason field supported.

Prerequisites

  • Connected account and --yes.

Expected outcome

Disconnect result.

Next steps

  • Verify status; reconnect via dashboard handoff if needed.

Usage

sh
akedly whatsapp disconnect

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp disconnect" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: POST /meta-tech-provider/disconnect.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Disconnect the WhatsApp account, clear its access token and remove the user WABA/phone links. Requires --yes. No reason flag is accepted. After an ambiguous failure check whatsapp status before retrying. Read-only logins are refused. OTPs will fall back to Akedly's default WhatsApp number; reconnecting needs the dashboard WhatsApp sign-up (akedly whatsapp connect prints the link).

Login 429 guidance.

Worked examples

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

Synthetic request and response

Intentionally stop own-WABA usage; destructive, requires consent flag.

sh
akedly whatsapp disconnect --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "message": "WhatsApp Business Account disconnected"
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp disconnect --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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp otp-templates library

Discover supported library template names, language and variable defaults.

When to use

  • Before creating a custom OTP template.

How it works

  1. Reads template catalog/options.

Prerequisites

  • Login.

Expected outcome

Library entries and options.

Next steps

  • Use listed libraryName/variables in create.

Usage

sh
akedly whatsapp otp-templates library

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp otp-templates library" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Server request: GET /meta-tech-provider/otp-templates/library.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Read the usable OTP template library entries and options before choosing libraryName, supported languages and variable defaults. Read-only logins are supported.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Before creating a custom OTP template.

sh
akedly whatsapp otp-templates library

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "entries": [
      {
        "libraryName": "verify_code_1",
        "category": "AUTHENTICATION",
        "codeIndex": 1,
        "variables": [],
        "languages": {
          "en": {
            "language": "en",
            "metaLanguage": "en_US",
            "libraryId": "27345159648464169",
            "body": "*{{1}}* is your verification code.",
            "bodyParams": [
              "123456"
            ],
            "bodyParamTypes": [
              "CODE"
            ],
            "example": [
              "123456"
            ],
            "codeIndex": 1,
            "variables": [],
            "preview": {
              "body": "*{{1}}* is your verification code.",
              "bodyParams": [
                "123456"
              ],
              "securityRecommendation": "For your security, do not share this code.",
              "securityRecommendationInBody": false,
              "footerTemplate": "Expires in {{minutes}} minutes.",
              "footer": "Expires in 3 minutes.",
              "button": {
                "type": "OTP",
                "otpType": "COPY_CODE",
                "label": "Copy code"
              },
              "text": "*{{1}}* is your verification code. For your security, do not share this code.\nExpires in 3 minutes."
            }
          },
          "ar": {
            "language": "ar",
            "metaLanguage": "ar",
            "libraryId": "9349571461738867",
            "body": "*{{1}}* هو رمز التحقق الخاص بك.",
            "bodyParams": [
              "123456"
            ],
            "bodyParamTypes": [
              "CODE"
            ],
            "example": [
              "123456"
            ],
            "codeIndex": 1,
            "variables": [],
            "preview": {
              "body": "*{{1}}* هو رمز التحقق الخاص بك.",
              "bodyParams": [
                "123456"
              ],
              "securityRecommendation": "لأسباب تتعلق بأمانك، يرجى عدم مشاركة هذا الرمز.",
              "securityRecommendationInBody": false,
              "footerTemplate": "تنتهي صلاحيتها خلال ‏٣‏ دقائق.",
              "footer": "تنتهي صلاحيتها خلال ‏٣‏ دقائق.",
              "button": {
                "type": "OTP",
                "otpType": "COPY_CODE",
                "label": "نسخ الرمز"
              },
              "text": "*{{1}}* هو رمز التحقق الخاص بك. لأسباب تتعلق بأمانك، يرجى عدم مشاركة هذا الرمز.\nتنتهي صلاحيتها خلال ‏٣‏ دقائق."
            }
          }
        },
        "excluded": {}
      }
    ],
    "options": {
      "securityRecommendation": {
        "default": true,
        "values": [
          true,
          false
        ]
      },
      "expiryMinutes": 3,
      "button": {
        "type": "OTP",
        "otpType": "COPY_CODE"
      }
    }
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp otp-templates library

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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp otp-templates list

Inspect custom/built-in OTP templates, language approval, and current connection.

When to use

  • Find template Mongo id or recover provisioning.

How it works

  1. Reads account template collection.

Prerequisites

  • Login; empty disconnected account is valid.

Expected outcome

Templates and connected state.

Next steps

  • Update only missing languages; attach only approved template.

Usage

sh
akedly whatsapp otp-templates list

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp otp-templates list" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:read.

Server request: GET /meta-tech-provider/otp-templates.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

List your custom OTP templates, built-in default, language approval states and current WABA connection. IDs here are Mongo ids, unlike Meta phoneNumberId. Read-only logins are supported.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Find template Mongo id or recover provisioning.

sh
akedly whatsapp otp-templates list

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "wabaId": null,
    "connected": false,
    "builtInDefault": {
      "id": null,
      "metaName": "akedly_otp_auth",
      "readOnly": true,
      "wabaId": null,
      "languages": [
        {
          "language": "en",
          "metaLanguage": "en_US",
          "status": "NOT_FOUND",
          "templateId": null,
          "metaTemplateId": null
        },
        {
          "language": "ar",
          "metaLanguage": "ar",
          "status": "NOT_FOUND",
          "templateId": null,
          "metaTemplateId": null
        }
      ]
    },
    "templates": []
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp otp-templates 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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Common error guidance.

whatsapp otp-templates create

Create a library-backed customer OTP template and provision requested English/Arabic variants through Meta.

When to use

  • When built-in content is unsuitable and active own WABA exists.

How it works

  1. Validates catalog/defaults, saves template, requests provisioning, then checks approval up to 30 sec without replaying creation.

Prerequisites

  • Active WABA, allowed library/languages/defaults, below 20 active templates.

Expected outcome

The saved template includes one row per requested language. Meta status can remain PENDING when the CLI approval-check window ends; the template is saved and must not be recreated.

Next steps

  • List and update missing languages; do not repeat create; attach after approved.

Usage

sh
akedly whatsapp otp-templates create

Inspect this command offline before preparing an operation:

sh
akedly describe "whatsapp otp-templates create" --output json

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: POST /meta-tech-provider/otp-templates.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Add an OTP template from required --library-name and --languages (unique comma-separated en,ar). Optional --security-recommendation on|off defaults to on, subject to library policy. --defaults-file is a regular JSON object keyed by language then variable name, at most 64 KiB; library defaults apply when omitted. An active own WABA is required; at most 20 non-archived templates per WABA. HTTP 502 TEMPLATE_PROVISIONING_FAILED means the template was saved: list it and recover NOT_FOUND languages with otp-templates update <id> --add-languages en,ar rather than create again. Automatic retries are disabled; no --yes is required. Read-only logins are refused. Run akedly whatsapp otp-templates library to find valid library names and variable names. When adding languages, the CLI checks their approval for up to 30 seconds without repeating the write. If approval is still pending or the status check fails, the saved template is returned successfully and stderr gives its status and the pipeline attach command. A defaults-only update does not wait.

Login 429 guidance.

Worked examples

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

Synthetic request and response

When built-in content is unsuitable and active own WABA exists.

sh
akedly whatsapp otp-templates create --library-name verify_code_1 --languages en,ar

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "template": {
      "id": "64b000000000000000000001",
      "libraryName": "verify_code_1",
      "metaName": "akedly_auth_verify_code_1_abc123",
      "securityRecommendation": true,
      "securityRecommendationInBody": false,
      "languages": [
        {
          "language": "en",
          "metaLanguage": "en_US",
          "status": "PENDING",
          "templateId": "987654321",
          "metaTemplateId": "64b000000000000000000002"
        },
        {
          "language": "ar",
          "metaLanguage": "ar",
          "status": "PENDING",
          "templateId": "987654322",
          "metaTemplateId": "64b000000000000000000003"
        }
      ],
      "variables": [],
      "codeIndex": 1,
      "wabaId": "123456789012345",
      "wabaChanged": false,
      "archivedAt": null,
      "createdAt": "2026-01-01T00:00:00.000Z",
      "updatedAt": "2026-01-01T00:00:00.000Z"
    }
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Create bilingual OTP template with defaults from a JSON file

Use a reviewed library entry and supply English and Arabic purpose text for a newly provisioned template. A connected own WABA and an available template slot are required; this provisions Meta templates, whose approval can remain pending after the CLI wait window. The saved template must be listed and recovered rather than created again.

sh
akedly whatsapp otp-templates create --library-name verify_otp_usecase --languages en,ar --defaults-file ./fixtures/otp-create-defaults.json

Input file: ./fixtures/otp-create-defaults.json (json).

json
{
  "en": {
    "purpose": "sign in"
  },
  "ar": {
    "purpose": "تسجيل الدخول"
  }
}

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "template": {
      "id": "64b000000000000000000001",
      "libraryName": "verify_otp_usecase",
      "metaName": "akedly_auth_verify_otp_usecase_a1b2c3",
      "securityRecommendation": true,
      "securityRecommendationInBody": false,
      "languages": [
        {
          "language": "en",
          "metaLanguage": "en_US",
          "status": "PENDING",
          "templateId": "987654321",
          "metaTemplateId": "64b000000000000000000002"
        },
        {
          "language": "ar",
          "metaLanguage": "ar",
          "status": "PENDING",
          "templateId": "987654322",
          "metaTemplateId": "64b000000000000000000003"
        }
      ],
      "variables": [
        {
          "name": "purpose",
          "index": 2,
          "type": "TEXT",
          "example": "Login",
          "defaults": {
            "en": "sign in",
            "ar": "تسجيل الدخول"
          }
        }
      ],
      "codeIndex": 1,
      "wabaId": "123456789012345",
      "wabaChanged": false,
      "archivedAt": null,
      "createdAt": "2026-01-01T00:00:00.000Z",
      "updatedAt": "2026-01-01T00:00:00.000Z"
    }
  }
}

Synthetic documentation only; this response and file were not submitted to Meta. The example shows PENDING as a valid saved state. The CLI does not need --yes for this command.

Additional command forms

sh
akedly whatsapp otp-templates create --library-name <libraryName> --languages en,ar

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

Custom-template response is serialized from the stored template and Meta language rows; each requested language can remain PENDING or NOT_FOUND when provisioning/approval is incomplete.

Meta approval and the local template record are separate; never treat a saved record as approved or send-ready.

Common error guidance.

whatsapp otp-templates update

Merge variable defaults or provision missing/retryable variants on an existing template.

When to use

  • Recover partial provisioning or change defaults.

How it works

  1. Applies selected defaults or adds languages, checks language approval up to 30 seconds.

Prerequisites

  • Template id; valid library variables; connected WABA for provisioning.

Expected outcome

The saved template includes one row per requested language. Meta status can remain PENDING when the CLI approval-check window ends; the template is saved and must not be recreated.

Next steps

  • List and retry only missing languages; library and security setting are immutable here.

Usage

sh
akedly whatsapp otp-templates update <id>

Inspect this command offline before preparing an operation:

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

Flags

FlagTypeEnum / rangeDescription
--ksaboolean switch—Select the KSA deployment.
--add-languagestext—Command-specific option; see the full command details below. Manifest body field: addLanguages.
--defaults-filetext—Command-specific option; see the full command details below. Manifest body field: defaults.
--dry-runboolean switch—Preview without sending the write or creating output files; planning reads may still occur. Bypass consent.
--helpboolean switch—Show offline command help.
--outputenumjson | humanSelect JSON or human output.
--fieldsdot-paths—Select comma-separated safe dot paths; apply to each element of a root array.

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: PATCH /meta-tech-provider/otp-templates/:id.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Update variable defaults from --defaults-file (regular JSON object keyed by language then variable name, at most 64 KiB), or add unique en,ar languages with --add-languages. Defaults merge with current values; library rules validate fixed variables and requested languages. Existing language variants can be retried only when missing/NOT_FOUND or orphaned; already usable languages are refused. Library name and securityRecommendation cannot be changed here. HTTP 502 TEMPLATE_PROVISIONING_FAILED means changes were saved; list the template and retry failed languages with addLanguages. No --yes is required. Read-only logins are refused. When adding languages, the CLI checks their approval for up to 30 seconds without repeating the write. If approval is still pending or the status check fails, the saved template is returned successfully and stderr gives its status and the pipeline attach command. A defaults-only update does not wait.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Recover partial provisioning or change defaults.

sh
akedly whatsapp otp-templates update 64b000000000000000000001 --add-languages en

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "template": {
      "id": "64b000000000000000000001",
      "libraryName": "verify_code_1",
      "metaName": "akedly_auth_verify_code_1_abc123",
      "securityRecommendation": true,
      "securityRecommendationInBody": false,
      "languages": [
        {
          "language": "en",
          "metaLanguage": "en_US",
          "status": "PENDING",
          "templateId": "987654321",
          "metaTemplateId": "64b000000000000000000002"
        },
        {
          "language": "ar",
          "metaLanguage": "ar",
          "status": "PENDING",
          "templateId": "987654322",
          "metaTemplateId": "64b000000000000000000003"
        }
      ],
      "variables": [],
      "codeIndex": 1,
      "wabaId": "123456789012345",
      "wabaChanged": false,
      "archivedAt": null,
      "createdAt": "2026-01-01T00:00:00.000Z",
      "updatedAt": "2026-01-01T00:00:00.000Z"
    }
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Update existing OTP variable defaults from a JSON file

Revise default purpose wording on an existing verify_otp_usecase template without changing its library, security setting, or language set. The template must belong to the account and the supplied keys must match its supported variables and languages.

sh
akedly whatsapp otp-templates update 64b000000000000000000001 --defaults-file ./fixtures/otp-update-defaults.json

Input file: ./fixtures/otp-update-defaults.json (json).

json
{
  "en": {
    "purpose": "confirm login"
  },
  "ar": {
    "purpose": "تأكيد الهوية"
  }
}

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "data": {
    "template": {
      "id": "64b000000000000000000001",
      "libraryName": "verify_otp_usecase",
      "metaName": "akedly_auth_verify_otp_usecase_a1b2c3",
      "securityRecommendation": true,
      "securityRecommendationInBody": false,
      "languages": [
        {
          "language": "en",
          "metaLanguage": "en_US",
          "status": "APPROVED",
          "templateId": "987654321",
          "metaTemplateId": "64b000000000000000000002"
        },
        {
          "language": "ar",
          "metaLanguage": "ar",
          "status": "APPROVED",
          "templateId": "987654322",
          "metaTemplateId": "64b000000000000000000003"
        }
      ],
      "variables": [
        {
          "name": "purpose",
          "index": 2,
          "type": "TEXT",
          "example": "Login",
          "defaults": {
            "en": "sign in",
            "ar": "تسجيل الدخول"
          }
        }
      ],
      "codeIndex": 1,
      "wabaId": "123456789012345",
      "wabaChanged": false,
      "archivedAt": null,
      "createdAt": "2026-01-01T00:00:00.000Z",
      "updatedAt": "2026-10-30T10:30:00.000Z"
    }
  }
}

Synthetic existing template ID and response; not submitted to Meta. Defaults-only update needs no --yes and does not invoke the approval wait.

Additional command forms

sh
akedly whatsapp otp-templates update <id> --add-languages en

Input and file contracts

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

Response contract

Custom-template response is serialized from the stored template and Meta language rows; each requested language can remain PENDING or NOT_FOUND when provisioning/approval is incomplete.

Meta approval and the local template record are separate; never treat a saved record as approved or send-ready.

Own recovery guidance

CodeHint
TEMPLATE_NOT_FOUNDRun akedly whatsapp otp-templates list and check the template id.

Common error guidance.

whatsapp otp-templates delete

Archive OTP template locally and attempt Meta variant deletion.

When to use

  • Retire unused template; destructive.

How it works

  1. Archives; Meta deletion may independently fail and is exposed in result.

Prerequisites

  • Template id and --yes.

Expected outcome

Archive result and metaDelete outcome.

Next steps

  • Verify list and resolve failed Meta cleanup.

Usage

sh
akedly whatsapp otp-templates delete <id>

Inspect this command offline before preparing an operation:

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

Flags

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

Authentication, permission and guards

Auth: login. Permission: whatsapp:update.

Server request: DELETE /meta-tech-provider/otp-templates/:id.

Shared server-guard guidance.

Consent

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

Retry

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

Output

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

Full command details

Archive your OTP template locally and attempt to delete its Meta variants when the current WABA matches. Requires --yes. A success can still report data.metaDelete.ok false; inspect the returned result. Read-only logins are refused.

Login 429 guidance.

Worked examples

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

Synthetic request and response

Retire unused template; destructive.

sh
akedly whatsapp otp-templates delete 64b000000000000000000001 --yes

Illustrative response (sensitive values omitted):

json
{
  "status": "success",
  "code": "TEMPLATE_ARCHIVED",
  "data": {
    "id": "64b000000000000000000001",
    "archivedAt": "2026-01-01T00:00:00.000Z",
    "metaDelete": {
      "attempted": true,
      "ok": true
    }
  }
}

Example is documentation only and has not been run. Resource ids do not assert existing state.

Keep BYO-SMS output private: visible endpoint/template text may contain literal credentials.

Additional command forms

sh
akedly whatsapp otp-templates 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

Schema describes the stable CLI-visible success envelope and known stable fields. API-owned fields may be added; fields omitted by member visibility or absent resource state may be absent.

Examples are synthetic; resource state, readiness, provider outcome, and fees vary by account.

Own recovery guidance

CodeHint
TEMPLATE_NOT_FOUNDRun akedly whatsapp otp-templates list and check the template id.

Common error guidance.