l4 rec reject

l4 rec reject records a reject decision on a savings recommendation. The recommendation's status becomes rejected. The reason is optional, and you can add or change it later in the dashboard.

l4 rec reject <id> [flags]

rec and recs are aliases for recommendations.

What it changes

The command posts to /api/v1/recommendations/{id}/decision with {"decision": "rejected"} plus the --reason and --explanation values you passed. On the recommendation:

status becomes rejected
saving_acceptance becomes rejected, stamped with your identity and the time
rejection_reason and rejection_explanation are set when you pass them, and stay null when you do not
if a member had requested execution and left the recommendation awaiting approval, the reject resolves that request

Flags

Flag	Description
`--reason <r>`	One of `operational`, `strategy`, `not_applicable`, `other`. Optional
`--explanation <text>`	Free-text explanation, used when `--reason` is `other`
`--yes` / `-y`	Skip the confirmation prompt

l4 checks --reason before it sends anything. A value outside that set fails locally, and the error prints the ones it accepts. The API enforces the same set.

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

Confirmation

By default the command prompts before sending:

Reject 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.

Two things send the decision with no prompt: --yes, and a stdout that is not a TTY. A piped or scheduled run closes the recommendation without asking, so check the id before you put this in a pipeline or a CI job.

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 reject REC-1234
l4 rec reject REC-1234 --reason operational
l4 rec reject REC-1234 --reason other --explanation "Owned by a team that is migrating off"
l4 rec reject REC-1234 --reason not_applicable --yes --json

Output

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

Recommendation REC-1234 rejected
Reason         operational

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

.success
.data.recommendation_id
.data.saving_acceptance          # "rejected"
.data.status                     # "rejected"
.data.rejection_reason
.data.rejection_explanation
.timestamp

Recommendation REC-1234 rejected is the proof the decision landed. Find the recommendation again with l4 rec list --status rejected.

Errors

Exit	Symptom	Cause
`4`	Authentication required	No token resolvable; run `l4 auth login` or set `LEVELFOUR_TOKEN`
`1`	`invalid --reason`	The value is not one of the reasons the API accepts
`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 accept: 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 reject

On this page