---
title: "List Capabilities"
method: GET
path: "/api/marketplace/capabilities"
tags: ["marketplace"]
---

# List Capabilities

`GET /api/marketplace/capabilities`

## 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`
- Auth: none declared

The blended capability grid: every visible object, all types at once.

``facets=false`` omits the facet block (TOS-3710). Facets describe the
WHOLE filtered set, so they are identical for every offset of one filter,
and computing them again per page is work whose answer is already on the
client. It stays a flag on this endpoint rather than a second endpoint on
purpose: a separate call would add a round trip to the FIRST paint, which
is the request that is actually slow, to save work on later pages that a
flag saves for free.

## Query parameters

- `q` string: Substring search over name/description/slug
- `type` string, nullable: One family code, or several separated by commas
- `publisher` string, uuid, nullable
- `capability` string, nullable
- `side_effect` string, nullable
- `type_facet` string, nullable: A per-type facet key, e.g. runtime
- `type_facet_value` string, nullable
- `relationship` string: all | my | discover | mine | using
- `listed_only` boolean: Only currently published Marketplace listings
- `ownership` string: all | mine
- `held` string: all | held | not_held
- `slug` string: Comma-separated connection definition slugs to narrow to (the attention deep link, TOS-6556)
- `domain` string, uuid, nullable
- `subtree` boolean
- `min_rating` number, nullable
- `sort` string: relevance | best_match | name | newest | top_rated | most_learned | publisher
- `limit` integer
- `offset` integer
- `facets` boolean: Compute the facet block. Pass false when paging an unchanged filter.
- `needed` string: agents: only what the caller's own agents' tools need and the caller does not hold
- `updates_only` boolean: Only held capabilities with an unresolved consent or permission update
- `org` boolean: Only listings published from an organization the caller belongs to

## Headers

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

## Response `200`

Successful Response

- MarketplaceListOut
  - `updates_total` integer
  - `items` MarketplaceCapabilityOut[]
    - `id` string, uuid, required
    - `type_code` string, required
    - `slug` string, required
    - `name` string, required
    - `description` string, required
    - `publisher` string, nullable
    - `publisher_id` string, uuid, nullable
    - `origin` string, required
    - `source_kind` string, required
    - `visibility` string, required
    - `current_version_id` string, uuid, nullable
    - `current_version_no` integer, nullable
    - `current_upstream_version` string, nullable
    - `capabilities` string[]
    - `side_effects` string[]
    - `domain_ids` string[]
    - `domain_names` string[]
    - `rating_avg` number, nullable
    - `rating_count` integer
    - `my_stars` integer, nullable
    - `holder_count` integer
    - `import_status` string
    - `import_error` string, nullable
    - `held` boolean
    - `held_object_id` string, uuid, nullable
    - `held_object_kind` string, nullable
    - `mine` boolean
    - `ratable` boolean
    - `icon_url` string, nullable
    - `held_back` MarketplaceHeldBackOut: This holder is pinned behind current because current asks for more. TOS-3713 shipped the hold itself: a new version that declares tools or capabilities beyond what the holder approved is NOT adopted, and the holder keeps running the version they consented to rather than being widened silently. That is the right behaviour and it was completely invisible, readable only by diffing two version ids nothing exposed. Present only for the consent-widening case. A ``pinned`` update policy and an owner reading their own object also leave a non-current version in play, and neither is something to ask anyone to accept.
      - `held_version_no` integer, nullable
      - `current_version_no` integer, nullable
      - `added_tools` string[]
      - `added_capabilities` string[]
      - `kind` 'consent' | 'permission_offer'
      - `added_permissions` string[]
    - `acquire` MarketplaceAcquireOut: How the shell acquires this object, resolved per type. ``family`` is the only thing the frontend dispatches on, against its own per-family client map. The shell knows no endpoint paths by type.
      - `family` string, required
      - `coordinates` object
      - `available` boolean
      - `unavailable_reason` string, nullable
      - `releasable` boolean
      - `release_unavailable_reason` string, nullable
      - `inputs` MarketplaceAcquireInputOut[]
        - `name` string, required
        - `label` string, required
        - `kind` string
        - `required` boolean
        - `choices` array[]
          - unknown[]
            - unknown
        - `help_text` string, nullable
      - `consent` MarketplaceAcquireConsentOut: What acquiring this object grants, shown BEFORE the acquire call.
        - `summary` array[]
          - unknown[]
            - unknown
        - `scopes` string[]
        - `tools` string[]
    - `maintenance` MarketplaceMaintenanceOut: Upkeep the OWNER may perform on their own copy (TOS-3743). Distinct from acquiring: these actions do not change who holds a capability, they repair or refresh the definition the caller already owns. The three the retired Skills surface offered (refresh from source, retry a failed import, dismiss a failed import) were the initial vocabulary; TOS-4595 added ``delete`` for a definition the caller authored themselves, which has no import provenance and so matched none of the other three. Which actions are OFFERED is decided entirely from generic ``objects`` columns (``imported_from``, ``import_status``, and ownership), so a type nobody has written code for inherits them the moment its rows carry the same provenance. Only WHICH ENDPOINT performs one is per-type, and that rides the same ``family`` the acquire plan already names, dispatched in the frontend's per-family client map. There is no branch on a type code on either side of the wire.
      - `family` string, required
      - `actions` string[]
    - `edit` MarketplaceEditOut: Whether/how the caller may edit this object (TOS-3861). ``family`` mirrors ``MarketplaceAcquireOut.family`` - the frontend dispatches edit/export/rollback calls through its own per-family client map, against the type's existing endpoints. There is no generic Marketplace write route.
      - `family` string, required
      - `can_edit` boolean, required
      - `can_rollback` boolean, required
      - `export_formats` string[]
    - `listing` MarketplaceListingOut: Who a listing is and what it costs (TOS-7352).
      - `subject_kind` string, required
      - `subject_name` string, required
      - `tagline` string, nullable
      - `price_label` string, nullable
      - `billing_mode` 'owner_pays' | 'caller_pays', nullable
      - `interview_enabled` boolean
      - `connectors` MarketplaceListingConnectorOut[]
        - `name` string, required
        - `icon_url` string, nullable
    - `needed_by` MarketplaceNeededByOut[]
      - `id` string, uuid, required
      - `name` string, required
  - `facets` MarketplaceFacetsOut: Everything the filter chrome renders, all of it server-derived.
    - `types` MarketplaceTypeOut[]
      - `code` string, required
      - `label_singular` string, required
      - `label_plural` string, required
      - `verb_acquire` string, required
      - `verb_release` string, required
      - `supports_ratings` boolean, required
      - `supports_versions` boolean, required
      - `supports_usages` boolean, required
      - `icon_name` string, nullable
      - `count` integer, required
    - `publishers` MarketplacePublisherOut[]
      - `id` string, uuid, required
      - `name` string, required
      - `count` integer, required
    - `capabilities` MarketplaceValueFacetOut[]
      - `value` string, required
      - `label` string, required
      - `count` integer, required
    - `side_effects` MarketplaceValueFacetOut[]
      - `value` string, required
      - `label` string, required
      - `count` integer, required
    - `domains` MarketplaceValueFacetOut[]
      - `value` string, required
      - `label` string, required
      - `count` integer, required
    - `type_facets` MarketplaceTypeFacetOut[]
      - `key` string, required
      - `label` string, required
      - `type_code` string, required
      - `options` MarketplaceValueFacetOut[]
        - `value` string, required
        - `label` string, required
        - `count` integer, required
    - `sorts` MarketplaceSortOut[]
      - `value` string, required
      - `label` string, required
  - `total` integer, required
  - `types` MarketplaceTypeOut[], nullable
    - `code` string, required
    - `label_singular` string, required
    - `label_plural` string, required
    - `verb_acquire` string, required
    - `verb_release` string, required
    - `supports_ratings` boolean, required
    - `supports_versions` boolean, required
    - `supports_usages` boolean, required
    - `icon_name` string, nullable
    - `count` integer, required

## 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)