商品条码查询API和条码生成API怎么选
要根据条码查商品名称、品牌或规格，选商品条码查询 API；要把已有条码号生成条码图片，或从条码图片读出编码，选条码生成识别 API。两者的输入、结果和错误处理不同，不能因为都带“条码”就互相替代。
商品录入、库存盘点和商品详情页经常同时出现“查条码”和“出条码”两个动作，但它们解决的是相反方向的问题：前者是由编码得到商品资料，后者是由已有编码得到可展示或可识别的图像。先拆清楚这个方向，才能避免把查询接口当作制码工具。
先按业务动作分流
| 业务动作 | 应优先查看的接口 | 当前文档列出的关键输入 | 结果应如何使用 |
|---|---|---|---|
| 输入商品条码，补全商品资料 | 商品条码查询 API | barcode | 读取名称、品牌、规格等返回字段，按业务需要入库或展示 |
| 已有条码号，要生成条形码图片 | 条码生成识别 API 的生成入口 | type、barcode、字号、DPI、比例、高度 | 取得 Base64 编码的条码图片内容后，由应用按需要展示或保存 |
| 手里是条码图片，要读出编码 | 条码生成识别 API 的识别入口 | barcode，可传 Base64 或可访问的条码图片地址 | 根据返回的条码类型和编码内容继续做校验或查询 |
这三步可以串联，但不是必须串联。例如，后台要批量生成货架标签时，只需要生成能力；客服输入一个商品编码寻找资料时，只需要查询能力。
商品条码查询适合“编码到商品资料”
极速数据的商品条码查询 API当前说明支持以 69 开头的 EAN-8、EAN-13 商品条码查询，请求参数为必填的 barcode。文档列出的返回字段包括商品名称、英文名称、品牌、规格型号、条码类型、图片链接、净含量等。
因此，它更适合商品建档、收银辅助、客服查询和商品详情补全。接入后不要假定每次都能补齐所有字段：接口的业务错误码中，210 表示没有信息；203、204、205 分别对应已下市、已注册但编码信息未按规定通报、条码异常，文档同时标注这三种情况会扣次数。对这类结果应记录原因、停止无意义重试，并给业务人员保留人工补录路径。
查询到资料也不等于可以直接替换自有商品主数据。对于库存、价格、上架状态等内部字段，仍应以企业自己的商品系统和审核规则为准；商品条码查询页面并没有把它定义为库存或价格决策接口。
条码生成识别适合“编码和图像之间转换”
极速数据的条码生成识别 API把生成和识别放在同一产品页：生成入口为 https://api.jisuapi.com/barcode/generate，当前文档列出 EAN13、EAN8、CODE11、CODE128、CODE39、CODE93、GS1128、I25、ISBN、MSI、UPCA、UPCE、CODEBAR 等条码类型；生成结果中的 barcode 字段是条码图片的 Base64 编码。
若要从图片读取编码，则使用 https://api.jisuapi.com/barcode/read。该入口的 barcode 参数支持 Base64 或可访问的条码图片地址，页面注明图片文件最大支持 500K。识别结果用于提取条码类型与编码内容，之后若还需要商品名称和规格，再把编码交给商品条码查询接口。
生成接口和识别接口的错误码也应分开处理。页面列出 201 条码类型不正确、202 条码号为空、203 条码不正确、206 条码地址不正确、210 没有信息。不要把所有非零状态都提示为“商品不存在”，因为它们可能分别是输入格式、图片地址或数据缺失问题。
一个实用的接入顺序
- 先确定输入载体。 输入是数字条码，就在“查询商品资料”和“生成图片”之间选；输入是图片，再走识别入口。
- 再确定页面需要的结果。 商品名称、品牌、规格等资料走查询；条形码视觉资产走生成；编码提取走识别。
- 最后设计异常分流。 参数错误请用户修正；没有信息进入人工补录或自有商品库查询；文档标注可能扣次的条码状态避免自动重试。
API 文档示例都使用 APPKEY 鉴权，并通过 JSON 的 status 与 msg 判断业务结果。APPKEY 不应放在浏览器端、图片 URL 或公开日志中；对需要识别的图片，也应确认其来源和存储权限符合自身业务要求。
截至 2026-08-06，商品资料检索可查看商品条码查询 API 文档，制码与读码可查看条码生成识别 API 文档。先按“查资料、生成图片、识别图片”选入口，能避免重复采购和错误的重试策略。
