CJ接口怎么对接？管商品库存订单和物流

对接 CJ 代发，繁琐都在接口细节里

把 CJ Dropshipping 接进自己的店铺或系统，难点不在某一步，而在环节多、细节碎：先要走 OAuth 拿令牌，再分别对接商品、规格、库存、刊登、订单、运费、物流多个接口；刊登到 Shopify 还要绑配送模板，报个 7001001 之类的错误码就得翻文档查半天。自己一点点啃 API 文档，进度很慢。

这个技能能帮你做什么

它把 CJ API V2.0 的对接整理成可直接照做的接口指引。授权上，它用 accio-mcp-cli 完成 CJ OAuth 并读取访问令牌（业务调用统一带 CJ-Access-Token 请求头）；业务上，它覆盖商品列表与详情、规格、库存查询、批量刊登、我的商品和评价管理；交易上，它支持创建订单、支付余额、计算运费、查询物流跟踪；配置上，它处理 Shopify 配送模板、仓库位置、Webhook 设置和常见刊登错误码排查。

最常见的"把 CJ 商品同步刊登到 Shopify"这条链路，它会替你串清楚——从授权、选品到绑定配送模板、处理刊登错误：

怎么用它

用法是把要对接的接口任务用自然语言说清楚即可。例如可以这样对它说：

它适合这些场景：把 CJ 商品批量刊登到 Shopify 并绑定配送模板；订单产生后创建 CJ 购物订单、确认支付并跟踪物流；按 SKU 或规格 ID 查库存决定是否继续销售；刊登报 7001001、7001003 等错误时自动修复配送模板配置。

大家常问

对接 CJ Dropshipping 时，accio-mcp-cli 的 OAuth 授权和后面的 REST 业务接口是什么关系？

简单说，OAuth 授权是"门禁"、REST 接口是"房间"。accio-mcp-cli 只负责一次性的身份认证：通过 start_cj_auth 让用户登录授权、再用 get_cj_access_token 读取 accessToken 和 refreshToken，全程不做任何业务操作。之后所有商品查询、下单、物流、Webhook 等都是标准 HTTP 请求，直连 developers.cjdropshipping.com，请求头带上 CJ-Access-Token 即可。授权只做一次（除非令牌过期），业务接口则持续调用。

把 CJ 商品刊登到 Shopify 时报 7001001 或 7001003，一般是什么原因引起的？

两者都和 Shopify 配送模板（Delivery Profile）配置有关。7001001 是缺少配送模板——店铺开启了配送模板功能，但批量刊登 listedByPids 时没传 templateShopCategoryVOList 或缺有效的 deliveryProfileId；解决办法是先查可用模板再把模板 ID 传入。7001003 是模板里没启用 CJ 仓库位置（fromCj:true），CJ 关联不到发货仓；办法是在模板里勾选 CJ Dropshipping 位置或新建含 CJ 位置的模板。两者多在初次配置 CJ+Shopify 集成时出现，配好后一般不再复现。

CJ 接口里的 CJ-Access-Token 是干什么用的，为什么不能写死在代码里长期复用？

CJ-Access-Token 是 API V2.0 的身份凭证，调用任何业务接口都要在请求头携带它来证明身份与权限，通过 OAuth 流程换取。不能写死有三个原因：它有明确过期时间（accessTokenExpiryDate），过期后写死的 Token 全线返回 401；CJ 配套提供 refreshToken，本就是让你定期刷新而非用户重新授权；写死在代码（尤其前端或公开仓库）会造成 Token 泄露、无法单独吊销的安全隐患。正确做法是运行时动态获取并缓存，临期用 refreshToken 自动续期。

用 CJ 接口做代发，下单前为什么要先查实时库存和仓库位置，而不是只看商品详情？

因为商品详情页的库存是静态预设、不实时更新，热销规格可能在你浏览后已售罄，只看详情下单本质是赌运气，易超卖引发退款和客诉。要用库存接口按规格（颜色/尺寸）查实时可售量和哪个仓有货。仓库位置同样关键：CJ 在中国、美国、欧洲多地有仓，同一商品从不同仓发货时效与运费差别很大，且 Shopify 配送模板需绑定 fromCj:true 的仓库，不查清楚会刊登报 7001003。正确顺序是详情→查实时库存→查仓库位置加运费→再下单。