Why Dealership Compounds Are a Blind Spot
Walk around a busy franchised car dealership on a Saturday morning and you will see a genuinely complex logistics operation. New stock arrives on transporter lorries, part-exchange vehicles come in on customer plates, test-drive cars leave and return, trade plates move between vehicles in the prep bay, and a steady stream of service customers crosses the same access point as the sales team. Despite all this movement, most dealership software systems have no reliable, automated record of which vehicle is where at any given moment. Staff rely on paper logs, verbal handovers between shifts, and manual key-cabinet checks. The result is predictable: vehicles go missing from the compound for hours before anyone notices, test drives overrun without a prompt, and handover disputes arise because there is no timestamped proof of when a car left the site.
Automatic Number Plate Recognition addresses this blind spot directly. A camera at each site entry or exit point captures an image, an ANPR API reads the plate in under a second, and the structured JSON response feeds straight into your dealership management system. The same single API call can simultaneously log the movement, check the plate against an expected-return list, flag trade plate formats, and record vehicle identity data for evidence purposes. This guide walks through how to build those four workflows using a REST API integration, with practical code examples and the UK GDPR considerations that matter specifically in an automotive retail context.
Four Workflows, One API Call
1. Compound movement logging
Every plate that crosses a camera threshold generates an event. Your application posts the camera image to the recognition endpoint and receives a registration string, a confidence score, and optionally the vehicle's make, model, and colour. Storing that response alongside a UTC timestamp and a zone identifier gives you a continuous audit trail of compound movements without any manual data entry. A vehicle that has disappeared from the prep bay can be traced to the exact minute it left the site.
2. Test-drive return matching
When a customer takes a vehicle out, your system records the plate and the agreed return time. When the exit-lane camera fires, the API response triggers a lookup against an in-memory or database-backed list of outstanding test drives. If the plate appears in the list, the record is closed. If the clock runs past the expected return time and the plate has not been seen on the entry lane, an alert fires to the sales desk. No polling, no clipboard checks, no missed returns.
3. Trade-plate detection and allowlisting
UK trade plates follow a distinctive format: one letter followed by four digits, for example R 1234, printed in red on a white background, and issued by the DVLA. Because the plate format differs from the standard alphanumeric sequence used for registered vehicles, a simple regular-expression check on the returned registration string can identify a trade plate instantly. Your application can maintain a short-lived allowlist of your dealership's own trade plate numbers and raise a flag whenever an unrecognised trade plate lingers on site beyond a configurable time window.
4. Vehicle handover verification
The timestamped API response is an immutable record of the moment a vehicle departed the site under a customer's control. Stored alongside the handover paperwork reference, it provides evidence that can resolve disputes about vehicle condition, mileage at departure, or the exact collection time. The same logic applies to part-exchange arrivals: the entry timestamp and vehicle data create a baseline record before the car ever reaches the valuation desk.
Mapping the Site as a Multi-Zone ANPR System
A dealership is not a single access point; it is a collection of distinct operational zones, each generating different event types. Treating the site architecturally as a multi-zone ANPR deployment lets you route each camera's output to the appropriate workflow handler in your application layer.
The main entry and exit lanes serve the broadest function: logging every vehicle movement and feeding the test-drive return checker. The handover bay, often a dedicated spot in front of the showroom, is where customer collections and part-exchange arrivals happen. An ANPR camera here gives you a precise departure timestamp that is separate from, and more reliable than, the time a salesperson remembers to update a record. The service reception lane handles a different population of vehicles: customer cars booked in for work. Recognising these plates on arrival lets service staff pull the job card automatically and timestamp the vehicle's return. The preparation and valeting area, often an inner compound separated from the public-facing forecourt, benefits from a camera to track which vehicles are in prep and which are ready to move to the display area.
Each camera maps to a zone identifier in your application. When you post an image to the API, you pass the zone as metadata alongside the image, and your event handler branches on it. The recognition call itself is identical regardless of zone; only the downstream business logic differs.
API Integration Walkthrough
The NPR API accepts a multipart POST to its recognition endpoint. Authentication is handled by sending your key in the X-API-Key header. Here is a minimal compound-gate call using curl:
curl -X POST https://nprapi.com/api/v1/recognise \ -H "X-API-Key: your-api-key-here" \ -F "image=@gate_camera_frame.jpg" \ -F "vehicle=true" \ -F "scene=true"
Setting vehicle=true adds DVSA vehicle data to the response, including make, model, and colour. Setting scene=true adds contextual scene intelligence. A successful single-plate response looks like this:
{
"success": true,
"registration": "AB23 CDE",
"confidence": 97,
"vehicle": {
"make": "Ford",
"model": "Puma",
"colour": "Blue"
},
"credits_used": 1
}
The confidence field is an integer from 0 to 100. For compound logging you might accept any result above 85 and queue lower-confidence reads for a brief human review. For handover evidence, where the record may be used in a dispute, you should set a higher threshold, such as 95, and fall back to a manual check if the image quality is poor.
For a busy entry lane where multiple vehicles may queue, set multiple=true. The response then returns a plates array where each element carries a registration, a confidence score, and a country field in ISO 3166-1 alpha-2 format where the plate's origin can be identified, plus a top-level processing_time_ms value for the whole frame. This is particularly useful for transporter arrivals where several new stock vehicles may appear in a single camera frame.
Building a Test-Drive Return Checker
The test-drive tracker relies on two data points per booking: the plate captured at exit from the exit-lane camera, and the agreed return time recorded by the salesperson. When the exit event fires, your application writes a record like the following to a fast key-value store or a lightweight database table:
{
"registration": "AB23 CDE",
"zone": "exit_lane",
"departed_at": "2025-07-12T10:32:44Z",
"expected_back_by": "2025-07-12T11:02:44Z",
"salesperson_id": "SP-042",
"confidence": 97
}
A background job, or a scheduled function if you are running serverless infrastructure, checks every outstanding record every minute. If the current UTC time is past expected_back_by and no corresponding entry-lane event has been recorded for that plate, the job emits an alert. The alert can be a push notification to a mobile app, a message to a Slack or Teams channel, or an entry in a shared dashboard. No human needs to remember to check; the system does it automatically.
When the vehicle returns and the entry-lane camera fires, the API response containing the matching plate closes the record and timestamps the return. The duration is calculated automatically, giving you accurate dwell-time data that feeds into weekly reports on test-drive patterns.
Trade-Plate Detection and Allowlisting
UK trade plates are issued by the DVLA and follow a format of one letter and four digits, for example R 1234. They are physically distinctive, printed in red on a white background, and are used by motor traders to move untaxed or unregistered vehicles for legitimate business purposes such as deliveries, demonstrations, and transfers between sites. Because trade plates are attached to vehicles temporarily rather than assigned to a specific car, they carry no persistent vehicle identity of their own. Misuse of trade plates, including using them outside permitted business purposes or after a licence has expired, is a criminal offence.
For your ANPR integration, detecting a trade plate is a matter of applying a regular expression to the returned registration string:
import re
TRADE_PLATE_PATTERN = re.compile(r'^[A-Z]\s?\d{4}$')
def is_trade_plate(registration: str) -> bool:
return bool(TRADE_PLATE_PATTERN.match(registration.strip().upper()))
When is_trade_plate returns true, your application checks the plate against an allowlist of your own dealership's trade plate numbers. A match is logged as a routine movement. A plate that is not in the allowlist is flagged for attention: it could be a visiting delivery driver, a recovery vehicle, or an out-of-hours movement that warrants review. A trade plate that has been on site for longer than a configurable maximum, say four hours, triggers an escalation alert regardless of whether it is in the allowlist, since trade plates should only be in use for the duration of a specific vehicle movement and should not be left sitting in a compound indefinitely.
Handover Evidence: Building an Immutable Record
Vehicle handover disputes are a recurring source of complaints in the automotive retail sector. Customers may claim a car was delivered in different condition from the one they accepted, or that the mileage recorded on their paperwork does not match reality. An ANPR-timestamped departure record does not replace a physical walk-round inspection, but it adds a layer of corroboration that is difficult to argue with.
When the handover-bay camera captures a departing vehicle, your application stores the full API response alongside the sale reference number, the salesperson ID, and an anonymised customer identifier. The vehicle data block, containing make, model, and colour, provides an additional check: if the plate reads correctly but the model or colour does not match the sold vehicle on record, the system can raise a mismatch alert before the car reaches the public road. This catches edge cases such as a customer accidentally driving the wrong demonstrator out of a bay, or a more serious attempt to substitute vehicles.
Write this record to an append-only store, or at minimum add a database trigger that prevents deletion without an audit log entry. The goal is a record that can be produced in a complaint investigation months later with no ambiguity about when it was created or whether it has been altered.
Vehicle Data as a Second Identity Layer
The plate string alone is a single point of failure. Plates can be cloned, misread in poor light, or obscured by a tow bar. Adding the vehicle=true flag to every recognise call returns DVSA vehicle data, specifically make, model, and colour, which provides a second independent check on identity.
In your application, compare the returned vehicle data against the expected record for that plate in your stock management or DMS system. A plate that reads as AB23 CDE but whose associated DVSA data describes a red saloon when your system expects a blue SUV is a signal worth investigating. This cross-check is particularly valuable at the main entry gate, where a cloned plate on a vehicle of the wrong type would be caught before it reaches the compound interior.
The confidence score complements this. A read with 99 confidence that also matches the expected make and colour is essentially certain. A read with 88 confidence where the colour matches but the model does not should be reviewed before any automated action is triggered. Build your business logic around both signals together rather than relying on the plate string in isolation.
GDPR Considerations for Dealership ANPR
Vehicle registration marks captured by ANPR equipment constitute personal data under the UK GDPR and the Data Protection Act 2018, because a plate can be linked back to an identifiable individual via the registered keeper record. Every ANPR deployment at a dealership therefore needs a documented lawful basis. For most dealerships, legitimate interests under Article 6(1)(f) of the UK GDPR is the appropriate basis, covering operational purposes such as securing the compound and tracking vehicle movements. Before processing begins, you must complete a Legitimate Interests Assessment demonstrating that your purpose is proportionate and does not override the rights of the individuals whose plates are captured.
The ICO's guidance on video surveillance systems, which expressly covers ANPR, also expects a Data Protection Impact Assessment for deployments of this kind. You should be able to show that you have kept the number of cameras to the minimum necessary to achieve your purpose, that visible signage at all ANPR zones informs visitors that their plate will be read, and that you have a clear, accessible privacy notice explaining the purpose and retention period.
Retention is where many integrations create unnecessary risk. For most dealership workflows the plate string and associated event data are only operationally useful for a short window: test-drive tracking needs data for hours, not months; handover records need the departure timestamp but not an ongoing log of the customer's subsequent site visits. Design your schema with a defined retention schedule from the start and implement automated deletion. Where in-memory processing is sufficient, for example when a plate is simply being checked against an expected-return list with no need to store the result, process and discard without writing to any persistent store.
Customer plate data is particularly sensitive in a dealership context because it may appear in CRM records, finance agreements, and service histories. Keep your ANPR event log strictly separate from your customer database, linked only by an anonymised reference where a join is genuinely necessary. This separation limits the impact of any data breach and makes it easier to respond to subject access requests without inadvertently disclosing unrelated data.
Batch Processing for Peak Days
A busy Saturday handover day at a large dealership can see dozens of vehicles departing within a two-hour window. For real-time compound gate events, the right pattern is to push each camera frame to the recognise endpoint as it fires and handle the response asynchronously in a queue. Your camera controller posts the frame, receives the JSON response, and places the event on an internal message queue. A consumer process reads from the queue and applies the appropriate workflow logic: test-drive matching, trade-plate detection, or handover logging. This decouples the camera trigger from the business logic, keeps response times low at the gate, and allows you to replay events if a downstream service is temporarily unavailable.
For overnight or early-morning batch tasks, such as reconciling the previous day's movements against your DMS stock list to identify any vehicles with no recorded exit or entry event, the NPR API provides a dedicated batch endpoint. Submit all relevant frames in a single multipart POST to https://nprapi.com/api/v1/batch using the images[] file field. Retrieve results via a GET request to https://nprapi.com/api/v1/batch/{uuid} using the UUID returned at submission time, then run your reconciliation job against the output.
Getting Started
The NPR API is documented in full at https://nprapi.com/docs. A free tier is available for initial development and testing, which is sufficient to validate your camera placement, test your regular-expression logic against real trade-plate and standard-plate images, and confirm that the vehicle data block returns the make, model, and colour you expect for your stock vehicles.
A good starting point is to capture a test image from each of your planned camera positions during daylight and again at night, then submit each to the recognise endpoint with vehicle=true and inspect the confidence scores. Camera angle, focal length, and the presence or absence of infrared illumination all affect read quality. Identifying positions where confidence is consistently below your threshold before go-live is far cheaper than debugging a live deployment under operational pressure.
Once your camera positions are validated and your API calls are returning clean responses, instrument your application to log confidence distributions over time. A camera whose average confidence drops from 96 to 82 over several weeks is probably developing a lens contamination or alignment problem; catching it early means fixing it before it degrades your compound audit trail.
Conclusion
A dealership compound is a high-value, high-movement environment that most off-the-shelf DMS products treat as an afterthought. A single REST API call, posting a camera image and parsing the JSON response, is sufficient to build compound movement logging, test-drive return tracking, trade-plate monitoring, and timestamped handover evidence into your existing software stack. Adding the vehicle=true flag layers DVSA make, model, and colour data on top of the plate string, giving you a meaningful second identity check that a registration alone cannot provide. Approached with a clear UK GDPR framework from the outset, including a documented lawful basis, a proportionate retention schedule, and visible on-site signage, the same integration that sharpens operational efficiency also demonstrates to regulators and customers that the dealership handles vehicle data responsibly.