日本海外仓与第三方物流
面向多货主、多仓库业务,由 WMS 根据货主合同、仓库和配送规则选择承运商;生成完成后,将运单号和处理结果写回对应包裹。
INTEGRATION
将 WMS、OMS、ERP 或电商系统连接至 ShippSyS,只需一套请求即可生成多家日本承运商的面单,并将 PDF、运单号和处理结果返回原系统。
免费试用可生成 100 张面单,用于验证接口、打印和结果回传。

60-SECOND OVERVIEW
/labels/validate 检查同一份数据POST /labels 批量提交面单生成任务curl -X POST \
'https://api.shippsys.com/shippsys-api/label/v1/labels?client_key=YOUR_CLIENT_KEY' \
-H 'Authorization: Bearer YOUR_TOKEN' \
-H 'Content-Type: application/json' \
-d '{ "schema_version": 1, "items": [{ "carrier": "sagawa", "client_reference": "ORDER-10001", "ship_date": "2026-08-23", "service": { "method_code": "1" }, "recipient": { "name1": "株式会社テスト", "phone": "03-1234-5678", "postal_code": "100-0001", "prefecture": "東京都", "city": "千代田区", "address1": "千代田1-1" }, "parcel": { "quantity": 1, "items": [{ "name": "商品" }] }, "payment": { "type": "prepaid" } }] }'为便于阅读,示例省略了可选字段。可用值及各承运商字段请以Quickstart和API Reference为准。
USE CASES
适合已经使用 WMS、OMS 或 ERP,但仍需登录日本承运商软件、分别制作 CSV、手动回填运单号的企业和仓库。
面向多货主、多仓库业务,由 WMS 根据货主合同、仓库和配送规则选择承运商;生成完成后,将运单号和处理结果写回对应包裹。
让运营人员继续使用熟悉的 OMS 或管理后台,无需切换到各承运商系统,即可生成面单并查看 PDF、运单号和错误原因。
复用总部 ERP 或业务系统中的订单、收件人和商品数据,将日本仓库的面单结果回传总部,减少跨团队 CSV 传递和重复录入。
FIT CHECK
如果当前业务符合以下多项情况,可重点评估 API 集成。
如果只使用一家承运商、发货量较少,并且现有承运商软件已经能够完成全部操作,则未必需要开发 API。我们会先了解当前流程,再建议使用 Web 应用(管理页面录入与 CSV 导入)、API 或 Next Engine 对接。通过 API 导入的数据也可在 Web 应用中确认、修改、打印和管理处理记录。
DATA FLOW
ShippSyS 接收发货数据后,按指定承运商和配送服务完成转换与面单生成,再将 PDF、运单号和处理状态返回原系统。
IMPLEMENTATION
确认每个货主使用的承运商、承运商客户编号、配送服务、发件人信息及面单纸张。
完成字段映射,并明确订单拆包、配送方式选择、打印状态及运单号回写规则。
准备 API 密钥,为每个包裹分配唯一管理编号,并实现提交、状态查询、结果保存和错误展示。
使用实际承运商合同、配送服务、纸张和打印机,验证正常生成、输入错误、取消、重印与重新生成。
确认 Webhook、未完成任务巡检、错误告警和每日结果核对后,再逐步切换正式业务。
RESPONSIBILITY
配送规则和现场作业状态由您的系统管理,ShippSyS 负责不同承运商的数据转换、面单生成与结果返回。
根据订单条件和仓库规则选择承运商及配送服务
校验指定承运商和配送服务是否可用
为收件信息和包裹数据添加唯一管理编号并提交
转换为承运商格式,并返回 PDF、运单号和错误信息
管理打印、贴单、复核、交接等现场作业状态
提供生成结果及可用的查询、取消和重新生成操作
API CAPABILITIES
虽然不同承运商和配送服务支持的功能有所差异,但可通过统一接口处理数据确认、异步生成、结果获取和运维操作。
OPERATIONS
除正常请求外,面单 API 的业务流程还需妥善处理包裹变化、输入错误、超时、取消和通知失败。
一张订单可能拆成多个包裹,一个包裹也可能因重新生成而更换运单号。应在订单号之外保留包裹级唯一管理编号,并记录当前有效运单号。
发生超时时,不要直接将请求认定为失败并重复提交;应先使用管理编号查询结果,确认未受理后再重新提交。
邮编、地址、电话和配送服务等错误,应显示在仓库人员可以判断并修改的位置,而不是只保留在 API 日志中。
PDF 已经生成,不代表面单已经打印并贴到商品上。系统中的生成状态与仓库现场的作业状态需要分别管理。
区分重印同一 PDF 与修改配送条件后重新生成;旧运单号应标记为不可继续使用,同时记录操作人员、原因和处理时间。
除 Webhook 外,还应通过 API 重新查询长时间未完成的数据,并监控通知重发及签名验证结果。
可用操作、必填字段和取消方法因承运商及配送服务而异。开发前请查看各承运商支持功能,并使用实际合同、纸张和打印机进行验证。
FAQ
集中说明承运商合同、100 张免费面单、开发准备和正式运行中的常见问题。
原则上需要。除了与所用承运商签约,还应准备生成面单所需的承运商客户编号和连接信息。具体资料因承运商和配送服务而异。
目前支持佐川急便、雅玛多运输、西浓运输及日本邮政 Click Post 等。服务、字段和可用操作因承运商而异,请通过承运商支持功能确认最新信息。
免费试用包含 100 张面单,可验证 API 请求、PDF 生成、实际纸张打印,以及运单号和处理结果回传。建议使用正式运行时采用的承运商合同、配送服务和打印环境。
不是。目前没有独立沙盒环境,试用请求会进入实际面单生成流程。测试前请确定测试数据、面单生成后的取消或废弃方法以及内部测试负责人,避免误用于正式发货。
请确认承运商和配送服务、合同信息、面单纸张、打印机、发件人、收件人、商品名称等输入字段,以及运单号保存位置。多货主业务还需要明确切换承运商合同信息的单位。
可通过 API 查询处理状态,并在完成后获取面单 PDF、运单号和错误信息。即使使用 Webhook,也建议保留重新查询未收到通知数据的机制。
API 对接时,应为每条发货数据设置唯一管理编号,并能够查询该编号的受理及处理结果。发生超时时,确认请求尚未受理后再重新提交,从而避免重复生成面单。
在上游系统修改内容并重新提交后,系统会生成新的面单和运单号。新运单号将通过 API 或相应对接功能回传并更新至上游系统。重新生成的面单会计入面单生成数量。
基本费用及按面单数量计算的费用请查看价格页面。集成开发和运行条件可在了解现有系统结构后另行说明。
可以。请提供正在使用的 WMS、OMS 或 ERP、承运商、月度面单量、打印环境和当前发货流程;我们会结合 API 是否适用,说明集成范围和上线步骤。
SHIPPSYS DEVELOPERS
开发者网站提供认证、请求与响应、承运商字段、错误处理、Webhook 和 OpenAPI 规范,并提供 cURL、JavaScript、Python 与 PHP 示例,便于开发人员直接核对实现方式。
现有系统请通过旧版 API 文档确认对接规格;新项目建议使用上述 ShippSyS 面单 API。
免费试用注意事项:目前没有独立沙盒环境。免费试用期间发送到 API 的内容也会作为实际面单生成任务处理。