Why plate recognition alone is rarely enough
Reading a number plate is the first step, not the last. A raw plate string tells you which registration is present. It tells you nothing about whether the vehicle matches that registration, whether it is taxed, whether it holds a valid MOT, or whether it was declared off the road last week. In most production ANPR workflows, the plate read is the trigger for a vehicle data lookup, and it is that combination that makes the system genuinely useful.
This guide covers what the DVLA Vehicle Enquiry Service (VES) API returns field by field, what it deliberately withholds, where the data gaps and failure modes are in real-world deployments, and how combining plate recognition with vehicle data in a single API call compares to stitching two separate integrations together yourself.
What the DVLA VES API returns
The DVLA Vehicle Enquiry Service is a RESTful API that accepts a vehicle registration number as input and returns structured vehicle data in JSON format. It uses a POST-only endpoint, passing the registration number in the request body rather than the URL. This design is consistent with treating registration numbers as potentially sensitive personal data.
A successful response contains the following fields, though not all are guaranteed to be present for every vehicle.
Identity fields
make is the manufacturer as recorded by DVLA, for example VOLKSWAGEN or MERCEDES-BENZ. Note that this is the make only. The VES API does not return a model field in its standard response, so you will receive FORD but not FOCUS. colour is the primary colour as a capitalised string such as BLUE, WHITE or SILVER. It reflects the registered colour at the time of V5C issue and may not match a vehicle that has been resprayed. fuelType returns values such as PETROL, DIESEL, ELECTRIC or HYBRID. engineCapacity is the engine displacement in cubic centimetres as an integer. yearOfManufacture is the calendar year in which the vehicle was built. monthOfFirstRegistration is given to month and year precision only, for example 2019-07. The day is deliberately omitted to reduce the risk of identifying individuals from registration date patterns.
Tax and MOT status fields
taxStatus returns one of several string values: Taxed, SORN, Untaxed, or Not Licensed. taxDueDate is an ISO 8601 date indicating when the current tax period expires. motStatus returns Valid, Not valid, No details held by DVLA, or No results returned. motExpiryDate is the date the current MOT certificate expires and is present only when the MOT status is valid.
Emissions and type fields
co2Emissions is an integer value in grams per kilometre, useful for congestion zone checks and fleet reporting. euroStatus returns the relevant Euro emissions standard, such as EURO 6. typeApproval gives the vehicle category, such as M1 for passenger cars or N1 for light goods vehicles. revenueWeight is the revenue weight in kilograms, relevant for commercial vehicles. markedForExport is a boolean that is true if the vehicle has been marked for permanent export. dateOfLastV5CIssued is the date the most recent logbook was issued. wheelplan describes the axle configuration and appears in the official sample responses, so handle it where present.
What the DVLA VES API does not return
Understanding the gaps is as important as understanding what is present. The VES API does not return keeper name or address. Keeper information requires a formal application under Section 19 of the Road Traffic Act and is only available to specific categories of legally authorised applicant. It is not available through the VES API and cannot be obtained by calling it more cleverly.
The API also does not return MOT test history, individual test results, failure reasons, advisory notices, or mileage readings recorded at test. That data is held by the DVSA rather than the DVLA, and is accessible via the separate DVSA MOT History API. If your use case requires mileage history or a record of past failures, you need both integrations.
There is no accident history, no finance or HPI data, no previous keeper count, and no colour change history in the VES response. For those data points you need a commercial vehicle history check service, which aggregates data from multiple sources beyond what the government APIs expose.
The DVLA VES API in practice
Authentication uses an x-api-key header. Each organisation is issued a single API key, and the DVLA explicitly prohibits requesting multiple keys for the same organisation. Rate limits are applied at both the individual client level and collectively across all clients. Exceeding your allocated rate returns an HTTP 429 status. The rate limit is tied to the estimated monthly volume declared at registration time, so organisations with high-volume use cases must declare that upfront rather than scaling up silently afterwards.
There is a significant practical blocker for new projects at the time of writing. The DVLA developer portal currently states that new VES API registrations are closed while system upgrades are carried out, and the registration page confirms no new keys are being issued. There is no published timeline for when registrations will reopen. Organisations that already hold a key are unaffected, but any new project that depends on direct DVLA VES access is blocked at the first step until that changes.
Critical edge cases every developer must handle
SORN vehicles
A vehicle declared SORN (Statutory Off Road Notification) will return a taxStatus of SORN. The vehicle still exists in the DVLA database and the lookup will succeed, but it is not legally permitted on public roads. In a parking enforcement or gate management context, a SORN response should trigger a flag rather than a simple pass or fail. The vehicle data is real; the vehicle's legal road status is a separate concern from the plate read itself.
Brand-new registrations
A vehicle registered within the last few days may appear in DVLA records before its MOT record exists, since new vehicles are exempt from MOT testing for their first three years. In this case motStatus will return No details held by DVLA or No results returned. Your application logic should treat the absence of MOT data for a recent registration differently from the absence of MOT data for a ten-year-old vehicle, where the same response could indicate the MOT has lapsed.
Cherished and personalised plate transfers
A cherished or personalised registration number can be transferred between vehicles. During and immediately after the transfer process, there may be a brief window where the DVLA record is being updated and the data returned does not yet reflect the new assignment. More importantly, a personalised plate gives no reliable age information. A plate reading A1 ABC could be on a vehicle of almost any age. Your workflow should not infer vehicle age from plate format when personalised plates are in use.
Q plates and age-identifier-free plates
Q plates are assigned to vehicles of uncertain age or origin, including kit cars, vehicles assembled from multiple sources, and some imported vehicles. A Q plate vehicle will exist in the DVLA database, but the yearOfManufacture and monthOfFirstRegistration fields may be absent or set to placeholder values. Do not treat missing age data as a data error in these cases. It is a genuine reflection of uncertainty in the vehicle's history.
Foreign and non-GB plates
The DVLA VES API covers only vehicles registered in Great Britain. Northern Ireland vehicles are registered with the DVA rather than the DVLA, and a DVA-format plate submitted to the VES endpoint will return an error or no result. Foreign plates and plates from any other jurisdiction will similarly fail. Your ANPR pipeline must handle non-GB plate formats gracefully, ideally identifying them before attempting a VES lookup, and surfacing a meaningful status rather than a generic error to the end user.
How vehicle data enriches real ANPR use cases
Parking enforcement
A plate read combined with a vehicle data lookup lets an enforcement system cross-check that the make and colour of the vehicle observed on camera match what the DVLA has on record for that registration. A blue Ford that resolves to a white Audi is a strong signal of a cloned or misread plate. The plate read gets you the string; the vehicle data gets you the sanity check.
EV bay management
A gate or bay management system that reserves spaces for electric vehicles can use the fuelType field to verify automatically that the vehicle attempting to enter an EV bay is actually electric. Without the lookup the system relies on the driver to park correctly. With it, the check is automated and auditable.
Forecourt and access control
A forecourt or site access system that flags untaxed or SORN vehicles benefits directly from the taxStatus field returned in the VES response. Rather than building a separate watchlist and maintaining it manually, the system queries live DVLA data at each entry event and acts on the current status.
Dealership stock intake
When a vehicle arrives for part-exchange or stock intake, a plate read triggers a lookup that auto-populates make, colour, fuel type, engine capacity, year of manufacture, and first registration date into the dealer management system. This removes manual data entry and provides a source-of-truth baseline before any visual inspection begins.
One API call versus two separate integrations
The straightforward alternative to a combined solution is to build two separate integrations: an ANPR component that reads the plate, and a DVLA VES integration that takes the resulting string and fetches vehicle data. This works, but it introduces meaningful engineering overhead.
Every time you chain two API calls, you double the potential failure surface. The plate read can fail. The DVLA lookup can fail. The two can succeed independently but be associated incorrectly if you are not careful about sequencing and request idempotency. You also add latency: a plate read that takes 200 milliseconds followed by a DVLA lookup that takes 300 milliseconds produces a 500-millisecond pipeline minimum before any network variance is accounted for.
Beyond latency, there is the ongoing maintenance overhead. The DVLA VES API is versioned and may change its field names, response structure, or authentication mechanism over time. You are responsible for tracking those changes, updating your integration, and testing across your stack each time. As noted above, VES registration is currently closed to new applicants, which makes the two-integration approach impossible to start from scratch until that changes.
A combined ANPR and vehicle data API that accepts an image and returns plate, confidence score, make, model, and colour in a single structured JSON response collapses that pipeline to one call, one authentication credential, one error surface, and one provider to monitor for changes. For most production use cases, particularly those where time-to-first-result matters, the simpler architecture is also the more reliable one.
Handling confidence scores alongside vehicle data
Every plate recognition result should carry a confidence score: a numeric indicator of how certain the recognition engine is about the characters it has read. In a well-designed system, the score reflects aggregated character-level certainty across the whole plate string, returned as an integer from 0 to 100.
The practical question for developers is where to set thresholds. A high-confidence read, say 95 or above, combined with a vehicle data response where the make and colour match what the camera sees, is a strong combined signal that can be acted on automatically. A read with a confidence score of 72 where the returned colour is white but the camera image shows a dark-coloured vehicle is a different situation entirely: both the OCR uncertainty and the data mismatch are signals that the result should be queued for human review rather than acted on automatically.
The practical benefit of combining plate recognition and vehicle data in the same call is that your downstream logic receives all of these signals together. You do not need to join the recognition result to a separate lookup response. The structured JSON gives you registration, confidence, make, model, and colour in one place, and your routing logic can treat them as a single unit.
Code example: plate and vehicle data in one call
The following example shows a POST request to the NPR API recognition endpoint with the vehicle data flag enabled. The request sends an image file and returns a structured JSON response containing the plate string, a confidence score, and DVSA-sourced vehicle details including make, model, and colour.
curl -X POST https://nprapi.com/api/v1/recognise \
-H "X-API-Key: your-api-key-here" \
-F "image=@plate.jpg" \
-F "vehicle=true"
A successful response looks like this:
{
"success": true,
"registration": "AB21CDE",
"confidence": 97,
"vehicle": {
"make": "VOLKSWAGEN",
"model": "GOLF",
"colour": "GREY",
"fuelType": "PETROL",
"taxStatus": "Taxed",
"motStatus": "Valid"
},
"credits_used": 1
}
The vehicle=true flag is passed as a form field alongside the image. The response bundles the recognition result and the vehicle data lookup into a single JSON object. There is no second request to coordinate, no registration string to extract and re-submit, and no second set of error handling to write. If you need to detect multiple plates in a single image, adding multiple=true returns a plates array where each item includes registration, confidence, and country. Full documentation is available at nprapi.com/docs.
Conclusion
An ANPR workflow that combines plate recognition with vehicle data is considerably more useful and more defensible than one that produces raw plate strings alone. You gain make and colour confirmation to reduce false positives, tax and MOT status for compliance checks, fuel type for EV bay management, and a structured record that feeds downstream systems without manual data entry.
Building that pipeline directly against the DVLA VES API gives you an authoritative data source, but it comes with real barriers: registration is currently closed to new applicants, rate limits are tied to declared volumes, the API is POST-only with its own specific authentication pattern, and there is no model field in the standard response. Handling all of the edge cases covered in this guide, covering SORN vehicles, Q plates, cherished transfers, foreign plates, and new registrations without MOT records, requires careful defensive coding throughout your stack.
If you want to prototype the combined plate recognition and vehicle data lookup quickly, the NPR API free tier lets you send real UK registration images and receive structured JSON responses with make, model, and colour included. That is a practical way to validate your integration logic and test edge cases against real data before committing to the full architecture.