---
title: "Apply All Memory Proposals"
method: POST
path: "/api/memory/proposals/apply_all"
---

# Apply All Memory Proposals

`POST /api/memory/proposals/apply_all`

Batch-apply the given proposal ids in ONE transaction. Any 409
needs_rebase (or a mid-batch failure) rolls the whole batch back so a
partial apply can never leave the queue inconsistent.

Applies in `id ASC` (staging) order regardless of the order `ids` were
submitted in. A single dream pass can stage an `add` for a brand-new
slug followed by an `update` against that same in-pass slug (see the
same-pass slug reservation in memory_consolidate.py's `_run`) — the
update's target only exists once the add is applied first, and staging
always assigns the add a lower id (later batches see earlier batches'
reservations, never the reverse). Trusting the client's array order
instead let a UI that lists proposals update-before-add send that pair
reversed, 409 on the very first item, and roll back the WHOLE batch —
so "approve all" could never succeed even though every individual
proposal was independently applicable in the right order.

## Headers

- `authorization` string, nullable

## Response `200`

Successful Response

- object

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/omicos/apis/omicos-server.md) · [All operations](https://skmtc.dev/omicos/apis/omicos-server/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/omicos/omicos-server/revisions/a00b94573ffe/schema)