简短回答:用 htmlDefinition,而不是 documentBase64
要通过 DocuSign eSignature REST API 创建响应式 HTML 文档,在 Envelopes:create 请求的 documents 数组中定义文档:使用 htmlDefinition 对象,其 source 属性以纯文本(而非 Base64 字符串)承载你页面的 HTML。将 documentId 设为 "1" 之类的字符串,设置文档 name,并将 fileExtension 设为 "html"(DocuSign 工程博客中也有使用 "htm" 的可运行示例)。然后将该签署包 POST 到 /restapi/v2.1/accounts/{accountId}/envelopes。以这种方式构建的文档会进入 DocuSign 的响应式签署(Responsive Signing)体系,手机和平板上的签署人看到的不是固定版式的 PDF,而是一个可随屏幕缩放的网页式签署页面。
要避开的陷阱:把 HTML 字节塞进 documentBase64。DocuSign 开发者支持团队已明确记录,这种做法会让文档走常规处理管线,不会产出响应式文档;在某些账户中,该调用甚至会直接返回"不允许 HTML"的错误。
一个可用性提醒:高级响应式签署——直接发送 HTML 并使用 Smart Sections——在所有开发者(沙箱)账户中都可用,但仅面向部分生产环境套餐开放;而基础响应式签署(自动将 PDF 转为 HTML)默认处于关闭状态,必须由账户管理员开启。请与 DocuSign 支持确认你的生产套餐能力,并先在沙箱中验证行为。
响应式签署的两层机制
DocuSign 官方文档将响应式签署分为两层。在基础响应式签署中,你提供 PDF(或其他受支持的文件类型),由 DocuSign 将其转换为可签署的 HTML 文档;已有 tab 会被保留,锚点 tab 仍附着在对应文本上,转换结果会作为签署包附件存储,可供你回取。在高级响应式签署中,你直接发送 HTML,并可选配 Smart Sections。两种方式产出的页面都能动态调整尺寸,移动端签署体验优于固定版式的 PDF。
htmlDefinition 对象还提供 API 参考中的移动端专属控制项:maxScreenWidth 可将响应式 HTML 版本限制在指定像素宽度及以下的屏幕上(更大的屏幕将看到 PDF 版本);showMobileOptimizedToggle 则在移动设备上显示"移动端友好"开关,签署人可在完成前切换到 PDF 视图。
签署包请求:代码中的 htmlDefinition
官方"创建可签署 HTML 文档"操作指南分为三步:获取 OAuth 令牌、构建带 htmlDefinition 节点的签署包定义、调用 eSignature REST API。以下是 curl 形式的请求,凭据使用占位符。
```bash
curl -s -X POST "https://demo.docusign.net/restapi/v2.1/accounts/{$ACCOUNT_ID}/envelopes" \
-H "Authorization: Bearer {$JWT}" \
-H "Content-Type: application/json" \
-d @envelope.json
```
下面的 envelope.json 请求体以文本形式承载 HTML,为 tab 分配映射了签署人角色,并包含一条 Smart Section 定义:
```json
{
"emailSubject": "Your mobile-friendly agreement",
"status": "sent",
"documents": [
{
"documentId": "1",
"name": "agreement.html",
"fileExtension": "html",
"htmlDefinition": {
"source": "
Service Agreement
Terms text here
pricing_table_start
| Plan A |
pricing_table_end
","displayAnchors": [
{
"startAnchor": "pricing_table_start",
"endAnchor": "pricing_table_end",
"removeStartAnchor": true,
"removeEndAnchor": true,
"caseSensitive": true,
"displaySettings": {
"display": "responsive_table_single_column",
"tableStyle": "width:100%;max-width:816px;margin-left:auto;margin-right:auto;",
"cellStyle": "text-align:left;padding:0px;"
}
}
]
}
}
],
"recipients": {
"signers": [
{
"email": "signer@example.com",
"name": "Example Signer",
"recipientId": "1",
"roleName": "Signer"
}
]
}
}
```
三个细节必须注意。第一,documentId 必须是 1 到 2,147,483,647 之间的整数,以不带逗号的字符串形式编码;tab 通过它引用文档。第二,source 是纯文本——操作指南明确要求把页面 HTML 直接写入 source 的值,而不是 Base64。第三,注意引号问题:DocuSign 工程师建议在 HTML 定义中尽量少用双引号、改用撇号,因为嵌在 JSON 里的 HTML 中多余的双引号经常导致反序列化错误。
签署包创建后,签署人会收到一封含签署链接的邮件,可在 DocuSign 移动应用或网站中打开。签署包完成后,已签署文档与证据都保存在已完成的签署包中——该保留哪些内容,参见 DocuSign 完成证书与审计轨迹指南。你也可以用 GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/html_definitions(EnvelopeHtmlDefinitions:list)回读已存储的定义。
在 HTML 签署文档中放置 tab
响应式 HTML 文档中的 tab 不使用 xPosition/yPosition 坐标。DocuSign"在 HTML 文档中设置 tab"指南给出了两种方法。第一种是 HTML 块:每种 tab 类型都有对应的 DocuSign HTML 标签,通过 data-ds-role、data-ds-recipient-id、required、readonly、font-size、color 等属性配置;属性值会覆盖 tab 的默认设置。第二种是 JSON 标记:在 HTML 源码中嵌入包含 tabLabel 的标记,每个标记会被 API 请求中匹配的 tab 定义替换。单选(radio)tab 是特例——其标记必须包含映射到某个 radio 组的 groupName 和 value 属性。
同一份指南中还有两个约束,漏掉就会踩坑。只有内联样式会反映到处理后的文档中;定义在页面之外的样式,如 块或外部 CSS,不会生效。另外,通过 htmlDefinition 分配 tab 时,tab 的角色必须能映射到接收人——在签署人上设置 roleName(或使用服务器模板、组合模板),内联 tab 定义才能解析到正确的人。
签署完成后,通过 API 从已签署文档提取 tab 与表单数据就是你的后端记录签署人填写内容的方式。
面向移动端优化的 Smart Sections
Smart Sections 是 htmlDefinition 内部的移动端优化层。按照响应式签署概念指南,它支持签署人可展开收起的折叠区块、将多列内容在窄屏上转为单列的旋转表格,以及在签署人继续操作前设置停顿点的 Continue 按钮。它对 DocuSign 从 PDF 转换的文档和你直接发送的 HTML 都有效。
上面的 JSON 展示了完整结构:displayAnchors 条目包含 startAnchor、endAnchor、removeStartAnchor、removeEndAnchor 和 caseSensitive,外加一个 displaySettings 对象——其 display 值(此处为 responsive_table_single_column,即旋转表格模式)决定行为,tableStyle 与 cellStyle 提供内联 CSS。起始锚点、结束锚点至少要有其一;如果锚点字符串在 HTML 中找不到,该 display anchor 会被忽略——因此锚点必须是字面、唯一、且能在模板渲染后原样保留的字符串。API 参考还记录了 headerLabel、displayOrder、displayPageNumber 和 displayAnchorPrefix(前缀至少 4 个字符可提升锚点处理性能)。
需在沙箱中验证的限制与坑点
以下每一项都请在开发者沙箱中跑一遍,涉及套餐差异的行为在上线前与 DocuSign 支持确认。
- 账户开通状态。 基础响应式签署默认关闭;高级能力在所有开发者账户中可用,但仅面向部分生产套餐。不要因为沙箱成功就默认生产环境一致。
- 图片必须内嵌。 直接发送 HTML 时不能使用图片文件链接;图片必须以 Base64 编码为 data URI 放在
标签内,否则无法显示。 - 仅支持内联样式。 外部样式表和
块不会生效;请把样式写进每个元素的内联属性。 - 受限的 HTML 与 CSS。 出于安全考虑,响应式签署禁用了若干 HTML 元素、属性和 CSS 属性。在选定设计体系之前,先查 DocuSign 指南中的允许元素清单。
- 不支持 RTL。 希伯来语、阿拉伯语、波斯语等从右至左书写的语言目前不受响应式签署支持。
- JSON 引号问题。 嵌在 JSON 中的 HTML 里多余的双引号会导致反序列化错误;HTML 定义内部请改用撇号。
- 发送前先预览。 eSignature Admin 中的 Preview 选项可以展示内容在响应式体验中对移动端签署人的呈现效果。
- 量级成本。 如果这些签署包以产品级量级生成,请围绕 DocuSign API 速率限制与定价层级规划容量,而不是只测单个签署包。
移动优先签署、条款更简单:Nota Sign
响应式 HTML 解决的是文档在手机上如何呈现的问题。而它背后的平台是否适合你的产品——按套餐门槛锁定的功能、为销售团队而非为大规模发送的 API 设计的按席位定价——是一个需要单独判断的决策。
Nota Sign 是 FaDaDa 面向全球业务的电子签名平台,它的三项优势与移动端签署的构建直接对应:
- 随时随地完成签署 —— 法律覆盖 100 多个国家和地区,背后是 FaDaDa 连续多年位列 IDC 中国电子签名软件市场第一,签署人在任何市场的手机上签署,都具有完整的法律效力。
- 原生内置的亚太身份能力 —— iAM Smart、Singpass 以及 SES/AES/QES 保障等级,外加区域数据中心;我们的中国电子签名 REST API 开发者指南覆盖了本地集成模式。
- 契合 API 产品的定价 —— 不收按席位费用,小团队也能跑得起;中端市场与企业买家按定制方案合作。
更全面的平台评估,可以先看我们关于何时该比较 DocuSign 替代方案的分析,然后与 Nota Sign 团队开启对话。








