Skip to main content

​
各入口的认证

  • Routing REST（li.quest）：公开路由端点允许不带密钥访问，但受速率限制约束。认证请求使用 x-lifi-api-key。GET /v1/keys/test 等受保护端点要求有效密钥。
  • Earn REST（earn.li.fi）：要求 x-lifi-api-key。不要将 routing 的访问规则或配额套用到 Earn。
  • 通用 MCP，HTTP transport：服务端接受 Authorization: Bearer <key> 或 X-LiFi-Api-Key；两者同时存在时，优先使用 Bearer key。选中的值通过 x-lifi-api-key 传给上游。这不授予签名或广播交易的权限。
  • 通用 MCP，stdio transport：服务端读取 LIFI_API_KEY。test-api-key 工具调用 routing 的 /v1/keys/test；routing key 测试成功不证明可以访问所有 LI.FI 产品。
  • SDK：按已安装 SDK 版本的文档配置 API key，由客户端发送上游请求头。见 SDK 配置。
  • CLI 和 Intents：使用各产品文档规定的认证方式，不要将通用 MCP 的 Bearer 适配或 routing key 当作通用凭证。
HTTP 请求头名称不区分大小写。不同大小写不构成契约不一致。不要记录或公开 key，应保存在服务端配置中。

​
按操作理解结果

分别保留 HTTP status、API 数字 code、交易 status 和 substatus。以下是客户端处理建议，不是新的 REST 响应 schema，也不保证已部署 MCP 会返回这些结构化字段。

​
重试边界

重试 GET /status 或报价查询，不等于重试签名、approval、提交交易或存款。超时绝不授权新交易。考虑替换前必须保留原 hash 并核对其状态。修改 slippage 必须符合用户策略或获得明确授权。 如果返回 Retry-After，解析 delay-seconds 或 HTTP date，不要提前重试。否则采用带 jitter 的有界指数退避。ratelimit-reset 文档含义是距离重置的秒数，不是绝对 Unix timestamp。不同产品的 header 和配额可能不同。通用 MCP HTTP client 当前自行计算 backoff；不要假设它会向调用 Agent 暴露或严格执行 Retry-After。

​
MCP 部署边界

MCP transport 返回 HTTP 200 不代表业务成功，必须检查 CallToolResult.isError 和工具内容。当前通用 MCP 错误可能是文本，而不是 typed error object。Earn capability 响应和 structured outputs 取决于已部署版本；GitHub PR 不证明服务已部署。 参见 Error Playbooks、Status & Recovery 和 Rate Limits。