---
title: "Accept Update Capability"
method: POST
path: "/api/marketplace/capabilities/{object_id}/accept-update"
tags: ["marketplace"]
---

# Accept Update Capability

`POST /api/marketplace/capabilities/{object_id}/accept-update`

## Request

- Base URL: `https://app.thinqos.com` (the document declares no server; this is the origin it was published from)
- URL: `https://app.thinqos.com/api/marketplace/capabilities/{object_id}/accept-update`
- Auth: none declared

Take the held-back update on one capability (TOS-6779).

TOS-3760 shipped the accept path for skills only (``POST /api/skills/{id}/
accept-update``); connections got held-back DETECTION in TOS-5024 but no
release, so a holder whose consent baseline fell behind the current
version saw "v3 is waiting on you" and no way to say yes. This is the
generic route, dispatched through the registry like acquire/release so the
endpoint stays type-agnostic (the module-import guard forbids naming a
per-type module here).

A CONSENT-WIDENING write, so it carries the same contract the skill
endpoint established: no request body, because the only thing a caller
could put in one is the permission set being approved, and the server must
recompute that from the object rather than take it from a client that
might be stale. The type's executor recomputes the delta through the same
``held_back`` decision the runtime serves, so what the UI showed and what
this grants cannot disagree.

404 when the caller holds nothing here; 409 when nothing is held back, so
a double-click cannot silently re-consent to a version that has moved on
underneath the dialog.

## Path parameters

- `object_id` string, uuid, required

## Headers

- `x-impersonate-identity-id` string, nullable

## Response `204`

Successful Response

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/thinqos/apis/thinqos-api.md) · [All operations](https://skmtc.dev/thinqos/apis/thinqos-api/llms.txt) · [OpenAPI document](https://skmtc.dev/thinqos/apis/thinqos-api/revisions/5387b4ded614?raw)