从商业合同的角度看，API接口文档是否必须提供，核心要看当初签的协议里有没有写清楚。如果合同里明确约定了“供应商需提供完整的API文档以支持后续集成”，那这就是硬性义务，不提供就算违约。但现实中，很多B2B定制软件的合同写得比较粗糙，只规定了交付功能模块，没提接口文档的事。这时候，供应商可能会以“额外服务”为由，要求加钱才给文档。
说实话，这种情况在行业里挺常见的。有些供应商故意把API文档当成谈判筹码，想通过控制接口来绑定客户，让你离不开他。如果你在签合同前没把这点列入需求清单，后期要文档就可能被卡脖子。所以，别再傻傻相信“口头承诺”，所有关于接口文档的条款，包括格式、更新频率、使用权限，都得白纸黑字写进合同里。
另外，即便合同没写，你也可以试试从“行业惯例”来争取。在B2B定制软件领域，提供基础API文档其实算得上默认的交付物，因为没文档的话，客户连基本的数据对接都做不了。但这事不能完全依赖惯例，法律上还是以书面约定为准。建议你在项目启动前，就主动跟供应商敲定文档的交付标准，别等到二次开发时才发现没得用。
从技术角度看，没有API接口文档，二次开发几乎不可能顺利进行。API文档详细描述了系统里各个接口的功能、参数、返回格式和错误码，相当于一张技术地图。开发人员得靠它来知道怎么调数据、怎么发指令、怎么处理异常。如果你拿不到文档，那就只能“逆向工程”——通过抓包、试错来猜接口逻辑，效率极低不说，还容易搞出Bug。
我见过不少企业，因为供应商不给文档，被迫自己反编译代码或者找第三方工具破解接口。结果呢？不仅花了冤枉钱，还把系统搞得漏洞百出，最后又回头找原供应商高价修复。说白了，API文档不是锦上添花，而是必需品。它让后续的集成、扩展、维护都有据可依，不然你连系统里存了哪些数据都搞不清楚。
还有个现实问题：很多B2B定制软件是建立在供应商自己的框架上的，代码里有大量私有逻辑。如果没有文档，你根本不知道哪些接口是稳定的、哪些是内部测试用的。这就导致二次开发时，你写的代码可能跟原系统不兼容，甚至直接让主程序崩溃。所以，技术团队在评估供应商时，一定要把API文档的完整性和易用性作为硬指标，别只看功能演示。
当你要API文档时，供应商可能会找各种理由推脱。最常见的是说“文档属于商业机密，不能外泄”。这个理由听起来合理，但仔细想想，API文档只是技术描述，又不是源码，谈不上核心机密。你可以要求签保密协议，或者只提供部分接口的文档，而不是全盘公开。如果供应商连这都不答应，那大概率是想用“技术锁”来控制你。
另一种借口是“文档需要额外付费开发”。说实话，正规的软件供应商在项目交付时，应该已经同步生成了文档。如果他们说没有，说明项目管理不规范。你可以争取在合同中加入“文档是交付物的一部分”的条款，或者把文档费摊到项目总价里。对于那些临时加价的供应商，建议你评估下长期合作的风险，别被一次性的小钱绑死。
还有个实际的做法：在项目初期就要求供应商提供“API文档范例”，哪怕只是一两个接口的样例。这既能检验他们文档的质量，也能在后期谈判时作为参考。如果他拿不出任何范例，那你就要警惕了，可能他们自己都没把接口设计标准化。在这种情况下，二次开发的风险会很大，不如考虑换供应商或者用开源方案替代。
如果你已经陷入拿不到API文档的困境，别慌张，还有几条路可以走。第一，尝试通过“技术审计”来倒逼供应商。你可以聘请第三方技术团队，对现有系统做一次代码审计和接口梳理，然后以“系统安全”为由，要求供应商配合提供接口信息。这样既显得专业，又能把压力转给对方。
第二，考虑合同仲裁或法律诉讼。如果合同里有相关条款，供应商不履行就是违约，你可以通过法律途径要求他交付文档。不过这条路耗时耗钱，更适合项目金额大、纠纷严重的情况。小项目的话，建议还是优先协商，比如用延长维保期来交换文档。
最后，从长远看，最稳妥的做法是在选型时就把API开放能力作为核心考核点。选择那些提供标准化API、有开发者社区、或者支持OpenAPI规范的供应商。这类供应商通常更开放，文档也更完善。记住，B2B定制软件的二次开发不是一次性买卖，而是长期合作关系。API文档就像一把钥匙，没有它，你永远只能被困在原供应商的“技术牢笼”里。所以，早点把这事谈清楚，比事后补救要省心得多。
