l4 rec reject
l4 rec reject records a reject decision on a savings recommendation. The recommendation's status becomes rejected and it drops out of the pipeline. The reason is optional and can be added or changed later in the dashboard.
l4 rec reject <id> [flags]rec is an alias for recommendations, so l4 recommendations reject and l4 recs reject do the same thing.
What it changes
The command posts to /api/v1/recommendations/{id}/decision with {"decision": "rejected"} plus whatever reason you supply. On the recommendation:
statusbecomesrejectedsaving_acceptancebecomesrejected, stamped with your identity and the timerejection_reasonandrejection_explanationare set when you pass them, and staynullwhen 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 |
An unrecognized --reason is rejected locally before any request is sent, with the list of valid values. 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:
Reject recommendation REC-1234? [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. 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 --jsonOutput
Default output is a success line plus the fields the API returned:
Recommendation REC-1234 rejected
Reason operationalWith --json, the API envelope is printed as-is:
.success
.data.recommendation_id
.data.saving_acceptance # "rejected"
.data.status # "rejected"
.data.rejection_reason
.data.rejection_explanation
.timestampErrors
| 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 four 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 |
Related
l4 rec accept- the other half of the decisionl4 rec execute- request execution of an accepted recommendationl4 recommendations- list and view recommendations