https://api.logbrew.co 的 JSON over HTTP 接口。公开 SDK 会把它们管理的批次发送到 POST /v1/events。自定义原生客户端会把原生封装（envelope）发送到 POST /api/telemetry/ingest。这两个数据接收路由都需要项目范围的接入 Bearer 令牌。
读取和更改账号所属的资源时，使用账号 Bearer 令牌。切勿把账号 Bearer 令牌或浏览器会话用作 SDK 或数据接收配置。切勿把接入 Bearer 令牌发送到读取路由。
发送范围明确的请求
客户端发送请求之前，使用以下检查清单：- 从端点表中选择路由和 HTTP 方法。
- 使用正确的 Bearer 令牌：数据接收使用接入 Bearer 令牌，其他所有请求使用账号 Bearer 令牌。
- 选择路由支持的项目范围。收到空响应后，不要扩大范围。
- 只添加路由接受的查询键。请参阅查询筛选条件。
- 路由有 JSON 请求体时，发送
Content-Type: application/json。 - 重试之前，先读取 HTTP 状态和响应体。
- 不要让 Bearer 令牌、实时动态票据和完整的响应体出现在日志和智能体提示词中。
端点
数据接收
让 SDK 构建
/v1/events 批次。不要手动构造。原生封装请参阅 SDK 接入。
遥测数据读取
部署
部署成功或失败后，从发布自动化流程中记录这次部署。
PUT 请求体包含 project_id、release、environment、service_name、status（succeeded 或 failed）、started_at、finished_at，以及可选的 commit_sha。release、environment 和 service_name 要使用与 SDK 发送的值相同的值。账号必须拥有该项目。
deployment_id 是你为这次部署自定义的 ID。使用相同 ID 和相同请求体重试时，会返回已存储的部署。相同 ID 搭配不同的请求体时，会以 409 和 idempotency_conflict 失败。不同的部署请使用新的 ID。
排查
每个排查路由都会针对一个排查对象返回一个范围有限的证据包。CLI 的logbrew explain 命令会读取这些路由并验证响应。
产品分析
POST 分析路由接受 JSON 请求体，而不是查询键。请参阅产品分析。
实时动态
账号与登录
用量、配额、订阅和退出登录路由请参阅账号 API。成功状态码
200 响应并不能证明证据是完整的。读取响应中的覆盖率、截断和状态字段。
查询筛选条件和分页
每个读取路由都接受各自的查询键。project、trace 和 user 等友好别名不是查询键。列表路由默认返回不带外层对象的数组，使用 pagination=cursor 时返回游标封装。部署列表始终返回页面对象。请参阅查询筛选条件。
响应和错误
先读取code，再读取供人阅读的消息。程序行为依据 next_action，给人的指引使用 next。不要解析 error 或 next 的措辞。
更新问题
这些请求使用账号 Bearer 令牌。它特意与LOGBREW_INGEST_BEARER 区分开。账号必须有权管理该问题所在项目中的问题。否则，请求会以 403 和 forbidden 失败。同一权限涵盖状态、优先级和负责人的更改，以及问题规则和日志规则。
每个请求设置以下字段中的 1 个或多个：
请求中不包含上述任何字段时，会以
422 和 validation_failed 失败。
一个问题有 0 或 1 个负责人：一个账号或一个团队。账号必须能够读取该项目，团队必须属于该项目所在的组织。否则，请求会以 422 和 validation_failed 失败，LogBrew 不会做任何更改。可分配的账号请通过列出负责人获取。其他任何 assignee 值也会以 422 和 validation_failed 失败。
你手动设置的优先级会保持不变。没有手动设置优先级时，优先级跟随问题的严重程度：error 和 critical 为 high，warning 为 medium，info 为 low。
已经是所请求值的字段不会改变。超时后，可以再次发送同一个请求。超时并不能证明更改没有发生。发送其他更改之前，先重新读取该问题。
更新单个问题
添加response_version=4，即可在响应中获得 archived、优先级和负责人。在版本 4 中，assignee 为 { "type": "user", "user_id", "name", "email" }、{ "type": "team", "team_id", "slug", "name" } 或 null。版本 3 会把团队负责人显示为 null。
批量更新问题
发送project_id，以及该项目中 1 到 100 个不同的问题 ID：
project_id 和 results，每个问题 ID 对应 1 个结果，顺序与请求相同。每个结果包含 issue_id、outcome 和 issue。在响应版本 3 中，issue 是该问题的当前数据；对于 not_found，它为 null。在请求体中添加 "response_version": 2，即可以响应版本 4 获取每个问题。
空列表、超过 100 个 ID 或重复的 ID，都会以
422 和 validation_failed 失败。把更大的集合拆分成多个请求。如果账号无法读取该项目，请求会以 404 和 not_found 失败。
列出负责人
发送项目 ID，获取该项目中所有可以被分配问题的账号：user_id、name 和 email。账号没有姓名时，name 为 null。添加 response_version=2 还可以获得 teams：该项目所属组织的所有团队，每个团队包含 team_id、slug 和 name。请参阅负责人列表响应。任何能够读取该项目的账号都可以获取此列表。如果账号无法读取该项目，请求会以 404 和 not_found 失败。
成员失去项目访问权限后，分配给该成员的问题将不显示负责人。如果该成员重新获得访问权限，这些问题会再次显示该成员，除非在此期间有人更改或移除了负责人。
所有权和建议的所有者
GET /api/telemetry/issues/ownership?project_id=<project-uuid> 返回 rules、codeowners、updated_at 和 unresolved_owners。任何能够读取该项目的账号都可以读取。发送带有 project_id 以及 rules、codeowners 或两者的 PUT 请求，会替换对应的文本，这需要问题管理权限。省略的字段保留原有文本，空字符串会清空该文本。每段文本不超过 128 KiB。文本无效时，请求以 422 失败，并指出出错的行。
GET /api/telemetry/issues/{issue_id}/owners?response_version=2 返回 suggested_assignee、owners 和 inputs。每个所有者包含 type（user 或 team）、source（ownership_rule、codeowners 或 recent_activity）、rule、line 和 matched。版本 1（默认版本）只列出账号。
问题变更历史
GET /api/telemetry/issues/{issue_id}/activity?response_version=2 按从新到旧返回 activity，并返回 next_cursor。每个条目包含 type（status、priority、assigned、unassigned、severity_rule 或 first_seen）、value、actor_id、actor、assignee_id、assignee、team 和 at。limit 取 1 到 200，默认为 50。要读取下一页，发送取自 next_cursor 的 cursor_time 和 cursor_id。
通知
GET /api/telemetry/issues/notifications 返回 notifications、unread、read_at 和 next_cursor。每条通知表示另一个账号把某个问题分配给了你或你所在的团队。向 POST /api/telemetry/issues/notifications/read 发送空 JSON 对象或带有 read_at 的对象，会移动你的已读标记。已读标记不会往回移动。
设置问题和日志规则
规则会改变 LogBrew 显示匹配信号的方式，不会删除数据。采集到的severity 保持不变，响应会在 triage 中显示该规则。
severity 可取 info、warning、error、critical 或 source。source 会移除覆盖设置，重新显示采集到的严重程度。对于日志规则，ignored: true 会在默认日志列表中隐藏匹配的日志。使用 status=ignored 或 status=all 读取它们。规则适用于已保留的和未来的匹配信号。其他值会以 422 和 validation_failed 失败。