Report a problem

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.

Authenticate support requests with an account access bearer such as $LOGBREW_TOKEN. Never use a project ingest key.

Create a ticket

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

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:

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:

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:

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:

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.

Start

Concepts

Workflows

Report a problem

Create a ticket

Make the report actionable

List matching tickets

Read one ticket

Close or reopen a ticket

Keep reports safe and recoverable

​Create a ticket

​Make the report actionable

​List matching tickets

​Read one ticket

​Close or reopen a ticket

​Keep reports safe and recoverable

Create a ticket

Make the report actionable

List matching tickets

Read one ticket

Close or reopen a ticket

Keep reports safe and recoverable