适用场景：自研采购 ERP、跨境代购系统、供应链中台、多渠道采销平台，通过 API 拉取商品、下单、同步订单、物流、库存，打通 1688 / 阿里国际站货源到自有业务。
区分：1688 国内站、Alibaba.com国际站是两套独立开放平台，API 体系、权限、计费、风控完全隔离。
一、整体商业逻辑
核心目标：把 1688 / 国际站变成后端货源仓，实现自动化采购，减少人工复制商品、手动下单、人工查物流。
1. 业务链路（采购对接标准流程）
- 货源选品：调用商品搜索 / 图搜接口 → 获取商品标题、主图、规格 SKU、供货价、起批量、库存、运费模板、供应商信息
- 商品数据治理：清洗 1688 原始数据，映射到自有系统商品库（SKU 匹配、价格换算、规格归一化、多语言处理（国际站））
- 询价 / 确认可采：查询实时库存、是否支持代发、发货时效、起订量限制；部分供应商需要询价接口获取真实报价
- 创建采购单：API 提交采购订单，填写收货地址、SKU 数量；部分场景需要自动支付（重点：阿里官方 API 一般不支持代支付，大多只能生成订单，人工 / 自有资金账户付款）
- 订单状态同步：轮询 / 回调拉取订单状态（待付款、已付款、已发货、交易完成、退款）
- 物流面单同步：获取运单号，回写到自有系统，同步给下游买家
- 售后链路：发起退款、查询退款进度、上传凭证；售后接口权限限制通常比较严格
- 对账：采购金额、运费、优惠、退款金额拉取，内部财务对账
2. 两种商业模式，API 侧重点不一样
模式 A：代购 / 一件代发（最常见）
下游有零售订单（独立站、小店、多平台），收到客户订单 → 自动去 1688 / 国际站下单采购。
API 重点：商品采集、SKU 匹配、下单、订单 / 物流同步
商业痛点：供应商库存不稳定、价格波动、起批量限制，很容易出现 “卖出去了但 1688 没货”。
模式 B：批量集采、供应链备货
企业采购，批量下单囤货，对接供应商做长期供货。
API 重点：批量询价、合同 / 账期、大批量订单、对账、供应商绩效
商业痛点：很多大供应商不开放 API 实时库存，只能定时拉取。
3. 商业价值
- 减少人工录单、复制商品，降低人力成本
- 实时获取货源价格库存，自动比价选供应商
- 订单自动化流转，缩短履约周期
- 统一多货源（1688 + 国际站）在一套中台管理
4. 商业层面的约束（非常关键）
- API 权限不是全开放：1688 开放平台、阿里国际站开放平台，接口有准入审核，部分高级接口（下单、退款）需要企业资质、场景审核，个人开发者拿不到。
- 接口调用按量计费：商品详情、图搜等高频查询接口会消耗额度，并发越大成本越高，需要做缓存策略控制成本。
- 供应商侧不强制接入 API：API 拿到的库存很多是供应商自主维护的非实时库存，存在虚库存，不能完全当成真实可发货库存。
- 平台规则风险：批量爬取、高频采集商品，容易触发风控；禁止利用 API 做违规比价、恶意下单。
- 国际站额外商业成本：多币种、汇率、报关、物流渠道、跨境税费，API 只返回基础信息，报关清关数据很多需要额外处理。
二、技术难点
（一）商品与 SKU 层面（最大坑）
- SKU 结构混乱，匹配难度极高
1688 商家 SKU 命名非常自由：颜色 / 尺寸 / 材质混杂，同一个商品不同商家规格写法不一样；国际站还存在多语言 SKU 名称。难点：下游订单 SKU 和上游 1688 SKU 自动映射，极易匹配错，导致发错货。
- 库存非实时
API 返回库存是商家后台填写，不是仓库真实库存。下单成功 ≠ 一定有货。
技术方案：增加下单前预校验 + 下单失败重试机制 + 缺货预警。 - 价格动态变化
阶梯价、起批量、混批优惠、运费模板，规则复杂；不同采购数量对应单价不一样，需要本地复算价格。 - 图片、描述富文本脏数据
商品详情里包含 HTML、水印、外链、乱码；需要清洗、去水印、图片本地化存储，否则下游展示会异常。
（二）订单与下单接口难点
- 下单接口权限门槛高
单纯商品采集容易申请；代下单接口审核严格，阿里会评估业务场景，防止恶意刷单。 - 订单幂等性问题
网络抖动、重试请求，可能重复创建采购单。必须设计幂等号，保证同一请求不会重复下单。 - 支付能力限制
官方 API 大多不能直接代付。采购订单创建后，需要人工在 1688 后台付款，或者企业子账号资金体系，无法完全全自动闭环。 - 异步状态
订单付款、发货、退款都是异步事件。平台回调不稳定，一般采用「回调 + 定时轮询兜底」双机制。
（三）风控、限流、并发难点
- 接口 QPS 并发限制
每个应用有调用频率上限。高频场景（大量商品采集、大量订单同步）很容易被限流、返回 429。
解决方案：令牌桶限流、本地缓存商品数据、削峰、错峰轮询。 - 账号风控
API 应用 + 采购账号绑定。短时间大量下单、大量查询，会触发账号风控：验证码、限制下单、接口临时封禁。重点：不要单账号无限跑，采购账号池 + 风控监控。
- 接口版本迭代、下线
阿里开放平台会不定期下线旧接口、字段变更。没有通知的情况下，系统直接报错，需要版本管理和灰度。
（四）国际站额外技术难点（Alibaba.com）
- 多语言、多币种：返回价格为外币，需要实时汇率换算，币种精度处理。
- 询盘模式：国际站很多 B 类商家不支持直接下单，只能询盘，无法像 1688 国内站那样直接创建订单。
- 跨境物流、报关信息缺失：API 不直接提供完整报关资料，需要单独业务模块处理。
- 时区、单位差异：重量单位、发货时效是当地时区，时间字段要统一 UTC 处理。
（五）数据一致性与异常链路
- 分布式链路：下游订单 → 1688 采购单 → 物流 → 售后，任何环节失败都会造成数据不一致。
需要：本地状态机、失败重试、死信队列、人工异常工单。 - 售后接口弱：退款、退货接口能力有限，很多场景只能人工在 1688 后台操作，API 无法覆盖全部售后场景。
（六）数据合规难点
- 商品图片、描述版权：通过 API 获取商家素材，使用需要遵守商家授权，不能随意转载。
- 接口数据只能用于自身采购业务，禁止转卖、批量对外输出原始数据，违反开放平台协议会被封应用。
三、推荐系统架构极简版（采购对接中台）
下游订单系统/独立站 → 采购中台
├─ 接口网关：1688 API Client / 国际站API Client（两套SDK）
├─ 限流&缓存层：商品SKU缓存，减少API调用
├─ SKU映射引擎：规格归一化、SKU匹配
├─ 订单状态机：幂等下单、异步状态同步、失败重试
├─ 风控监控：调用量、账号异常、缺货告警
└─ 对账&日志模块
四、落地优先级建议
- 一期：商品采集、SKU 拉取、库存价格查询（最容易落地，验证货源）
- 二期：订单查询、物流同步
- 三期：采购下单接口（难度最高，需要资质审核）
- 四期：售后、对账自动化
五、常见踩坑总结
- 以为 API 库存 = 真实库存 → 大量超卖
- 不做缓存，直接实时调用商品详情 → 调用量爆炸、成本高、被限流
- 没做幂等，网络重试导致重复下单
- 混淆 1688 国内站和国际站 API，两套接口不能互通
- 期望实现全自动支付闭环，官方 API 不支持
