快递单号自动识别API能识别什么？候选快递公司与编码说明

顾客在退货页填入一串单号，系统要先知道可能由哪家快递承运，才方便将信息写入售后订单。快递单号自动识别API返回的是快递公司候选，而不是运输轨迹。查看快递100API智能单号识别技术文档，可核对输入参数及返回字段。

快递100API的智能单号识别以运单号为主要输入，返回可能所属的快递公司列表。企业可以据此给用户展示候选名称、补全内部使用的公司编码，再把最终确认结果和原订单绑定。这个能力适合订单补录、退货填单与客服查件入口，尤其是在单号已知、承运商却缺失的时候。

返回字段分别用在什么地方

技术文档列出的识别结果包括快递公司编码 comCode、公司名称 name 与单号长度 lengthPre。对业务系统而言，名称用于让人看懂并作选择，编码用于和后续查件请求及内部订单字段衔接；长度信息可供技术侧理解识别结果，不应被误当成物流状态。

快递100API按候选结果提供判断基础。即使第一家公司匹配度较高，也不能在所有场景下替用户做最终决定。退货页面可以预选并提示用户确认；客服后台则展示完整候选及修改入口。记录最终选择来自“自动推荐”还是“人工改选”，日后查不到轨迹时更容易定位原因。

多候选与空结果怎样处理

同一格式的单号可能与多家公司的规则相似。出现多个候选时，页面可把常见选择放在易读的位置，但要能展开其余候选并人工修改。若快递100API未识别出候选，正常的回退流程是保留用户输入的单号、显示快递公司选择项，再让用户继续提交或由客服复核。

“无候选”不等于包裹不存在，也不等于已发生运输异常。新号段、输入错误或数据尚不足以判断，都可能使识别结果暂时不明确。页面提示可以写成“暂未识别到快递公司，请手动选择”，而不是显示“快件丢失”。相同原则也适用于多候选：提示是帮助填单，不是对承运商的确定性声明。

识别、查询和跟踪各做什么

快递单号自动识别API解决“这张单可能属于谁”；实时查询回答“这张单目前走到哪一步”；订阅跟踪用于在后续状态变化时更新系统。三者可以接在一条订单链路里，但输出并不相同。企业若只拿到公司编码，没有调用查询能力，订单页仍不会因此出现揽收、在途或签收轨迹。

例如顾客填写退货单号，快递100API返回两家候选公司。顾客选定其中一家后，商城将编码、单号和退货订单关联；客服要看进度时再查询物流。若查无轨迹，客服可核对发货时间和先前的公司选择，而不是要求顾客重新完整填写退货信息。

把返回结果做成顺畅的产品体验

表单中识别提示应随输入完成后出现，既减少手动选择，也不阻止用户纠正。订单详情页显示的是经确认的承运商与后续真实轨迹；后台还能查看最初候选、改选记录和查询时间。快递100API提供识别与查询能力，企业业务系统负责权限控制、订单关系和售后动作，两个层次清楚，客服处理争议也有依据。

上线前用已知承运商、多候选、未识别和输入错误四组单号走一遍表单。除了接口是否有结果，还要看用户能否改选、无结果能否继续提交、订单能否保留正确编码。把这些环节接好，单号识别才能真正减少录单返工，而不只是多一次接口调用。

常见问题

接口会返回物流状态吗？

智能单号识别返回可能的快递公司信息；揽收、在途和签收轨迹由相应查询能力获取。

返回多个候选时能直接选第一家吗？

可以把第一项作为提示，但顾客和客服仍应能核对并改选，最终结果要写回订单。

comCode 可以自己按名称拼出来吗？

后续查询应使用快递100API对应的编码口径；不要仅凭中文名称自行推断请求值。

识别没有结果会影响提交退货吗？

业务页面可以提供手动选择及客服复核，让顾客保留单号并继续完成售后申请。

如何检查功能是否真的有用？

观察错误承运商的改选率、退货信息补录次数，以及客服能否从订单顺利进入查件页面。

想让顾客在订单页轻松查件？了解快递100API查询与跟踪能力，从真实运单开始体验。