你的业务系统里，有一辆车显示 5 万公里。

这个数字，你敢直接用吗？

如果它只是卖家填写的、用户上传的，或者来自当前仪表盘，那么它最多只能说明一件事：这辆车现在显示 5 万公里。

至于它以前跑过多少、有没有调过表、历史里程有没有出现倒退，单看这个数字其实判断不了。

这也是二手车平台、汽车金融、车辆租赁和车辆审核业务里比较麻烦的一点。车辆里程本身并不难拿，难的是判断这个里程值不值得信。

传统做法通常是查保养记录、维修记录，或者安排线下检测。对于单辆车来说问题不大，但一旦进入平台化、批量化的业务场景，完全依赖人工核验，流程就会变得很重。这时候，历史里程数据的价值就出来了。

探数API的车辆里程数据查询接口，把这个问题从线下搬到了线上。输入17位VIN车架号，接口直接返回车辆的真实历史里程、里程更新时间、是否存在调表风险的评估结果，以及历史里程趋势数据。不需要线下预约检测，不需要人工比对多份记录，调用一次就能拿到核心数据。

数据来源是车联网，每月更新，覆盖新能源和燃油车，综合查得率约70%。查得计费——查询成功返回数据才计费，查无记录不扣费。

📋 返回数据长什么样

先看接口能拿到什么。

传入VIN车架号，接口返回13个字段。完整返回示例：

{
    "code": 1,
    "msg": "操作成功",
    "data": {
        "vin": "WBA51BH05PCL21797",
        "brand_name": "宝马",
        "manufacturer_date": "2023",
        "last_driving_date": "2026-06-01",
        "display_mileage_by_actual": "58500",
        "driving_date_by_actual": "2026-06-01",
        "suspected_adjust": "0",
        "suspected_mileage_before_adjust": "",
        "suspected_before_adjust_month": "",
        "suspected_mileage_after_adjust": "",
        "suspected_after_adjust_month": "",
        "history_display_mileage_list": "[{\"displayMileage\":58500,\"hasErr\":false,\"month\":\"2026-06\",\"remark\":\"正常数据\"}]",
        "check_display_mileage_attention": "[\"车辆存在调表风险\"]"
    }
}

这些字段主要是告诉你这是什么车、历史里程是多少、有没有疑似调表的信息，主要分为下面三个模块

基础信息块

前4个字段：车架号、品牌、生产年份、表显里程更新时间。用来确认”查的是哪辆车”以及数据的新鲜度。

核心里程块

中间4个字段：真实历史里程、对应行驶时间、是否疑似调表。display_mileage_by_actual 是接口通过车联网数据推算出的车辆真实历史里程数，和表显里程是两个概念。suspected_adjust 是调表风险的判断结果，0 表示未检测到异常，1 表示疑似调表。

深度分析块

后5个字段：调表前后的里程数值及时间、历史里程列表、风险备注。这些字段在疑似调表或者需要做趋势分析时才用到。

history_display_mileage_list 是嵌套的JSON数组，结构如下：

[
  {
    "displayMileage": 58500,
    "hasErr": false,
    "month": "2026-06",
    "remark": "正常数据"
  }
]

按月组织的历史里程记录，包含该月的表显里程、是否有异常标记、数据状态。连续看几个月的数据，能大致判断里程增长节奏是否在正常区间。比如一辆车3个月内从5万跳到8万，增长曲线就不太对劲。

check_display_mileage_attention 是风险提示字段，返回格式类似 ["车辆存在调表风险"]，业务侧可以拿来做界面上的风险标注。

📊 接口能力一览

接口只有一个版本，参数精简——VIN车架号必填，行驶证图片可选。没有基础版和专业版的区分，所有字段一次返回。

🚗 典型场景怎么用

场景一：二手车交易平台的车辆核验

买家在平台上看中一辆车，车辆标注了 5 万公里、个人一手。在显示这个信息之前，机构就可以用车辆里程数据查询 API 先调用一下。

接口返回 display_mileage_by_actual 是12万公里，和车商说的差距明显，再看 suspected_adjust 是不是 1——两个条件同时命中的话，系统自动打上”里程存疑”标签，提醒买家进一步核实。

机器先筛一遍，把明显有问题的车挑出来。剩下的再走正常的展示流程，不用每辆车都安排线下检测。

场景二：汽车金融风控审核

车抵贷、汽车分期这类业务放贷前，需要评估车辆残值。里程数在这里尤为重要——同年份同品牌的车，里程差一倍，残值差一截。

调用接口拿到真实里程和对应时间，和申请人自述的里程做个比对。如果接口返回的真实里程比申请人说的还低，说明车况大概率比描述的差，风控评分里加一个权重调整项。

suspected_adjust 在这个场景里是重要信号。如果车辆疑似调过表，说明上一任车主有隐瞒车况的动机，实际车况大概率比表面看起来复杂。

场景三：租赁企业的车辆巡检

租赁公司管着一批车，定期要核实际使用情况。以前靠人工看表显，或者接车载GPS，两种方式各有各的局限——表显可以调，GPS只跑运营时段。

用这个接口定期对车队的VIN号做批量查询，拉一次数据存下来。下次再查，对比两次的真实里程差值。某辆车一个月内增长远超正常运营量，或者调表风险返回了异常标记，系统里标一下，安排线下核查。

场景四：4S店和维修厂的车况诊断

车辆进店保养或维修时，技师可以直接看到当前仪表盘里程。

但如果企业自己的车辆档案中同时保存了历史里程数据，就多了一个交叉核验的维度。

例如，本次进店时车辆显示 6 万公里，但系统保存的历史查询结果中已经出现过更高里程，那么当前表显就存在进一步确认的必要。

对于已经按 VIN 建立车辆档案的维修企业，可以把每次查询到的里程数据继续保存到对应车辆记录中。

这样下一次车辆进店时，看到的不只是“这次显示多少”，而是过去不同时间点留下的里程数据。

接口速查

总结来说
查里程这件事，真正有用的不是一个”当前里程数”。

当前里程只是一个结果。一辆车之前跑过多少、什么时候跑的、有没有被人动过手脚，这些藏在历史记录里的信息，才是核验时真正要看的东西。

这个接口通过VIN车架号把这些数据搬到了线上。业务侧拿到调表风险的判断结果后，前后里程的差值越大，说明调表幅度越高。历史里程列表按月返回，连续看几个月，增长曲线有没有异常拐点一目了然。

数据每月更新，查无记录不扣费，企业实名用户联系客服开通后就能调用。如果你在做二手车平台、金融风控或者租赁管理，值得把这个接口纳入数据能力栈里。