只需车辆基础信息和候选车型时可先看 VIN 基础查询；业务要求一对一车型结果时评估精准版；需要销售代码、颜色代码或配置列表时，再选择原厂配置查询。三者用途不同，不能只按接口名称或价格判断。

三类 VIN 接口分别解决什么问题

截至 2026 年 8 月 12 日，极速车服官网分别提供 VIN 车辆识别代码查询、VIN 车辆识别代码查询（精准版）和 VIN 原厂配置查询。三页都要求传入 VIN，但返回口径和适合的下一步不同。

选择维度 VIN 基础查询 VIN 精准版 VIN 原厂配置查询
官方端点 /vin/query /vin2/query /vin3/query
官方说明重点 基础车辆信息、一对多候选 一对一车型返回 原厂配置与销售属性
典型字段 品牌、车型、年款、发动机、变速箱、carlist 车型名称、车辆型号、出厂日期、发动机号、尺寸 销售代码、销售市场、车身/内饰颜色代码、配置列表
更适合的动作 车型候选收敛、后续查件入口 需要单一车辆档案的业务核验 需要配置差异或销售属性的精细核对
主要边界 候选结果仍需确认 一对一返回不等于配件绝对适配 不同品牌返回字段可能不同，且支持范围会变化

这张表是基于三份官方文档差异形成的选型框架，不是极速车服给出的统一分级标准。生产接入仍需按账号权限、当前支持范围和实际业务字段联调。

什么时候选择 VIN 基础查询

需要先识别车辆并获得候选车型时，基础查询更适合作为第一层入口。官方文档的接口地址为 https://api.jisuepc.com/vin/query，支持 GET、POST，必填参数为 vin，还可传 caridtype 和 strict。

该接口页面明确说明是一对多返回，并将可能的车型放在 carlist 中。返回字段还包括厂家、品牌、车型、年款、发动机、变速箱、驱动方式、前后轮胎尺寸、车型 ID 以及机油、变速箱相关信息。

因此它适合以下场景：

  1. 维修接待先识别品牌、车系和可能年款；
  2. 汽配系统需要得到可供人工确认的 carid；
  3. 查询结果还要继续进入车型库、EPC 或零件搜索；
  4. 系统允许保留“待确认车型”而不是强制立即生成唯一档案。

不要直接取 carlist 第一条写入车辆主档。即使请求成功，也应结合行驶证、发动机、变速箱、年款和实车资料确认具体车款。

什么时候评估精准版

业务流程必须获得一对一车型返回时，可以评估 VIN 精准版。其官方端点为 https://api.jisuepc.com/vin2/query，请求参数只有必填 VIN，文档说明返回车辆销售名称、长宽高、指导价、年款、排量和发动机型号等信息。

精准版返回字段还包括车辆型号 model、发动机号 engineno、车身颜色、生产日期、轮胎规格、轴距、质量和燃料类型等。它更适合车辆档案补全、工单预填或需要减少人工候选选择的流程。

“精准版一对一”描述的是该产品文档的返回形态，不等于所有车辆都一定能查到，也不等于结果可以替代证件或实车核验。若接口返回 210“没有信息”，系统应进入补充资料或人工处理，不能用基础接口的第一条候选自动冒充精准结果。

什么时候需要原厂配置查询

问题落在车辆配置差异而不是基础车型名称时，应评估 VIN 原厂配置查询。其端点为 https://api.jisuepc.com/vin3/query，必填 VIN，返回参数包含销售代码 salecode、销售市场 market、车身与内饰颜色及代码、变速箱型号和 configlist 配置列表。

官网同时说明，不同品牌返回字段略有不同，页面列出的支持品牌也是核验当日的动态范围。因此数据库不宜假设所有品牌都有相同的配置字段。推荐保存：

  • 原始配置响应和查询时间；
  • 品牌、车型、销售代码等稳定检索字段；
  • configlist 的原始结构或版本化明细；
  • 缺失字段状态，区分“不适用”“本次未返回”和“解析失败”。

原厂配置能帮助处理同年款不同配置的差异，但仍不能直接承诺某个零件一定适配。进入采购或安装前，还要核对 OE 号、EPC 分组、生产批次和实物信息。

三类请求怎样统一封装

三个接口都可以用服务端 APPKEY 调用。可以建立一个统一的 VIN 查询服务，在内部按业务动作路由：

POST https://api.jisuepc.com/vin/query
POST https://api.jisuepc.com/vin2/query
POST https://api.jisuepc.com/vin3/query

appkey=YOUR_APPKEY
vin=YOUR_VIN

请求模板仅表示字段结构，未使用真实 VIN 发起查询。接口可能涉及权限、配额或计费，联调时应使用获授权的测试数据，并先确认当前产品规则。

统一服务至少保留 query_type、请求追踪 ID、脱敏 VIN、业务 status、数据版本和人工确认状态。不要把三个端点的不同结构强行压成一张完全相同的结果表；公共车辆字段可以标准化，候选列表和配置列表则分别保存。

错误码相同，业务处理仍要区分

三份文档都列出 201“VIN 为空”、202“VIN 不正确”和 210“没有信息”，系统错误包括 APPKEY、权限、次数、IP 限制、维护和停用等状态。

虽然错误码相似，业务含义要带上接口类型：基础查询无信息、精准版无信息、原厂配置无信息是三个不同状态。日志和工单应记录调用了哪个端点，避免客服只看到“210”却不知道缺少的是基础车型还是原厂配置。

总结

VIN API 选型应由结果用途决定：基础查询负责车辆候选和后续查件入口，精准版负责一对一车型信息，原厂配置查询负责销售代码、颜色和配置差异。正式接入前，应分别查看三个官方文档并按当前支持范围联调，不能把任一 VIN 查询结果直接等同于最终配件采购或安装保证。

标签：