英国的车辆数据格局是专家的世界：一个提供者为MOT历史，另一个为服务时间表，第三个为估值，第四个为规格。One Auto API的业务建立在结束这种分散，将市场上最好的数据源整合在一个API后面，这样经销商、平台和车间软件只需集成一次，就可以根据需要开启产品。
多年来，货架上缺少一个产品：图片。客户解析的每一辆车都以干净、结构化的数据形式到来，没有图像，因为图像是唯一无法单独作为 JSON 字段发送的车辆属性。这就是我们的用武之地。
图像作为数据产品
让这项合作成功的洞察是，车辆影像的行为与One Auto API的目录中其他内容完全相同。他们的客户已经通过平台识别车辆；图像只是针对同一请求解析的另一种产品。Vehicle Imagery在他们的API后端插入，客户通过他们已经运行的同一集成获得正确车辆的工作室图像，图像大小由他们在其他地方使用的相同参数控制。
一个无聊的集成
合作的静默超能力在于它所不做的事情。当我们的目录扩展到现场工厂颜色时，更新通过One Auto API的平台流动，作为每辆车可用颜色的更大列表，无需他们进行集成工作。当他们的客户需要特定的图像尺寸时，高度和宽度参数直接传递。我们这边的目录增长变成了他们那边的产品改进，自动进行。
- 一个集成服务 One Auto API 的整个客户群
- 八个外部视图加内饰，可按需提供
- 颜色和覆盖更新随数据而来，而不是项目
- 基于域的许可，因此最终用户可以像其他产品一样开启图像
已在生产中运行
这种模式在实践中得到了验证：平台客户已经从评估到完成集成，再到按固定月费使用的合同生产，图像已经进入了生产使用。对于这些客户，没有需要管理的第二个供应商关系。影像只是One Auto API堆栈的一部分，通过我们的CDN下方提供。
覆盖双向流动
这项合作也可以反向进行。当One Auto API的客户需要我们尚未覆盖的车辆时，特别是在商用车辆范围内，摄影一直是最薄弱的环节，他们的请求直接输入到我们的目录路线图中。他们的市场需求提升了我们的覆盖范围，每个下游平台客户都从这些增加中受益。
为什么这个故事不仅仅局限于英国
One Auto API 就是现代数据平台合作的样子：我们继续专注于图像，他们继续专注于聚合，双方都不要求对方成为其他事物。对于任何地方的平台在权衡是否要构建图像层还是插入一个图像层，这是一个可行的答案。
