`POST /api/proposals/{id}/approve` -- approve + apply + materialize. Returns the applied proposal with `apply_result` describing what landed; records an audit event with the materialized resource id.
const url = 'https://example.com/api/proposals/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/approve';const options = {method: 'POST'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://example.com/api/proposals/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/approveParameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Responses
Section titled “Responses”One proposal on the wire. A presentation view over the row; payload is
passed through as-is so the inbox can render the proposed diff.
object
The target App, surfaced under the frontend’s app_id name (the row
stores it as the generic target_id). Only app.file_upsert carries one.
What an approve materialized ({ kind, resource_id }). Populated on the
approve response; null on list/get reads.
The proposing agent task id (when proposer_kind == "agent"); null for
a user-raised proposal.
Reviewer’s reject note. Not persisted on the row (it lives in the audit
trail), so it is null on reads.
Human one-liner derived from kind + payload (e.g. the script name or
“3 files”), so the inbox list reads without parsing the payload itself.
Examplegenerated
{ "app_id": "2489E9AD-2EE2-8E00-8EC9-32D5F69181C0", "applied_at": "2026-04-15T12:00:00Z", "apply_result": "example", "created_at": "2026-04-15T12:00:00Z", "created_by_task": "example", "expires_at": "2026-04-15T12:00:00Z", "id": "2489E9AD-2EE2-8E00-8EC9-32D5F69181C0", "kind": "example", "payload": "example", "review_note": "example", "reviewed_at": "2026-04-15T12:00:00Z", "reviewed_by": "example", "status": "example", "title": "example", "workspace_id": "2489E9AD-2EE2-8E00-8EC9-32D5F69181C0"}A proposed app-file is stale: its if_match etag no longer matches the current version, so the whole proposal is rejected
The canonical JSON body of every error response — the single source of truth
the frontend binds to. Every AppError serializes as this exact shape, and
the generated OpenAPI component ApiErrorBody (with its ErrorCode enum) is
what the frontend error schema is generated from, so there is no hand-written
error schema on either end.
object
Machine-readable, stable error code.
Present only on a quota-exceeded 403 — the inline upgrade-CTA payload.
object
The entitlement feature key that was hit, e.g. apps.max_count.
The plan’s limit for this key.
Where to send the user to upgrade.
Current usage (count or bytes, per the key).
Human-readable message (the server’s English text; the client may localize
by code).
Example
{ "code": "not_found"}