做新能源二手车、保险定损或者售后维保,很多时候真正麻烦的不是“没有电池数据”,而是数据不在一个地方。
同一辆车,想确认它对应的电芯类型、供应商、电芯数量、电池包容量等信息,往往需要从车型资料、车辆数据库等不同信息来源中进行核对。
而如果还要进一步了解电池当前的健康状态,则属于另一类数据,需要结合电池检测或健康度报告。
如果你的业务本身已经有 VIN,那么这件事其实可以简单很多。
输入一个 17 位 VIN,接口返回车辆、电芯、电池包和 BMS 等配置数据。
你可以把它理解成:
VIN → 匹配车辆 → 获取电池配置 → 返回 JSON
这一篇文章,我们重点看三个问题:
探数的新能源电池参数查询 API 到底能返回什么?这些数据对业务有什么用?以及它和“电池健康度”到底是不是一回事。

一次 VIN 查询,接口返回的数据主要分成 4 类:
| 数据类型 | 可以拿到什么 | 主要字段数量 |
|---|---|---|
| 🚗 车辆信息 | 品牌、生产企业、动力类型、续航、整备质量、车身尺寸等 | 11 |
| 🔋 电芯信息 | 电芯类型、供应商、型号、形状、尺寸、电压、容量、数量、重量、能量密度 | 10 |
| 📦 电池包信息 | 电池包供应商、容量、电压、能量、重量、能量密度、串并联组合 | 7 |
| ⚡ BMS 信息 | BMS 生产企业 | 1 |
一共 29 个字段。
这里有一个比较容易混淆的地方:这个接口查询的是车辆对应的电池配置数据,不是车辆当前的实时状态。
比如:
简单来说:
它更适合解决“这辆车的电池配置是什么”这个问题,而不是“这辆车现在的电池状态怎么样”。
如果你的系统需要把接口数据完整落库,可以直接按照下面的字段理解。
| 字段 | 含义 | 示例 |
|---|---|---|
vin |
VIN 车架号 | LC0C74C4XT0146687 |
brand_name |
品牌 | 特斯拉 |
manufacturer |
车辆生产企业 | 特斯拉 |
rlxs |
动力类型 | 纯电动汽车 |
scale |
车辆类别 | SUV |
driving_condition |
标称续航(km) | 593 |
full_weight |
整备质量(kg) | 1921 |
full_weight_max |
总质量(kg) | 2432 |
len |
车身长度(mm) | 4797 |
width |
车身宽度(mm) | 1920 |
height |
车身高度(mm) | 1624 |
这部分不是电池参数本身,但可以作为 VIN 对应车辆的基础信息。
对于已经建立车辆数据库的企业来说,这些字段也可以和电池信息一起保存,形成相对完整的车辆档案。
这是接口中比较集中的一部分。
| 字段 | 含义 | 示例 |
|---|---|---|
cell_type |
电芯类型 | 磷酸铁锂电池 |
cell_supplier |
电芯供应商 | 宁德时代 |
cell_code |
电芯型号 | CB280 |
cell_shape |
电芯形状 | 方壳 |
cell_size |
电芯尺寸(mm) | 6428084 |
cell_voltage |
电芯电压(V) | 3.2 |
cell_capacity |
电芯容量(Ah) | 180 |
cell_count |
电芯数量(个) | 108 |
cell_mass |
电芯重量(kg) | 3.22 |
cell_gravimetric_energy_density |
电芯重量能量密度(Wh/kg) | 180 |
其中比较值得关注的是:
cell_type、cell_supplier、cell_code 和 cell_count。
这些字段放在一起,可以更具体地了解车辆对应的电芯配置。
例如,仅知道“这是一台 62 kWh 的车”,对于一些需要进一步区分车辆电池配置的业务来说,信息可能还不够。
这时候再结合电芯类型、供应商、型号以及数量等字段,就能获得更完整的配置信息。
cell_voltage 和 cell_capacity 则属于单颗电芯的参数,可以与电池包的组合方式等字段结合查看。
| 字段 | 含义 | 示例 |
|---|---|---|
batt_pack_supplier |
电池包供应商 | 特斯拉 |
batt_pack_capacity |
电池包标称容量(Ah) | 180 |
batt_pack_voltage |
电池包标称电压(V) | 348 |
batt_pack_quantity |
电池包标称能量(kWh) | 62.5 |
batt_pack_mass |
电池包重量(kg) | 483 |
batt_pack_density |
电池包能量密度范围(Wh/kg) | 120-140 |
batt_pack_combon |
电池包组合方式 | 1P108S |
这里面,batt_pack_quantity 返回的是电池包标称能量,单位为 kWh,也就是我们日常说的“多少度电”。
batt_pack_voltage 是电池包标称电压。
batt_pack_combon 则用于表示电池包的组合方式。
例如:
1P108S
表示 1 并 108 串。
另外需要注意,batt_pack_density 可能返回类似:
120-140
这样的范围值,而不是单独的固定数值。
如果你的系统需要对这个字段进行计算,建议先按照实际返回格式进行处理。
BMS 部分目前返回:
bms_supplier
也就是 BMS 生产企业。
这个字段可以作为车辆电池配置的一部分,与其他车辆及电池字段一起保存。
对于已经建立车辆档案、售后系统或数据管理系统的企业,可以根据自己的业务需求使用这部分信息。

例如输入一个 VIN 后,可能得到这样的 JSON 结果(简写):
{
"code": 1,
"msg": "操作成功",
"data": {
"vin": "LC0C74C4XT0146687",
"brand_name": "特斯拉",
"manufacturer": "特斯拉",
"rlxs": "纯电动汽车",
"scale": "SUV",
"driving_condition": "593",
"full_weight": "1921",
"full_weight_max": "2432",
"len": "4797",
"width": "1920",
"height": "1624",
"cell_type": "磷酸铁锂电池",
"cell_supplier": "宁德时代",
"cell_code": "CB280",
"cell_shape": "方壳",
"cell_size": "64*280*84",
"cell_voltage": "3.2",
"cell_capacity": "180",
"cell_count": "108",
"cell_mass": "3.22",
"cell_gravimetric_energy_density": "180",
"batt_pack_supplier": "特斯拉",
"batt_pack_capacity": "180",
"batt_pack_voltage": "348",
"batt_pack_quantity": "62.5",
"batt_pack_mass": "483",
"batt_pack_density": "120-140",
"batt_pack_combon": "1P108S",
"bms_supplier": "特斯拉公司"
}
}
如果业务主要关注电池配置,可以重点读取:
cell_*batt_pack_*bms_supplier如果需要建立完整的车辆档案,则可以结合车辆信息字段一起保存。
例如:
cell_voltage = 3.2 V
cell_count = 108
batt_pack_combon = 1P108S
这些字段放在一起,可以帮助技术人员从电芯参数和电池包组合方式两个维度了解车辆的电池配置。
需要注意的是,不建议仅根据某一个字段去推断整套电池结构。实际使用时,可以结合接口返回的完整配置数据进行判断。
对于 B 端业务来说,电池参数API 的价值通常不只是“查一次数据”。
更实际的情况是:企业本身已经有 VIN,希望把车辆对应的电池信息补充到现有系统中。
下面几个场景比较典型。
二手新能源车评估中,车辆的电池配置是需要关注的信息之一。
如果业务系统已经获取 VIN,可以先通过接口查询车辆对应的电芯、电池包等配置,再结合企业自身的评估规则、车辆检测结果或电池健康度数据进行综合判断。
例如:
VIN
↓
查询车辆及电池配置
↓
获取电芯 / 电池包相关信息
↓
结合企业自身评估数据
↓
形成车辆评估记录
这里需要注意:
接口返回的是车辆配置数据,并不代表当前车辆的实际电池状态。
例如电池是否发生过更换、当前 SOH 如何、实际容量是否出现衰减等,都需要结合相应的检测数据或健康度数据进行判断。
所以,如果企业同时拥有:
车辆配置 + 当前电池状态
那么对于车辆评估来说,可以获得更完整的数据参考。
在涉及新能源车辆动力电池的业务中,车辆的电池配置可以作为车辆信息的一部分,用于辅助了解车辆的电池规格。
如果保险或车辆服务系统已经保存 VIN,可以将查询到的车辆、电池包及电芯相关信息与现有车辆档案关联,作为后续业务处理时的参考数据。
例如:
VIN
↓
查询车辆配置
↓
获取电池相关参数
↓
关联车辆档案
↓
作为业务参考
需要明确的是:
电池参数查询属于配置数据查询,不能替代保险定损、事故鉴定或现场检测。
对于售后维修企业来说,VIN 本身就是车辆信息管理中的重要入口。
如果售后系统已经获取 VIN,可以将接口返回的电芯、电池包及 BMS 相关信息作为车辆配置的一部分,与企业内部的车辆档案和配件信息进行关联。
这样,维修人员在查看车辆信息时,可以同时看到相应的电池配置数据。
例如:
VIN
↓
查询车辆及电池配置
↓
查看电芯 / 电池包 / BMS 信息
↓
关联企业内部车辆档案
↓
辅助售后业务查询
具体的零部件适配,仍应以企业自身的配件目录、车型资料或维修标准为准。
对于电池回收、梯次利用等业务,车辆的电池类型和配置也是需要关注的信息之一。
如果回收企业已经掌握车辆 VIN,可以先获取车辆对应的电池配置,作为回收档案中的基础信息。
后续再结合实际电池上的标识、实物检查和检测结果进行确认。
可以简单理解为:
VIN
↓
查询车辆对应的电池配置
↓
形成基础档案
↓
结合实际电池标识
↓
进行实物检查 / 检测
也就是说,VIN 查询可以作为前置的数据补充,但不能替代对实际电池的识别和检测。

做新能源车数据时,一个比较容易出现的误区,就是把“电池参数”和“电池状态”当成同一类数据。
实际上,两者解决的问题并不一样。
| 你想知道的问题 | 对应数据 |
|---|---|
| 原厂或车辆对应的电芯类型是什么? | 电池参数 |
| 电芯是哪家供应商? | 电池参数 |
| 电芯是什么型号? | 电池参数 |
| 一共有多少颗电芯? | 电池参数 |
| 电池包多少 kWh? | 电池参数 |
| 电池包怎么串并联? | 电池参数 |
| 现在 SOH 还有多少? | 电池健康度 |
| 当前续航怎么样? | 电池状态 |
| 当前充电状态如何? | 实时 / 动态数据 |
| 当前电池温度是多少? | BMS / 实时数据 |
所以,这个接口最适合放在车辆电池配置这一层。
它回答的是:
“这辆车对应的电池配置是什么?”
如果你还想知道:
“这辆车现在这块电池怎么样?”
那就需要继续使用电池健康度、检测结果或者其他实时车辆数据。
请求地址:
https://www.tanshuapi.com/market/detail-161
请求参数:
| 参数 | 必填 | 类型 | 说明 |
|---|---|---|---|
key |
是 | string | 个人中心获取 |
vin |
是 | string | 17 位 VIN 车架号 |
GET 示例:
https://www.tanshuapi.com/market/detail-161?key=你的key&vin=LC0CE6CD5M1127672
返回标准 JSON。
开发人员可以根据 code 判断请求结果,再读取 data 中的具体字段。
如果需要完整的请求参数、返回字段及错误码说明,可以直接查看对应的 API 接口文档。
如果你正在做新能源二手车、保险、售后、车辆数据管理或者电池回收相关业务,而且手里已经有 VIN,那么这套接口可以帮助你补充:
车辆 → 电芯 → 电池包 → BMS
这一层的结构化数据。
它不是用来检测电池健康度的,也不是读取车辆实时状态的。
它解决的是一个很基础、但在车辆数据业务中经常需要的问题:
知道一辆新能源车的 VIN,就可以进一步获取与车辆对应的电池配置数据。
对于已经有车辆数据库或业务系统的企业来说,这些数据可以根据实际需求用于车辆档案、配置核验、评估数据补充以及其他内部业务。
| 项目信息 | 说明 |
|---|---|
| 接口名称 | 新能源电池参数查询 |
| 查询方式 | VIN + API Key |
| 请求方式 | GET / POST |
| 返回格式 | JSON |
| 必填参数 | key、vin |
| VIN 长度 | 17 位 |
| 返回字段 | 29 个 |
| 数据类型 | 车辆、电芯、电池包、BMS 配置 |
| 数据更新 | 每日更新 |
| 计费方式 | 查得计费 |
如果你的业务不只是查询电池配置,还需要继续补充 VIN 相关数据,可以根据实际需求组合使用。
通过 VIN 匹配车辆基础信息,用于车型识别和车辆档案。
查询电池健康度、续航分析、使用习惯和充电状态等相关信息。
查询车辆里程情况及相关数据。
通过车辆信息查询维保记录。