ARTICLE · 1187526
App 用不了,商家说“第三方API接口坏了”:这个理由能免责吗?
接口故障发生在上游，合同责任却需要沿着交易关系判断。
付费买了会员，准备生成一份文件，页面却一直显示“请求失败”。
联系客服，得到的答复是：“第三方接口出了问题，请等待恢复。”
这样的解释，在数字服务中并不少见。但接口究竟是什么？它出了问题，用户应该找谁负责？
先说清楚：API 是什么，怎么用？
API 是 Application Programming Interface 的缩写，中文通常称为“应用程序编程接口”。它可以理解为不同软件之间按约定规则办事的通道。
拿餐厅打个比方：顾客点菜，服务员把订单交给厨房，再把菜送回来。软件也可以通过一个规定好的“窗口”，向另一个系统提出请求，取得结果。
比如，你在一款文字生成 App 中输入“帮我写一份活动方案”，点击生成。App 把请求发送给外部的人工智能服务，对方完成处理后把结果返回，App 再展示给你。这只是常见的一种实现方式，并非所有 App 都采用同样的技术结构。
整个过程可以简单写成：
1.你提出需求
2.App 调用外部接口
3.外部服务处理
4.结果返回 App
接入方通常需要申请账号和访问凭证，按接口规定发送请求，并遵守额度、计费和使用规则。普通用户不需要亲自操作这些接口，只需要在 App 中点击按钮。
API 也不只用于人工智能。查询物流、显示地图、识别图片、发起支付，都可能用到它。它既可以连接外部服务，也可以连接企业内部系统。
问题在于：你看到的是一个产品，背后提供能力的，可能是好几家服务商。任何一个关键环节出故障，都可能让你买的功能无法使用。
一、别人提供的，用户为什么还可以找你？
假设一家企业经营文字生成 App，用户向它购买会员，约定可以使用文章生成功能。某天，上游接口发生故障，核心功能持续无法使用。
用户购买的是这家企业提供的服务。企业选择哪家接口、如何安排技术供应链，通常属于其履约安排。
《民法典》第五百九十三条规定，一方因第三人的原因造成违约，仍应依法向合同相对方承担违约责任；与第三人之间的纠纷，另依法律或者约定处理。
因此，“故障出在上游”，不能单独成为经营者拒绝承担合同责任的理由。但仍须先判断，停机是否违反了经营者对用户承担的义务。
如果用户直接向接口商购买服务，App 只提供连接工具，责任结构可能不同。谁收款、谁承诺服务、谁与用户订约，都需要查清。
二、国内案例：有中间供应商，也要履行自己的义务
最高人民法院于2023年发布的网络消费典型案例中，有一起“熊某等诉某旅行社网络服务合同纠纷案”。
熊某通过旅游 App 预订自由行产品，因孩子患病申请退订。旅行社联系中间供应商后，获知取消订单存在扣除800元违约金的申请路径，却向熊某表示订单不可取消，也没有继续协助申请。
法院认为，旅行社不能以预订成功为由认定全部义务已经完成，还负有协助退订、申请退款等附随义务。其未如实告知取消政策，导致用户损失，应当赔偿。
这不是接口故障案，裁判重点是旅行社自身的告知和协助义务。不过，它提供了一个相关启示：服务背后存在供应商，并不意味着面对用户的经营者已经完成了全部义务。
放到数字服务中，除了查明故障来自哪里，还应审查经营者是否履行了相应的通知、协助和补救义务。
三、发生故障，不等于必须全额退款、赔偿一切损失
偶发几分钟延迟，与连续数日无法使用，影响显然不同。用户购买一次文件生成服务，任务最终没有完成，与包月会员期间出现短暂波动，也需要分别判断。
要看服务承诺、故障持续时间、受影响功能，以及用户受到的实际损失。
《民法典》第五百七十七条规定了继续履行、补救和赔偿损失等违约责任；第五百八十四条则要求赔偿与违约造成的损失相对应，并受到可预见性限制。
所以，用户可能有权要求补做、退还相应费用或者赔偿损失，但故障不自动等于全额退款，也不自动等于无限赔偿。
比如，用户主张“生成失败让我错过一笔大订单”，还需要证明损失确实存在、与故障有因果关系，并符合相应的赔偿范围。
四、提前写一句“第三方故障概不负责”，有用吗？
不少经营者会想到：把免责条款写进用户协议，让用户勾选同意，是否就解决了？
合理说明服务边界、维护安排和故障处理机制，与一概免除经营者责任，法律评价不同。
对于预先拟定、重复使用的格式条款，《民法典》第四百九十六条要求提供方对重大利害关系条款履行提示、说明义务；第四百九十七条规定，不合理免责或者排除对方主要权利的条款可能无效。
勾选同意，不会自动让所有免责条款有效；把文字加粗，也不能修复条款内容本身的不合理。
面向生活消费的付费服务，还要考虑消费者保护规则。如果宣传时承诺“永久稳定”“绝不掉线”，实际服务却无法兑现，也可能引发争议。经营者提供的服务信息应当真实、全面，实际质量应与所表明的质量状况相符。
五、美国案例：损失很大，上游就一定赔得很多吗？
另一个容易被忽视的问题是：经营者处理了用户损失，能否向上游追回同等金额？
美国有一起数据中心断电纠纷，值得参考。
在 HI Technology Corp.（原 InComm）诉 QTS 一案中，2019年的一次断电使 InComm 部分机房失去供电约两小时，礼品卡销售和激活业务受到影响。InComm 获得约1.73万美元服务费抵扣后，仍提起诉讼，主张损失达到数千万美元。
2023年11月3日，佐治亚州上诉法院认为，服务费抵扣并非对所主张违约的唯一救济，但维持了相关合同责任不超过100万美元的判断。这里确认的是责任上限，并不是判令赔偿100万美元。
这也不是 API 故障案，而是数据中心服务合同纠纷。它提示的商业风险很直接：业务损失可能远高于接口或基础设施服务费，而上游合同可能设置较低的赔偿上限。
经营者对用户承担的责任，不会当然等额转化为对上游的赔偿请求。
当然，美国裁判不能直接用于判断我国合同条款的效力。《民法典》第五百零六条还规定，因故意或者重大过失造成对方财产损失的免责条款无效；具体限责安排能否适用，需要结合条款性质和案情审查。
六、我控制不了接口，算不可抗力吗？
“超出我的控制”，还不足以认定不可抗力。
法律要求考察事件是否不能预见、不能避免且不能克服。普通限流、账户欠费、容量不足或维护，不能仅凭“发生在第三方”就认定为不可抗力。
如果确有重大客观事件，则应结合事件性质、履约影响和替代措施具体判断；主张合同免责，还涉及及时通知和提供证明等要求。
七、商业化前，值得准备的三件事
第一，把承诺写清楚。用户付的钱对应什么功能、次数和期限，失败后如何处理，应当容易理解，也能实际执行。
第二，让故障可以查明。保存必要的请求时间、错误类型、计费结果、协议版本和故障通知，同时控制日志中的个人信息和敏感内容。
第三，准备补救机制。失败任务能否重新执行？是否重复扣费？已生成的成果能否保存？长期无法使用时，如何延期、退款或终止服务？
接入第三方能力，可以让产品更快上线。开始收费以后，还需要把故障发生后的安排做完整。
对于用户而言，他通常无从判断背后的技术链条。他更关心的是：钱已经付了，服务没有得到，谁能给出一个明确、合理的解决办法？
本文以中国大陆法律下的一般付费数字服务关系为讨论背景。国内案例用于说明相关合同义务，外国裁判用于比较参考，均非 API 故障的同类裁判。具体责任应结合交易结构、有效约定和故障证据判断。
曹文龙 | 泰和泰（北京）律师事务所合伙人
常年为 AIGC 智能体平台、AI 影视剧项目、XR 平台及游戏公司提供数据安全、智能体合规运营、知识产权架构设计及投融资争议解决服务。
兼任北京市文化娱乐法学会合规与风控专委会主任、对外经贸大学法学院校外导师。服务涵盖世界500强、央企国企及头部数字内容平台，擅长复杂商事与知识产权难题。
主编编写《中国国际知识产权仲裁年度报告》（2026网游篇、2025软件篇、2024影视篇），受邀担任中国版权保护中心×北京大学法学院“数字版权交易与保护”研讨专家。
