l4 rec accept

l4 rec accept records an accept decision on a savings recommendation. It moves the recommendation out of the Available bucket and into Pending, stamps who accepted it and when, and leaves it ready to execute.

l4 rec accept <id> [flags]

rec and recs are aliases for recommendations.

Nothing is applied in your cloud account. Accepting records a decision. l4 rec execute is what starts the change.

What it changes

The command posts to /api/v1/recommendations/{id}/decision with {"decision": "accepted"}. On the recommendation:

saving_acceptance becomes accepted
saving_accepted_by and saving_accepted_at are stamped from the credential
status itself stays pending, so the dashboard shows the recommendation under Pending rather than Available
if a member requested execution and the recommendation is waiting on an approver, accepting it resolves that request and records you as the approver

Flags

Flag	Description
`--yes` / `-y`	Skip the confirmation prompt

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

Confirmation

By default the command prompts before sending:

Accept recommendation REC-1234? [y/N]:

Anything other than y or yes aborts, prints Aborted., and exits 0 without calling the API. Pass --yes to skip the prompt in an interactive shell.

When stdout is not a TTY, so in a pipeline or a CI job, the prompt never appears and the write goes through. That stops a scripted run blocking on input that will not arrive, and it also means every id you pipe in is accepted with nothing to confirm.

Requires a read-write key

The endpoint requires the read-write scope, and l4 auth login mints a read-only key. See CLI authentication for how to create one that has it.

Re-running it

Each invocation sends its own Idempotency-Key, which lets the API discard a duplicate delivery of the same request. A deliberate re-run is a new request: it re-stamps the same decision fields and adds another entry to the recommendation's audit timeline.

Examples

l4 rec accept REC-1234
l4 rec accept REC-1234 --yes
l4 rec accept REC-1234 --json
LEVELFOUR_TOKEN=$L4_RW_KEY l4 rec accept REC-1234 --yes --quiet

Accept the available recommendations above a savings threshold, one page of results per run:

l4 rec list --status available --page-size 100 --jq '.data.data.items[] | select(.monthly_savings > 500) | .recommendation_id' \
  | xargs -I{} l4 rec accept {} --yes

Output

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

Recommendation REC-1234 accepted
By    api-key:00000000-0000-0000-0000-000000000000
At    2026-08-22

An API key stamps saving_accepted_by as api-key:<key id>, the UUID of the key that made the call. The same decision made in the dashboard stamps the signed-in user's email instead.

With --json the whole API envelope is printed. The fields it carries:

.success
.data.recommendation_id
.data.saving_acceptance          # "accepted"
.data.saving_accepted_by
.data.saving_accepted_at
.data.status                     # "pending"
.timestamp

saving_acceptance reading accepted is the confirmation the decision landed. status staying pending is the expected result, not a failed write.

Errors

Exit	Symptom	Cause
`4`	Authentication required	No token resolvable; run `l4 auth login` or set `LEVELFOUR_TOKEN`
`1`	`401` authentication failed	Token revoked, expired, or from the wrong environment
`1`	`403` permission denied	The key has the `read` scope, or your role lacks `org:savings:execute`
`1`	`404`	No recommendation with that id in this organization

l4 rec reject: the other half of the decision
l4 rec execute: request execution of an accepted recommendation
l4 recommendations: list and view recommendations
CLI authentication: read versus read-write keys

l4 rec accept

On this page