网站要显示物流进度，通常不会派人到快递公司的系统里逐条查找，而是由系统按约定发出请求，取得运单状态，再展示给用户。这里的“约定入口”就是API接口。所谓API接口对接，是让两个原本独立的系统按照共同约定交换信息，并让收到的信息在各自业务中发挥作用。

对方给了接口文档，为什么还不能直接用

接口文档会写明请求发到哪里、提交什么数据、返回什么内容。拿到文档后，开发人员能着手写调用代码，但业务含义仍要核对。

以“订单状态”为例，一方的“已完成”可能指付款完成，另一方却用它表示订单已经交付。字段名称即使相同，直接同步也会造成页面显示错误。对接前要把触发时机和状态含义说清：用户付款后就推送订单，还是等商家确认后再推送？对方返回失败时，订单留在原状态，还是安排重新发送？这些约定会影响后续使用，单靠接口地址无法回答。

文档中的身份校验也关系到能否调用。对方系统可能要求请求携带授权信息，用来识别调用者并限制访问范围。测试环境调用成功，换到正式环境却提示无权限时，先核对两套环境使用的地址和授权信息，别急着修改订单数据。

调用显示成功，订单却没有同步

假设一家网店把订单推送到仓储系统。开发人员发出请求后，接口返回“接收成功”，网店后台却迟迟看不到仓库确认的结果。业务人员说“接口已经通了”，仓库人员说“订单还不能处理”，双方谈论的其实是两段不同的过程。

此时先沿着这笔订单检查：网店发出了什么内容，仓储系统返回了什么，仓储系统里是否生成了对应订单。如果返回只表示“已收到请求”，仓库接下来的校验或入库仍可能失败。双方需确认订单如何对应，尤其是再次发送时，仓储系统会识别为同一笔订单，还是生成重复记录。

处理过程中，网店可以暂时保留待确认状态，不因一次“接收成功”就向用户显示仓库已处理。仓库方面则反馈这笔订单停在哪个环节，双方据此修改字段含义或处理重复请求的方式。若仓储系统暂时无法返回最终结果，页面显示和人工处理安排也得随之调整；接口能调用，并不会自动补上缺失的反馈。

下一次联调时，双方用同一笔测试订单核对请求记录和仓库记录，再检查确认信息能否回到网店后台。此前产生的测试订单是否清理，也由双方明确，避免它们混进正式业务。

对接完成前，还要确认什么

“接口通了”一般只表示系统之间能够通信；“对接完成”还包含实际业务能否连续运转。正常订单之外，数据缺失、重复提交或对方系统暂时不可用时，系统怎样提示和留存记录，也要经过测试。出现问题后能找到具体请求，双方才有依据判断问题发生在哪里。

如果你是提出需求的业务人员，不必从代码开始沟通。先说清楚哪项工作要由系统自动完成、目前由谁操作、结果要显示在哪里。开发人员再把这些需求对应到接口文档，确认对方能提供什么数据、何时返回。准备验收时，保留一笔完整的测试记录，从发出请求一直核对到业务页面上的最终状态。