Why Residential Sites Are Moving Beyond Fobs and Key Cards
RFID fobs and key cards have served residential access control reasonably well for decades, but their costs compound at scale. Fobs get lost, duplicated or passed to unauthorised users. Managing a tower block with 300 units means issuing, tracking and revoking hundreds of physical credentials, often through a concierge or managing agent who has no real-time visibility of who is on site. Number plate recognition removes the credential entirely. The vehicle itself becomes the token, and access decisions happen in milliseconds without a resident ever touching a reader.
Residential ANPR is not simply commercial car park ANPR with a different sign on the gate. A multi-storey car park processes anonymous transient vehicles and charges for time. A managed apartment block processes named residents under a tenancy agreement, stores data linked to identifiable individuals, and must handle visitors, contractors, courtesy cars and move-in or move-out events, all under the heightened UK GDPR obligations that apply when processing personal data in a residential context. This guide covers the architecture, the code, the data model and the compliance obligations you need to build it correctly.
Use Case Overview
The same core integration pattern serves several residential property types, each with slightly different requirements.
Managed apartment blocks typically have a single entry barrier or gate serving an underground or surface car park. Resident turnover is moderate but steady, and visitor traffic is high, including food delivery drivers, tradespeople and social guests. The managing agent needs a self-service portal for resident onboarding and visitor pre-registration.
Gated private estates have multiple entry points, potentially with separate pedestrian, resident vehicle and visitor vehicle lanes. Access policy may differ by gate. The system needs to enforce those rules at the allowlist query level, not just at the barrier relay.
Build-to-rent developments are operationally closer to hotels than traditional leasehold blocks. Tenancy churn is higher, corporate lets are common, and the operator often wants analytics about occupancy and parking utilisation alongside access control.
Mixed-use sites, where ground-floor retail or commercial units share a car park with residential upper floors, require time-based access rules: residents access the car park around the clock, while retail customers may be restricted to trading hours. Your allowlist query must factor in both the plate and the current time window.
System Architecture
Camera Placement
A dedicated ANPR camera at each entry and exit point is essential. ANPR cameras have a narrow task: capturing a legible plate image. Avoid using the same camera for general scene surveillance and plate capture, because the exposure and focus settings that suit one task will degrade the other. Mount the entry camera so that approaching vehicles are travelling slowly or stopping, which gives maximum dwell time and improves recognition accuracy. A horizontal angle of no more than 30 degrees off the vehicle's axis of travel is a widely observed practical limit; beyond that, perspective distortion begins to compromise character recognition. For a typical barrier-controlled residential entrance where vehicles stop before the gate, a camera mounted at approximately two to three metres height and angled slightly downward toward the front plate gives consistent results across both car and SUV heights.
IR illumination is mandatory for overnight recognition. Confirm that your chosen camera's effective IR range covers the full stopping distance before the barrier. Pair the entry camera with an exit camera of the same specification so that your system can generate dwell-time events, which are useful for detecting tailgating.
Barrier and Gate Relay Wiring
Most residential barrier controllers expose a dry-contact relay input. A pulse of typically 500 milliseconds on that contact triggers the barrier to open. Your back-end service sends the open command via a locally hosted relay controller, or via a cloud-to-edge webhook that bridges to the relay hardware, after your allowlist query returns a positive match. Keep the relay trigger logic on-site where possible: a brief internet outage should not lock residents out. A local edge agent can cache the current allowlist and process recognition results autonomously, syncing changes with the cloud back-end when connectivity resumes.
Cloud ANPR API as the Recognition Layer
Rather than running an on-premises OCR server, which requires licensed software, a powerful local machine and ongoing maintenance, you can offload all image-to-plate conversion to a cloud recognition API. The camera captures a frame on vehicle detection, and your edge agent or server posts that image to the recognition endpoint. The API returns a structured JSON response containing the plate string, a confidence score and any additional vehicle data you have requested. Your back-end then queries the allowlist and triggers the barrier relay based on the result. This separation of concerns keeps your application logic simple and lets you improve recognition accuracy by upgrading the API tier rather than replacing hardware.
Resident Allowlist Management
Data Model Design
Design your allowlist around units, not vehicles. A unit record links to one or more resident records, each of which links to one or more vehicle records. This model handles real-world cases correctly: a couple with two cars, a resident who changes their vehicle mid-tenancy, or a unit with a parking space allocated to one registered vehicle only.
A minimal vehicle record should include: the normalised registration mark (uppercase, no spaces), the unit identifier, an active boolean, a valid-from timestamp, a valid-to timestamp (null for open-ended resident access), and an optional label such as "main car" or "second car". Store registrations in a normalised form so that a plate read as "AB12CDE" and one stored as "AB12 CDE" both match without custom string logic.
Onboarding and Deactivating Access
Build an onboarding flow in your resident portal that captures the registration mark at move-in and validates its format against UK plate conventions before storing it. When a resident moves out, set the valid-to timestamp to the tenancy end date rather than deleting the record. Hard deletion breaks your audit log. Soft deactivation preserves the historical access record while immediately stopping gate access, because your allowlist query filters on both the active flag and the valid-to date.
Multiple vehicles per unit are common. Impose a configurable cap, typically two to three vehicles per unit, enforced at the application layer to match the site's allocated parking ratio. Surface a clear error to the property manager when the cap is reached rather than silently rejecting additional registrations.
Visitor Pre-Registration Flow
Visitors are where residential ANPR becomes meaningfully more complex than staff access on a commercial site. A visitor's access window is bounded by time, usually a single day or a specific arrival slot, and the resident who issued the invitation should be able to revoke it at any time.
Model a visitor token as a separate table linked to the unit: registration mark, granted-by (resident identifier), valid-from, valid-to, a single-use boolean, and a status field with values such as pending, active, used and expired. When the resident pre-registers a visitor through the portal or app, the system creates a token with the appropriate window. At the gate, the allowlist query checks the visitor tokens table using the same registration lookup, confirms that the current timestamp falls within the valid window, and, if single-use is set, marks the token as used after the first successful entry to prevent re-entry on the same token.
For deliveries or contractors with multiple entry events in a day, set single-use to false and use a wider time window instead. Add a scheduled task that runs every few minutes and marks expired visitor tokens. Do not rely on query-time expiry checking alone; stale tokens that should have been cleaned up can create confusion in audit logs.
API Integration Walkthrough
Sending a Captured Frame
Post the captured image from your edge agent to the NPR API recognition endpoint as a multipart form upload. Include your API key in the X-API-Key header. To enrich the response with vehicle make, model and colour drawn from DVSA data, add the vehicle flag as a form field.
POST https://nprapi.com/api/v1/recognise X-API-Key: your-api-key-here -F "image=@/tmp/entry_frame.jpg" -F "vehicle=true"
Parsing the JSON Response
A successful single-plate response looks like this:
{
"success": true,
"registration": "AB12CDE",
"confidence": 94,
"credits_used": 1
}
The confidence field is an integer between 0 and 100. In a residential access control context, set a minimum confidence threshold before querying the allowlist. A threshold of 85 is a reasonable starting point for a barrier-controlled entrance where vehicles are stationary or near-stationary. Below that threshold, route the event to a fallback flow rather than granting or denying access automatically.
Triggering the Barrier Relay
After parsing the registration from the API response, query your allowlist service. A minimal pseudocode flow looks like this:
plate = response["registration"]
confidence = response["confidence"]
if confidence < CONFIDENCE_THRESHOLD:
trigger_fallback_intercom(plate, confidence)
log_event(plate, "LOW_CONFIDENCE_FALLBACK")
return
match = allowlist.lookup(plate, current_timestamp)
if match:
trigger_barrier_relay()
log_event(plate, "ACCESS_GRANTED", match.unit_id, match.token_type)
else:
log_event(plate, "ACCESS_DENIED")
notify_concierge_if_configured(plate)
If your barrier controller is on-site, trigger the relay via a local REST call or MQTT message to an edge relay agent. If you are using a cloud-to-edge webhook, post the trigger command to the edge endpoint and handle timeouts gracefully with a dead-letter queue to prevent duplicate relay pulses.
Handling Edge Cases
Hire Cars and Courtesy Vehicles
A resident whose car is in for service will arrive in a courtesy or hire car with a registration that does not match any allowlist entry. Handle this with a short-term temporary vehicle registration flow, distinct from the visitor pre-registration flow, that a resident can submit via the portal before collecting the replacement vehicle. This temporary registration links to the resident's unit, carries an explicit valid-to date, and inherits the resident's access privileges rather than visitor-level restrictions.
Low-Confidence Reads
When the confidence score falls below your threshold, do not grant or deny silently. Route the event to a fallback that opens the intercom channel and alerts a concierge, or sends a push notification to the resident app with the partial plate and a prompt to confirm entry. Log the fallback event with the raw API response for later review. Reviewing low-confidence events periodically reveals whether a camera alignment or lighting problem is developing at a specific entry point.
Tailgating Detection
A second vehicle following closely behind a granted vehicle is a meaningful security risk on high-end residential sites. Implement basic dwell-time logic using your entry and exit camera pair. When the barrier closes after a granted entry, start a dwell timer. If the exit camera detects a vehicle leaving within a short window, say under 30 seconds, without a corresponding entry event, flag the sequence for review. More sophisticated setups use a loop detector or radar sensor at the barrier to count axle passes and emit an alert when more than one vehicle passes during a single gate-open cycle.
Fallback Intercom Override
Always maintain an intercom fallback. Network outages, API timeouts and camera obstructions all occur. Wire the intercom to allow manual gate release from the concierge station or a remote management interface, and ensure that every manual release is logged with a staff identifier and timestamp, just as automated events are.
Audit Logging and Event History
Every gate event, whether granted, denied, low-confidence, fallback or manual override, should produce an immutable log record. Store at minimum: a unique event identifier, the timestamp, the raw plate string returned by the API, the confidence score, the event outcome, the unit identifier if a match was found, the token type (resident or visitor), and the camera or entry point identifier.
Surface these logs in a property management dashboard with filters by unit, date range and outcome type. Property managers legitimately need to see whether a resident's vehicle has accessed the site recently if there is a welfare concern, or to reconstruct events following a security incident.
Retention should be proportionate to the purpose. A 90-day rolling retention period for routine access events is a common and defensible policy for residential sites. Retain events linked to security incidents for as long as the investigation requires, then delete. Automate deletion with a scheduled job rather than relying on manual housekeeping.
UK GDPR Compliance for Residential ANPR
Vehicle Registration Marks Are Personal Data
The ICO's video surveillance guidance explicitly covers vehicle registration marks captured by ANPR equipment as personal data, because in context they can be linked to an identifiable living individual. This applies regardless of whether the land is private. On a residential site, the link between a plate and a named resident is held directly in your own database, making identification more direct than in a public car park scenario.
Lawful Basis
For resident vehicle data, the most appropriate lawful basis for a private residential ANPR deployment is legitimate interests under Article 6(1)(f) of the UK GDPR. The legitimate interest is controlling access to private residential land and protecting residents' security and quiet enjoyment of their homes. You must document this with a Legitimate Interests Assessment covering the three-part test: confirm you have a genuine purpose, that processing plate data is necessary for that purpose, and that residents' interests and rights are not overridden. This is straightforward when residents have been informed and have a reasonable expectation that their plate is used for entry. The Data (Use and Access) Act 2025 introduced a separate recognised legitimate interests basis under Article 6(1)(ea) covering specific public interest purposes such as crime detection; that provision does not apply to routine residential access control, and Article 6(1)(f) with a full Legitimate Interests Assessment remains the correct route. For visitor plate data, the same basis applies, but you must ensure visitors are informed at the point of pre-registration and via signage at the entrance.
Data Protection Impact Assessment
The ICO's ANPR guidance requires a Data Protection Impact Assessment before deployment, and for a large residential site processing plates around the clock this is a legal requirement rather than optional best practice. The DPIA should document the cameras deployed, the data flows including any third-party API processors, the retention policy, and the controls in place to restrict access to the management portal. A Legitimate Interests Assessment can feed directly into the DPIA, reducing duplication of effort.
Privacy Notices and Signage
Display clear signage at every entrance stating that ANPR is in operation, who the data controller is, the purpose of processing, and how individuals can exercise their rights. Residents should receive a written privacy notice covering vehicle data processing as part of their tenancy documentation. Visitor privacy is served by entrance signage and, where practical, a brief notice included in the visitor pre-registration confirmation.
Data Minimisation and Retention
Collect only what the access control purpose requires. The plate string, timestamp and outcome are necessary. Storing a full video frame of every event indefinitely is not. If you use the vehicle flag to retrieve make, model and colour, document the purpose clearly; enriching a resident record with vehicle details is reasonable, but retaining that enrichment data beyond the tenancy serves no defensible purpose. Delete it on move-out along with the vehicle record. Apply a documented retention schedule and automate its enforcement.
Testing and Going Live
Staging and Accuracy Testing
Use the NPR API free tier to run recognition tests against a library of sample images captured from your target camera positions before writing a line of access-control logic. Test images should be captured in daylight, at dusk, in rain and in full darkness with IR active. Log the confidence scores for each condition. If a particular entry point consistently returns scores below 80 in wet weather, that is a camera placement or illumination problem to resolve before go-live, not a software issue to paper over with a lower threshold.
Run load tests against the recognition endpoint with realistic concurrency. On a busy residential site at morning peak, several vehicles may queue simultaneously. Measure end-to-end latency from image capture to relay trigger and confirm it is acceptable, typically under two seconds, for your gate control loop.
Go-Live Checklist
Before switching to live gate control, confirm the following: cameras are correctly positioned and illuminated; the barrier relay wiring has been tested with a manual trigger; the allowlist has been populated with all current resident plates and verified against a resident data extract; the visitor pre-registration flow has been end-to-end tested by at least one pilot resident; the DPIA is signed off; entrance signage is in place; the fallback intercom is functional and routes to a staffed endpoint; the audit log is writing to a non-deletable store; and the automated retention deletion job has been tested in staging. Run the system in shadow mode for one week before switching to live gate control, comparing what the automated system would have decided against manual gate releases, and investigate any discrepancies before go-live.
Conclusion
Plate-based access control delivers a meaningfully better resident experience than fobs and key cards, and the integration work is tractable for any engineering team comfortable with REST APIs and relational data modelling. The complexity lies in the details: the visitor token lifecycle, the low-confidence fallback, the courtesy car edge case, and the UK GDPR obligations that make residential data handling distinct from a commercial car park deployment. Get those right, and the recognition layer itself is straightforward: post a frame, parse the JSON, query the allowlist, pulse the relay.
To start building, sign up for the NPR API free tier at nprapi.com and review the full API documentation at nprapi.com/docs. Run your first plate recognition call against a test image before touching any gate hardware. The free tier is sufficient for staging, accuracy validation and load profiling, giving you a clear picture of the integration before you go anywhere near a live barrier.