l4 rec execute

l4 rec execute requests execution of a savings recommendation that has already been accepted. It records the implementation method and marks the rollout in progress. The rollout itself runs server-side.

l4 rec execute <id> [flags]

rec is an alias for recommendations, so l4 recommendations execute and l4 recs execute do the same thing.

What it changes

The command posts to /api/v1/recommendations/audit/execution-requests with the recommendation id and the chosen implementation_method. On the recommendation:

• implementation_status becomes in_progress, while status stays pending, so the dashboard keeps the recommendation under Pending with the Implementation column live
• implementation_method is set to the value you passed
• the dashboard's Triggered Via card records the method plus saving_accepted_by, meaning whoever accepted the recommendation, not the credential that ran this command

Accept the recommendation first with l4 rec accept. Connecting the Automated Savings grant, which is what lets the one-click methods touch your cloud account, happens in the dashboard and cannot be done from the CLI.

Flags

An unrecognized --method is rejected locally before any request is sent. The API enforces the same four values.

Global flags (--json, --jq, --template, --quiet, --token, --api) apply. See CLI overview.

Confirmation

By default the command prompts before sending, and the prompt names the method:

Execute recommendation REC-1234 using the one-click method? [y/N]:

Anything other than y or yes aborts, prints Aborted., and exits 0 without calling the API. When stdout is not a TTY the prompt is skipped and the write proceeds. Pass --yes to skip it in an interactive shell.

Requires a read-write key

The endpoint requires the read-write scope. l4 auth login mints a read-only key, so create a Read & write key in the dashboard under Settings > API Keys. See CLI authentication.

Each invocation sends its own Idempotency-Key, which lets the API discard a duplicate delivery of the same request. Re-running execute does not start a second rollout either: the server only sets implementation_status when it is not already set.

Examples

l4 rec execute REC-1234
l4 rec execute REC-1234 --method iac
l4 rec execute REC-1234 --method manual --yes
l4 rec execute REC-1234 --json

Accept and execute in one step:

l4 rec accept REC-1234 --yes && l4 rec execute REC-1234 --method one-click --yes

Output

Default output is a success line plus the fields the API returned:

Execution requested for recommendation REC-1234
Status    processing
Method    one-click

With --json, the API envelope is printed as-is:

.success
.data.recommendation_id
.data.status                     # "processing"
.data.implementation_method
.timestamp

Track the rollout with l4 recommendations view <id>, or in the dashboard under Status & Logs.

Errors

Related

• l4 rec accept - accept before executing
• l4 rec reject - reject instead
• l4 recommendations - list and view recommendations