Get 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
Query parameters
Filter by status
Filter by status
Filter by source
Filter by source
Include dismissed tombstones. The table passes false; the detail page needs them, and so does every pre-paging client.
Include dismissed tombstones. The table passes false; the detail page needs them, and so does every pre-paging client.
Page size. Omitted returns every matching row, which is what the detail page and pre-paging clients rely on.
Page size. Omitted returns every matching row, which is what the detail page and pre-paging clients rely on.
artifact: the artifact's own order (default). priority: confirmed rules first, then the likeliest proposals. recent: newest first.
artifact: the artifact's own order (default). priority: confirmed rules first, then the likeliest proposals. recent: newest first.
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.
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
Successful Response
Changes
No recorded changes to this endpoint across all 1 revision of this API.