This is the API for dealers. One credential scoped to your own dealer group — provision branches, order AVILOO boxes, list your own tests and look up a car by VIN or registration.

Building for a marketplace? A platform that aggregates listings from several unrelated dealer groups has its own API and its own docs. Marketplace API docs →

Battery Health Check — Integration Overview

One page, no code. What our data is, what your users would see, and what it takes to put it in your product. If you are the developer, you probably want the full documentation instead.

An electric car’s battery is most of its value, and nobody can see it. A used EV with a healthy pack and one with a tired pack look identical on a forecourt and on a listing page. Buyers know this, which is why they discount every used EV to cover the risk.

Battery Health Check is an independent battery test. A dealer plugs an AVILOO unit into the car, and about three minutes later gets a measured State of Health — a cell-level analysis of the pack’s usable energy, not a reading of what the car reports about itself. The method is certified by TÜV Nord and TÜV Süd, and the certificate is issued by AVILOO GmbH.

The Partner API is how that result gets into your product. Once a dealer has tested a car, you can retrieve the result and the certificate against a VIN or a number plate, and we will push you an event the moment a new one lands.

What your users see

Two artefacts come out of every completed test, and the split is deliberate.

The full certificate (PDF)

State of Health, range, capacity, vehicle details and the VIN. This is the document for the dealer’s file and for handing to a buyer at the point of sale.

Public-facing certificate image (JPEG)

The same headline result with the VIN removed and the certificate number masked, carrying a QR code that links to AVILOO’s own validation page. This is the one designed to sit on a public listing.

Alongside them you get the underlying numbers — State of Health, measured capacity, estimated range, cell count and variance, and a full diagnostics block — so you can render your own presentation rather than just embedding an image.

How it works

A dealer tests a car. Their AVILOO unit runs the test; it takes about three minutes. Nothing is required from you.
The result lands with us. AVILOO returns the measurement, we render the certificate and the preview.
We push you an event. A bhc.test.completed webhook fires with the full result attached, signed so you can verify it came from us.
You display it. Match the result to your vehicle record — by VIN or by registration — and render the figures or the certificate image on the listing.

If webhooks do not suit your architecture, everything is also retrievable on demand: look up a VIN or a registration and get back the most recent test.

What it takes to build

The figures below are what a specialist web agency might quote for this work — an external team, building manually. They are not our estimate of the work involved, and they are included because they are the numbers most people are working from.

Scope	Typical agency quote	What it covers
Show results on listings	1–3 days	Authenticate, look up a vehicle by VIN or registration, render the figures and the certificate image.
Add live updates	+1–2 days	Receive and verify webhooks, so results appear without polling.
Full platform integration	2–3 weeks	The above, plus creating dealer records and ordering AVILOO units through the API on your customers’ behalf.

What has actually happened. Several dealers have had results and live updates running on the same day they received their credentials, working from this documentation. Others have built the listing integration themselves. The first two rows above are a small piece of work, and it is worth scoping them on that basis rather than on an agency quote.

Authentication is standard OAuth 2.0 client credentials. Responses are JSON with a stable shape. An OpenAPI 3.1 specification is published if your team generates clients.

Using result status when publishing

State of Health should be interpreted together with the result-status fields. An integration should check these fields before displaying a measured value publicly, because a completed test does not always produce a value that can be published as-is.

Three cases account for this:

The model is still in validation. AVILOO’s reference data for that model is not final, so the figure can come out above 100%. The test is genuine and the certificate is valid — but “102.9% battery health” on a listing is not a good look.
The test reached no verdict. AVILOO ran it and could not determine battery health. There will never be a number for that test.
The result has not landed yet, or the record predates some of what we now capture.

We surface all of this explicitly rather than making you infer it: a result_status field telling you how much weight that test’s figure can carry, and a separate vehicle_supported flag describing the model. They are independent — a model in validation routinely returns a perfectly usable figure, and a fully supported model can still return an inconclusive test.

Results are expressed as a measured percentage together with these status fields rather than as a graded band, so an integration can distinguish a value it can publish from one it should not.

The sample response pack includes a representative response for each of these cases.

Getting access

Credentials are issued per dealer. Dealer administrators can issue scoped integration credentials directly from the BHC portal, so onboarding an additional dealer onto an existing integration does not require action from BHC.

Access level	Who issues it	What it can do
Read-only	Any dealer, self-serve from their portal	Retrieval of test results and certificates. No provisioning or ordering permissions. Recommended for DMS and vehicle-listing integrations.
Full integration	Any dealer, self-serve	Adds dealer records and webhook management.
Provisioning	Us, by agreement	Create dealer accounts and order AVILOO units over the API. For platforms onboarding dealers at scale.
Marketplace	Us, by agreement	One credential looking up tests and certificates by VIN or registration across every dealer — for classifieds and aggregation platforms. Lookup only: there is no call that lists any dealer's test history, which is what makes that reach reasonable. See Marketplace access.

Commercial terms are agreed per partner. Everything else is self-serve — see how to integrate.

Questions we get asked

Is there a sandbox? We do not currently provide a public sandbox. For development, the sample response pack provides a representative set of responses covering successful, provisional and other result states. When an integration is ready for validation, we recommend a pilot using real tests with a participating dealer.

What vehicles are covered? The great majority of EV brands. Coverage is at the model level though, not the brand level — individual models can still be in AVILOO’s validation programme, which is what the vehicle_supported flag tells you on each result.

How do we match a result to our vehicle record? By VIN or by registration — both are searchable, and a lookup by either returns the most recent test. Where you hold both, we recommend matching on the VIN: registrations can be transferred between vehicles, and a test recorded without a registration can only be found by VIN.

Can we pass our own identifiers through? Yes. Dealers, units and tests each carry an internal_reference field which comes back to you unchanged.

How fresh is the data? A webhook fires as soon as the result lands and the certificate is rendered.

What happens if you change the API? We add fields without notice, so ignore keys you do not recognise. We do not rename or remove them, change types or units, or repurpose status codes. Anything breaking ships on a new version path, never in place.

Who do we talk to? info@batteryhealthcheck.co.uk.