Show ticket API

This article and the rest of the API documentation in this section are written for a technical audience — integrators and developers connecting external systems to Tickiti. Familiarity with HTTP, REST, JSON and bearer-token authentication is assumed.

The show endpoint returns a single ticket together with its full response thread — every reply, public and internal, in the order the staff agent would see them — and the metadata for each response’s attachments. Use it to read a conversation before deciding how to act on it: the natural companion to Reply to ticket, and the detail behind a row from List tickets.

Endpoint

POST /api/v1/tickets/show

Headers

1. Authorization: Bearer YOUR_TOKEN — required. Token must have the tickets:read ability. A tickets:write token also works (write implies read).
2. Content-Type: application/json — required. No Idempotency-Key is needed (this is a read).

Body

Required fields:

1. ticket_number — the 6-digit number of the ticket to read. The ticket must exist and be in a queue the acting user can see.

Example

curl -X POST https://support.sole-provider.example/api/v1/tickets/show \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "ticket_number": "220009"
  }'

Successful response

The ticket header plus a responses array (pinned first, then oldest to newest). Each response carries its body as raw stored HTML and any attachment metadata; download an attachment’s bytes with Download attachment using its id. Numeric ids are returned as strings.

{
  "ok": true,
  "data": {
    "ticket": {
      "id": "1",
      "number": 220009,
      "subject": "Carbon plate cracked on first marathon",
      "status": "open",
      "priority": "20",
      "queue_id": "4",
      "originator_email": "marcus@trailblazers-club.example",
      "assigned_to_email": "priya.sharma@sole-provider.example",
      "resolved": null,
      "on_hold_until": null,
      "created_at": "2026-05-01T09:14:02+00:00",
      "updated_at": "2026-05-02T11:30:48+00:00"
    },
    "responses": [
      {
        "id": "42",
        "is_internal": false,
        "is_pinned": false,
        "staff_response": true,
        "created_by_email": "priya.sharma@sole-provider.example",
        "created_at": "2026-05-02T11:30:48+00:00",
        "updated_at": "2026-05-02T11:30:48+00:00",
        "is_email_sourced": false,
        "html": "<p>Your replacement has shipped.</p>",
        "plain_text": "Your replacement has shipped.",
        "attachments": [
          {
            "id": "14494",
            "response_id": "42",
            "name": "UPDD Diag.zip",
            "is_inline": false,
            "sha256": "cc9b8a68...608baf",
            "file_size": 1196962,
            "file_size_formatted": "1.14 MB",
            "extension_rule": "allowed"
          }
        ]
      }
    ]
  }
}

is_internal responses are staff-only notes that were never sent to the customer. is_email_sourced indicates the body arrived as an email (so it may contain Outlook/Word markup) rather than being authored in the in-app editor. The html is the raw stored body: inline images reference Tickiti’s own attachment route, and any cross-ticket “magic” links are left as stored — resolve them yourself if you re-render the HTML.

Error responses

1. 422 validation_failed — ticket_number missing.
2. 404 not_found — no ticket has that number.
3. 401 unauthenticated — bad or missing token.
4. 403 forbidden — token lacks the tickets:read (or tickets:write) ability, the user it acts as lacks access to the ticket’s queue, or the token owner is not a staff account.

What happens server-side

1. Tickiti locates the ticket by ticket_number.
2. It applies the same access check as the staff interface: the acting user must be the assignee, a participant, or hold view permission on the ticket’s queue.
3. It returns the ticket header and the complete response thread — public replies and internal staff notes — with attachment metadata for each response.