---
title: "Get Decisions"
method: GET
path: "/snapshots/{snapshot_id}/decisions"
tags: ["dashboard"]
---

# Get Decisions

`GET /snapshots/{snapshot_id}/decisions`

List decisions for a snapshot, sorted, filtered and optionally paged.

``total_found`` is the count *after* filters and *before* paging, so it is
the denominator the table prints beside "51–100 of …". With no filters and
no page it equals the artifact's own total, which is what it meant before.

**Every default reproduces the pre-paging response exactly**, and that is
deliberate rather than timid. A decision's identity on this surface is its
*position*: the PATCH route takes one, ``jira_links.decision_key`` falls
back to ``decision-{position}``, and the extraction-only serializer writes
a null id for every record, so on those snapshots there is nothing else to
key on. Reordering or filtering by default would therefore not degrade an
older client — it would make its next Confirm click rewrite a different
decision and return 200. The backend deploys before the frontend, so that
window would be real. Clients opt in with ``sort`` and
``include_dismissed``, and read ``decision_index`` off each row instead of
counting rows. Follows the same rule ``fields=full`` did on ``/docs``:
nothing that already calls the endpoint changes meaning.

## Path parameters

- `snapshot_id` string, required

## Query parameters

- `status` string, nullable — Filter by status
- `source` string, nullable — Filter by source
- `include_proposed` boolean
- `include_dismissed` boolean — Include dismissed tombstones. The table passes false; the detail page needs them, and so does every pre-paging client.
- `limit` integer, nullable — Page size. Omitted returns every matching row, which is what the detail page and pre-paging clients rely on.
- `offset` integer
- `sort` string — artifact: the artifact's own order (default). priority: confirmed rules first, then the likeliest proposals. recent: newest first.
- `lane` string, nullable — Filter by review lane, which is derived from the acceptance rather than from the status column. candidates are records nobody has accepted; governing is the roll-up of active and needs_review.

## Response `200`

Successful Response

- DecisionsResponse
  - `total_found` integer, required
  - `decisions` object[], required
  - `by_source` object, required
  - `conflicts` object[]
  - `governed_files` GovernedFile[]
    - `path` string, required
    - `decision_count` integer, required
  - `governed_file_total` integer

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/repowise/apis/repowise-hosted-api.md) · [All operations](https://skmtc.dev/repowise/apis/repowise-hosted-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/repowise/repowise-hosted-api/revisions/40167ba9ab58/schema)