Vehicle history report system with partner API

Context

A vehicle history report is bought once and in a hurry. The buyer is standing next to the car with its VIN and wants an answer within minutes. If it takes longer, they buy the report somewhere else.

The other audience is completely different. Car dealers and insurance brokers buy reports regularly and in large volumes. What matters to them is receiving reports directly in their own system, not a nice-looking page.

What needed solving

The same product had to work for both: a one-off buyer who pays immediately, and a partner who works under a contract and pays an invoice at the end of the month.

A report is built from records about the vehicle, and these come from different sources in different formats. They had to be combined into one clear document.

Reports are also bought abroad, so the website had to work in several languages.

How the system is structured

Vehicles are described by make, model, body type and country, while history records are stored separately and linked to a specific vehicle. A report is assembled from the available records, so adding a new data source does not change its structure.

A one-off buyer pays straight away, while a partner's purchases are accumulated and paid by invoice. Same product, different payment methods.

Payment by SMS is also available. It may look dated, but for a buyer standing by a car without a bank card it is the fastest way to complete the purchase within a minute.

A report can be downloaded or printed using the order code, with no account needed. The code can be shared with the seller or an insurer, and they can open the report themselves.

Partners receive reports through an API with personal access keys. The dealer gets the report straight into their own system, and the platform sees how much each key is used.

Content pages have language versions, so marketing copy and legal information can be changed without a developer.

Technical decisions

The report is assembled from records when it is opened. It is not stored as a finished document, so when a new data source appears, old reports do not need to be regenerated.

Usage is counted per key. One company may connect from several systems, so partner usage is visible for each key, not just for the account.

Two payment methods for one product. A one-off payment and a partner invoice are different processes. Merging them into one would make both more complicated.

An order code instead of an account. A one-off buyer does not create an account and returns to the report with a code. If this kind of purchase required registration, some buyers would simply leave.