---
title: "Read a ticket linked to this Context Capture credential"
method: GET
path: "/integrations/context-capture/v1/tickets/{ticketId}"
tags: ["ContextCapture"]
---

# Read a ticket linked to this Context Capture credential

`GET /integrations/context-capture/v1/tickets/{ticketId}`

## Request

- Base URL: `https://api.apphandoff.com/api`
- URL: `https://api.apphandoff.com/api/integrations/context-capture/v1/tickets/{ticketId}`
- Auth: HTTP bearer

## Response `200`

Linked ticket

- ContextCaptureTicket
  - `id` string, uuid, required
  - `number` integer, required
  - `title` string, required
  - `status` 'open' | 'closed', required
  - `stage` 'backlog' | 'up_next' | 'in_progress' | 'validation' | 'live', required
  - `priority` 'low' | 'medium' | 'high', required
  - `revision` string, date-time, required
  - `updatedAt` string, date-time, required
  - `portalUrl` string, uri, required
  - `resolutionType` string, nullable, required: How the ticket was actually resolved, so a customer-facing status can say "merged into HO-n" or "closed, not built" instead of "Resolved". Every closed ticket lands in stage `live` regardless of outcome, so `stage` alone cannot tell a shipped fix from a duplicate/cancelled/wont_fix close. Null on an open ticket, and null on a closed ticket that carries neither a stored resolution nor a merge — absence means "closed, nothing proven", never "completed".
  - `survivingTicketRef` string, nullable: For a duplicate close, the ticket that survived (e.g. `HO-11216`). Best-effort: no stored duplicate link type exists yet, so this is parsed from the free-prose resolution note and is absent when the note names no ticket. Absent on every non-duplicate resolution.

## Other responses

- `401`: Not authenticated
- `404`: Not found
- `429`: Rate limited

---

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