---
title: "Read the exact skill version a share request would share"
method: GET
path: "/v1/skill-share-requests/{share_request_id}/review"
tags: ["skill-share-requests"]
---

# Read the exact skill version a share request would share

`GET /v1/skill-share-requests/{share_request_id}/review`

## Request

- Base URL: `https://api.patricia.app` (the document declares no server; this is the origin it was published from)
- URL: `https://api.patricia.app/v1/skill-share-requests/{share_request_id}/review`
- Auth: HTTP bearer

Read what an open request would hand to the workspace, taken from the installation's PINNED manifest version rather than the skill's newest one, so the content shown is the content that would run even when the author has saved a newer version since asking. Title, semver and description are that pinned version's own, and description is null when the pinned manifest carries none rather than falling back to the skill's current summary. instructions_body is the pinned manifest's markdown body for an instructions skill, and null for a portable skill, whose prose lives in its file bundle rather than its manifest. Includes a renamed_since_pin flag when the skill has been renamed since. Requires skills:edit and a signed-in person (API keys are refused). Answers 404 when the request does not exist, belongs to another workspace, or has already been decided, and 409 when the skill has since been removed or is no longer held by the person who asked.

## Path parameters

- `share_request_id` string, uuid, required

## Headers

- `X-Tenant-Id` string, nullable

## Response `200`

Successful Response

- ShareRequestReview: What an approver reads before deciding one open ask: the EXACT version they would share. Content comes from the installation's pinned ``manifest_version_id``, never from the skill's newest version and never from :class:`ShareRequestSummary`'s snapshots. Those three can all say different things: the snapshot froze the title when the ask was raised, the newest version is whatever the author saved most recently, and the pin is the one document the workspace would actually run. Only the last of them is what an approval consents to. ONE field is chosen between two sources, and it documents that on itself: ``title`` falls back to the skill's current name when the pinned manifest carries no usable one, because both manifest schemas REQUIRE ``identity.title``: a pin without one is a corrupt row, and a sheet with no heading is the worse answer for it. Every other content field is the pin's or is null. ``description`` in particular is null when the pin carries none (which is ordinary, since the schemas make it optional) rather than borrowing the definition's, whose column is rewritten from the newest save. Built field by field rather than validated from a row (no ``from_attributes``): no single ORM object holds this shape.
  - `share_request_id` string, uuid, required
  - `skill_id` string, uuid, required
  - `installation_id` string, uuid, required
  - `manifest_version_id` string, uuid, required
  - `semver` string, required: Semver of the pinned version, not of the skill's newest one.
  - `archetype_code` string, required
  - `title` string, required: The pinned version's own title, falling back to the skill's current one when the pinned manifest carries none.
  - `description` string, nullable: The pinned version's own summary, or null when the pinned manifest carries none. The skill's current summary is never substituted: that one tracks the newest version the author saved, which is not the version this request would share.
  - `renamed_since_pin` boolean, required: True when the skill has been renamed since this version was pinned, so the sheet can say so out loud. Compared against the title as rendered, so it stays false when title itself fell back to the skill's current name.
  - `instructions_body` string, nullable: The pinned markdown body for an ``instructions`` skill, which is the archetype that keeps its prose in the manifest. Null for a portable ``skill``, whose prose lives in its file bundle rather than its manifest, and null when the pinned manifest carries no body.
  - `requester_name` string, required
  - `requested_at` string, date-time, required

## Other responses

- `400`: Bad request
- `401`: Unauthorized
- `403`: Forbidden. Inspect response body `code` for the specific reason (for example: PERMISSION_DENIED, EMAIL_NOT_VERIFIED, TENANT_ACCESS_REQUIRED, ROLE_UNRESOLVED)
- `404`: Not found
- `409`: Conflict
- `422`: Validation error

---

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