> ## Documentation Index
> Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Report a problem

> Create and track LogBrew support tickets with the authenticated Support API.

Use the Support API when a problem needs follow-up. Tickets belong to the
authenticated LogBrew account, so humans and agents can create a report and
read its current state later. Tickets are private to the submitting account and
LogBrew support. They are not public or visible to other users.

<Warning>
  Authenticate support requests with an account access bearer such as
  `$LOGBREW_TOKEN`. Never use a project ingest key.
</Warning>

## Create a ticket

`POST /api/support/tickets` requires `source`, `category`, `title`, and
`description`. The following example uses fake values and token-free
diagnostics:

```bash theme={null}
curl -sS "$LOGBREW_API_URL/api/support/tickets" \
  -H "Authorization: Bearer $LOGBREW_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "source": "docs",
    "category": "docs_confusion",
    "title": "First event is not visible",
    "description": "Steps: 1) send one info event; 2) read logs with the same project, release, and environment. Expected: one matching row. Observed: no matching rows.",
    "project_id": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa",
    "environment": "production",
    "runtime": "node",
    "sdk_package": "@logbrew/node",
    "sdk_version": "0.0.0-example",
    "release": "checkout@1",
    "diagnostics": {
      "steps": 2,
      "expected": "one matching row",
      "observed": "no matching rows",
      "command_name": "logbrew logs",
      "exit_code": 0,
      "error_code": "no_matching_rows",
      "error_summary": "The scoped read returned no rows.",
      "retry_count": 1
    }
  }'
```

Optional request keys are `project_id`, `environment`, `runtime`, `framework`,
`sdk_package`, `sdk_version`, `release`, `trace_id`, `event_id`, and
`diagnostics`.

| Field      | Accepted values                                                                                                                                                         |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `source`   | `cli`, `sdk`, `website`, `docs`, `mobile`                                                                                                                               |
| `category` | `sdk_install_failure`, `ingest_failure`, `auth_failure`, `project_setup`, `dashboard_issue`, `docs_confusion`, `cli_issue`, `mobile_issue`, `billing_question`, `other` |

## Make the report actionable

* Choose the closest `category` instead of defaulting to `other`.
* Keep `title` concise and name one symptom and surface.
* Write `description` as reproducible steps followed by the expected and
  observed result.
* Include the exact `project_id`, `release`, and `environment` involved. Add
  `runtime`, `framework`, package versions, `trace_id`, or `event_id` only when
  they directly identify the same failure.

For people and AI agents, the strict diagnostic allowlist is:

| Diagnostic key  | Safe content                                         |
| --------------- | ---------------------------------------------------- |
| `steps`         | Number of reproduction steps.                        |
| `expected`      | Short expected result.                               |
| `observed`      | Short observed result.                               |
| `command_name`  | Command and subcommand name only, without arguments. |
| `exit_code`     | Numeric process exit code.                           |
| `error_code`    | Stable machine-readable error code.                  |
| `error_summary` | Short redacted error summary.                        |
| `retry_count`   | Number of equivalent retry attempts.                 |

Omit `diagnostics` when none of these keys add useful context. AI agents must
omit secrets, tokens, authorization headers, ingest keys, raw logs, customer
data, local paths, hosts, and unrelated source code. Summarize the relevant
failure instead of attaching or pasting raw data.

A successful creation returns `ticket_id`, `status`, `created_at`, `next`, and
`next_action`. Public ticket IDs start with `sup_`. Use `next` as human-readable
guidance and `next_action` as the stable machine-readable product action. Do
not infer internal routing from either field.

## List matching tickets

`GET /api/support/tickets` lists tickets for the authenticated account. This
example selects open documentation reports for one release:

```bash theme={null}
curl -sS -G "$LOGBREW_API_URL/api/support/tickets" \
  -H "Authorization: Bearer $LOGBREW_TOKEN" \
  --data-urlencode "status=open" \
  --data-urlencode "source=docs" \
  --data-urlencode "category=docs_confusion" \
  --data-urlencode "release=checkout@1" \
  --data-urlencode "pagination=cursor" \
  --data-urlencode "limit=20"
```

Supported filters are `project_id`, `status`, `source`, `category`, `release`,
`pagination=cursor`, `cursor_time`, `cursor_id`, and `limit`.

Current lifecycle values are `open`, `routed`, `in_progress`,
`waiting_on_user`, `resolved`, and `closed`. Treat the returned status as the
source of truth.

## Read one ticket

Use the `sup_` ID returned by creation or listing:

```bash theme={null}
curl -sS "$LOGBREW_API_URL/api/support/tickets/sup_example123" \
  -H "Authorization: Bearer $LOGBREW_TOKEN"
```

`GET /api/support/tickets/{ticket_id}` returns one ticket owned by the
authenticated account.

## Close or reopen a ticket

`PATCH /api/support/tickets/{ticket_id}` lets the ticket owner set only
`closed` or `open`. Close a ticket with the account access bearer:

```bash theme={null}
curl -sS -X PATCH "$LOGBREW_API_URL/api/support/tickets/sup_example123" \
  -H "Authorization: Bearer $LOGBREW_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{ "status": "closed" }'
```

Reopen the same ticket when more investigation is needed:

```bash theme={null}
curl -sS -X PATCH "$LOGBREW_API_URL/api/support/tickets/sup_example123" \
  -H "Authorization: Bearer $LOGBREW_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{ "status": "open" }'
```

A successful PATCH returns the existing full ticket object. Repeating the same
close or reopen request is a successful no-op, so agents can safely retry an
exact request after an uncertain response.

The other lifecycle values returned by reads are not user-settable through
this endpoint. There is no public ticket message or follow-up endpoint.

| Response | Recovery                                                                                         |
| -------- | ------------------------------------------------------------------------------------------------ |
| `404`    | List the authenticated account's tickets and retry with a returned `sup_` ID.                    |
| `422`    | Send JSON with only `status: "open"` or `status: "closed"`; do not send another lifecycle value. |

## Keep reports safe and recoverable

* Keep `diagnostics` within the allowlist and sanitize every value before
  sending. The service also redacts and bounds the field.
* If a request fails, confirm that the required keys and enum values are valid,
  authenticate with an account access bearer, and follow the returned `next`
  or `next_action`.
* Read ticket detail to get the current status and next product action.

For self-service checks before filing a report, see
[Troubleshooting](/guides/troubleshooting).