五个接口，三种语言，复制即用

认证与请求

需要 law_search scope 和 Bearer API Key。

额度、计费与限流

• deep（默认）：每账号 Asia/Shanghai 自然日 100 次，0 点。
• expert：最多 30,000 字符，标准价按 5/10/15 点阶梯；限时免费至 2026-12-31 24:00（Asia/Shanghai），活动期间各字符档均为 0 点。
• 限流：同一 IP 或同一 Key 在 3 秒内最多请求 6 次。

使用说明

法条检索默认 stream: false（非流式）。deep（免费）模式响应较快，一般不会超时。但 expert 专家模式耗时较长（实测可达 40 秒以上），建议设置 stream: true 以利用心跳保活防止客户端断联。

响应格式

非流式（默认）

流式（stream: true）

返回 NDJSON 行：heartbeat → original_content（一个完整 JSON 行即为全部结果）。

⚠️ 法条检索流式输出的键名是 original_content，不是 data。与其他接口不同。

常见错误：invalid_json、prompt_required、exceed_char_limit，以及 Key、权限、IP、额度或服务暂不可用等问题。

认证与请求

请求使用 Authorization: Bearer ak_live_YOUR_API_KEY 和 Content-Type: application/json。

权限、额度与计费

同一 IP 或同一 Key 在 3 秒内最多请求 6 次。

使用说明

Web 端支持上传 txt、docx、pdf 和图片（OCR 识别）并自动提取文字。使用 API 时，你需要自行完成文件到文字的转换，然后通过以下字段传入：

• question（必填）：你的法律问题。需要多轮对话时，通过 history 传入上下文。
• context_text（可选）：将提取的文件文字通过此字段传入，代理会以两个换行拼接在 question 之前。计费字符数为两字段的字符数之和，自动加入的两个换行不计费。例如，一份 3,000 字的合同文本 + 50 字的问题 = 3,050 字计费。
• 建议使用流式（默认已开启 stream: true）：耗时相对较长，非流式客户端建议至少等待 600 秒。

响应格式

非流式（stream: false）

流式（stream: true，默认）

返回 NDJSON 行：heartbeat → original_content → data 增量文本片段。详见「流式指南」标签页。

错误

认证与请求

需要 contract_review scope 和 Bearer API Key。

计费、限流与响应

• 1-10,000 字符 10 点；10,001-20,000 字符 20 点；20,001-30,000 字符 30 点。
• 限流：同一 IP 或同一 Key 在 5 秒内最多请求 3 次。
• ⚠️ 合同审查目前只提供流式响应。即使传入 stream: false，也请按 NDJSON 逐行解析。
• 主要错误：invalid_json、contract_text_and_standpoint_required、exceed_char_limit，以及 Key、权限、IP、计费或服务暂不可用等问题。

响应格式

流式返回 NDJSON 行，三阶段：heartbeat → original_content（参考法条）→ data（审查意见）。

output_mode: "normal"（默认）— 审查意见以自然语言法律意见书形式输出。

output_mode: "json" — 拼接全部 data 后为结构化 JSON：

使用说明

Web 端支持上传合同文件（docx/pdf 等）并自动提取文字。使用 API 时，你需要自行提取合同文本后传入：

• contract_text（必填）：合同的完整正文。也支持旧字段名 user_input。
• standpoint（必填）：你的审查立场，例如"我是承租方"。也支持旧字段名 user_standpoint。二者缺一不可，否则返回 400。
• 计费字符数 = contract_text 长度 + standpoint 长度，上限 30,000。
• 建议使用流式（默认已开启 stream: true）：合同审查耗时较长，非流式客户端建议至少等待 600 秒。

认证与请求

需要 document_draft scope 和 Bearer API Key。

计费、限流与响应

• 1-10,000 字符 10 点；10,001-20,000 字符 20 点；20,001-30,000 字符 30 点。
• 限流：同一 IP 或同一 Key 在 5 秒内最多请求 3 次。

响应格式

非流式（stream: false）：

流式（默认）：NDJSON 行 — heartbeat → original_content → data 增量文本片段。详见「流式指南」标签页。

主要错误：prompt_required、exceed_char_limit，以及 Key、权限、IP、计费或服务暂不可用等问题。

使用说明

Web 端支持上传案件资料和范文并自动提取文字。使用 API 时，你需要自行完成文件到文字的转换后传入：

• prompt（必填）：文书写作要求。也支持旧字段名 requirement。
• reference_material（可选）：案件资料、证据描述等参考内容，计入总字符。
• sample_document（可选）：示范文本，用于风格和格式模仿，计入总字符。
• 计费字符数 = prompt + reference_material + sample_document 三者长度之和，上限 30,000。
• 建议使用流式（默认已开启 stream: true）：文书生成耗时较长，非流式客户端建议至少等待 600 秒。

请求与限制

• 无请求体，不需要额外权限；Key 必须有效且处于启用状态。
• 不计点数，也不消耗账号每日免费额度。
• 限流：同一 IP 或同一 Key 在 5 秒内最多请求 12 次。
• 成功响应是非流式 JSON；该 GET 接口不接受也不支持 stream 参数。
• summary 聚合最近 30 天；recent 是最新 50 条，不受 30 天过滤。
• Key 自查 recent 不包含 client_ip；登录控制台的账号用量响应可以包含。

成功响应字段

错误

常见错误为 api_key_required、api_key_invalid、too_many_requests 和 usage_backend_unavailable。如果返回 503，表示查询服务暂时不可用，不代表当前没有调用记录。

哪些接口支持多轮？

• 法律问答 POST /v1/qa：支持 history 参数，每一轮都可以传入之前的对话记录。
• 合同审查 POST /v1/contracts_review：接受 history 作为历史上下文，返回审查结果。对审查结论继续追问时，推荐将相关结果与问题传入法律问答。
• 文书生成 POST /v1/documents_draft：接受 history 作为历史上下文，返回文书草稿。围绕草稿继续讨论时，可使用法律问答。

history 参数格式

history 接受以下两种格式，按原顺序完整传递，不做字符截断。完整请求仍受传输大小限制（默认 2 MiB，含协议包装），超限会明确拒绝，不扣点：

数组中的 role 只区分 assistant 和其他值：非 assistant 均视为 User。建议每轮交替传入用户和 AI 的消息，保持对话上下文完整。

合同审查 / 文书生成如何追问？

REST 合同审查和文书生成均接受 history 参数；MCP 的这两个工具按各自参数表接收输入。围绕已有结果追问，推荐以下流程：

1. 先调用合同审查或文书生成，拿到结果。
2. 将结果与你的追问组织为 history 数组，调用 POST /v1/qa（使用 expert 模式可获得更大上下文窗口）。
3. 后续每一轮都追加到 history，继续使用 QA 接口。

示例流程：合同审查 → 拿到审查意见 → QA expert 模式追问"请针对违约金条款做更详细的风险评估"。

关于流式与非流式

Neo-RAG 语义拆解耗时较长，非流式可能断联。详见流式处理标签。

为什么建议流式？

Neo-RAG 在检索前会对输入内容进行语义拆解，再发起检索并生成回答。这个过程耗时相对较长，如果使用非流式（stream: false），客户端在等待完整响应期间可能因超时断联。流式模式下，AI 生成的内容逐块返回，连接始终保持活跃。

各接口默认行为

如何解析流式响应

流式模式（stream: true）返回换行分隔的 JSON（NDJSON），每一行都是一个完整 JSON 对象。一次网络读取可能只拿到半行，因此请先缓存未完成的部分，再逐行解析。

法条检索（/v1/law_search）

1. 心跳保活 — {"heartbeat": true}，可能出现多次
2. 完整检索结果 — {"original_content": "全部法条检索结果"}，以一个完整 JSON 行返回

法条检索流式响应不返回 data。original_content 就是最终检索结果，不是参考资料。

法律问答、合同审查、文书生成

1. 心跳保活 — {"heartbeat": true}，可能出现多次
2. 参考法条 — {"original_content": "检索到的法条…"}，通常以一个完整 JSON 行返回
3. 生成正文 — {"data": "增量文本片段"}，可能出现多次，调用方按顺序拼接

请按行分割并逐行 JSON.parse。不要直接对每次读取到的网络数据执行解析，因为一行 JSON 可能被拆成多个数据块。

let searchResult = "";
let legalReferences = "";
let generatedContent = "";

function handleStreamEvent(obj, endpoint) {
  // 持续检查失败；已经收到内容也不能跳过。
  if (obj.status === "error" || obj.error_code || obj.error) {
    const code = obj.error_code || obj.error || "internal_error";
    throw Object.assign(new Error(obj.message || code), { code });
  }
  if (Object.hasOwn(obj, "heartbeat")) return;

  if (Object.hasOwn(obj, "original_content")) {
    if (endpoint === "/v1/law_search") {
      searchResult = obj.original_content;
    } else {
      legalReferences = obj.original_content;
    }
  }

  if (Object.hasOwn(obj, "data")) {
    generatedContent += obj.data;
  }
}
// 响应结束且没有错误时，才确认成功。
// 已捕获的失败不能因后续正文或合同结束标记而清除。

curl

不加 --output 即可直接在终端看到逐行 JSON 输出。添加 --no-buffer 可禁用 curl 自身的缓冲。

JavaScript（fetch / Node.js）

浏览器端使用 response.body.getReader() 逐块读取，按换行分割后 JSON.parse；Node.js 端使用 fetch 的 response.body 流式读取或监听 data 事件。

Python

使用 requests 库时设置 stream=True，通过 response.iter_lines() 逐行读取并 json.loads；或使用 httpx 的异步流式接口。

非流式响应结构

非流式模式（stream: false）返回单个 JSON 对象：

法条检索（law_search）仅返回 data（检索结果即为正文，无额外的参考原文字段）。

⚠️ 合同审查注意：目前只提供流式返回。即使请求中设置了 stream: false，也请按 NDJSON 逐行解析。

非流式客户端应持续等待完整响应，建议将超时设为至少 600 秒，并在收到完整响应后检查业务结果。检索等待期间请避免重复提交同一请求。