Why Hotel Parking Is Broken
Walk into the back office of almost any hotel with a car park and you will find the same things: a paper permit log, a spreadsheet of guest registrations, a queue of staff fielding calls from frustrated guests who cannot get the barrier to open, and a handful of non-guests who have worked out that the car park is effectively free. Manual whitelists go stale the moment a guest swaps vehicles or a reservation is amended. Paper permits are shared, photographed and reused. Staff overhead is real, and the revenue leak from non-guest parking abuse is rarely measured but consistently significant.
Automatic number plate recognition changes this entirely. The camera reads the plate, a REST API call returns a structured JSON response in under a second, and the system either opens the barrier or routes the vehicle elsewhere. No human in the loop, no paper trail to manage, no enforcement patrol needed for routine guest access. The number plate recognition API sits as a thin, stateless layer between the camera hardware and the Property Management System (PMS), which means it can be integrated with Oracle OPERA Cloud, Mews, Cloudbeds or Apaleo without rewriting core hotel workflows.
This guide walks through the full integration: from reservation creation to barrier open to folio charge, with code patterns, edge case handling and a GDPR-compliant architecture that satisfies the ICO's guidance on ANPR data retention.
End-to-End Data Flow: Reservation to Barrier to Folio
The overall flow has five stages. A reservation is created in the PMS and a webhook fires to your middleware, which writes the guest plate to an in-memory whitelist. On arrival, the camera captures an image and your middleware posts it to the recognition API, receiving back a plate string and a confidence score. The middleware queries the whitelist, finds a match, and signals the barrier controller to open. On exit, the middleware calculates dwell time. If the stay falls within the booked parking window, nothing more happens. If the guest has overstayed, a charge is posted programmatically to the guest folio in the PMS. Throughout, no plate image is persisted, and the recognition result is discarded as soon as the access decision is made.
Each stage is a discrete, independently testable service. The recognition API handles only optical character recognition and vehicle data enrichment. Your middleware handles business logic: whitelist matching, dwell time calculation and charge posting. The PMS handles guest records and billing. Keep those boundaries clean and the whole system remains debuggable.
Step 1: Capturing the Plate at Reservation Time
The guest plate needs to reach your whitelist before the car arrives. There are two natural trigger points: booking confirmation and online check-in. At booking confirmation, the reservation form includes a vehicle registration field. Many hotels already collect this for pre-authorisation or valet coordination; if yours does not, adding a single optional field to the booking engine is straightforward.
When the PMS fires a reservation-created or reservation-updated event, your middleware receives a webhook payload containing the reservation ID, guest name, check-in and check-out dates, and the vehicle registration if provided. Your middleware writes a whitelist record with those fields and an expiry timestamp derived from the checkout date. Here is what that write looks like in pseudocode:
POST /internal/whitelist
{
"registration": "AB12CDE",
"reservation_id": "RES-00123",
"guest_name": "J. Patel",
"valid_from": "2025-09-01T15:00:00Z",
"valid_until": "2025-09-04T11:00:00Z"
}
For OPERA Cloud, business events including reservation creation are consumed via the Oracle Hospitality Integration Platform (OHIP), which exposes these as streaming API events so third-party systems receive them in real time without polling. Mews and Apaleo both publish webhook topics for reservation events natively. Cloudbeds similarly exposes a REST API and webhook callbacks for reservation lifecycle events. The integration pattern is the same regardless of PMS: subscribe to the reservation event, extract the plate, write to whitelist.
For guests who did not provide a plate at booking, the online pre-arrival flow is the second opportunity. A pre-arrival email with a short form can capture the registration and call the same whitelist endpoint. Some properties collect it at physical check-in as a fallback.
Step 2: Reading the Plate on Arrival
When a vehicle approaches the entry camera, the camera software captures a still frame and hands it to your middleware. Your middleware makes a single POST request to the recognition API:
POST https://nprapi.com/api/v1/recognise X-API-Key: your-api-key-here Content-Type: multipart/form-data -F "image=@entry_frame.jpg" -F "vehicle=true"
The vehicle=true flag instructs the API to enrich the response with DVSA vehicle data including make, model and colour. The JSON response looks like this:
{
"success": true,
"registration": "AB12CDE",
"confidence": 97,
"credits_used": 1,
"vehicle": {
"make": "Toyota",
"model": "Corolla",
"colour": "Silver"
}
}
The confidence field is an integer from 0 to 100. Set a threshold appropriate to your camera hardware; most well-placed cameras in good light return scores above 90. Below your threshold, route to a fallback flow rather than issuing a hard denial. The vehicle data provides a secondary verification layer: if the plate matches the whitelist but the make and colour do not match what the guest declared, you can flag the vehicle for staff review rather than granting automatic access. This secondary check is particularly useful for catching cloned plates.
The full round trip from image capture to JSON response typically completes in well under a second, fast enough for barrier control without any perceptible delay to the driver.
Step 3: Barrier Control Logic
Once your middleware has the plate string and confidence score, the access decision is straightforward.
First, check the plate against the whitelist. A match with confidence above your threshold triggers an access grant signal to the barrier controller and writes an entry timestamp record, keyed on the plate and reservation ID. A non-match routes the vehicle to your secondary flow, which might be a pay-and-display terminal, an intercom to reception, or a dynamic QR code for event-day or walk-in parking.
The barrier controller signal itself is a local network call, typically a simple HTTP POST or relay trigger to the gate hardware. That hardware interface is outside the scope of the recognition API; any barrier system with a network-accessible control API or relay input will work. The recognition API's job ends at returning the plate string and confidence score.
For multi-storey or large surface car parks, set multiple=true on the recognition call. The API then returns a plates array, each item containing registration, confidence and country as an ISO 3166-1 alpha-2 code where identifiable. This is useful if your camera angle captures more than one vehicle at once, or if you are processing footage from a patrol vehicle covering a wide area.
Step 4: Overstay Detection and Folio Charge Posting
Overstay detection is arithmetic. When the vehicle exits, the camera triggers another recognition call. Your middleware retrieves the entry timestamp for that plate, subtracts it from the exit timestamp, and compares the dwell time against the booked parking window stored in the whitelist record.
If the dwell time exceeds the booked window by more than your configured grace period (fifteen minutes is a common default), your middleware calculates the overstay charge and posts it directly to the guest folio in the PMS. The mechanics differ slightly by platform. In Apaleo, you post to the Finance API folio endpoint. In Cloudbeds, you use the postItem method against the reservation folio, noting that charges can currently only be posted to the primary guest folio. In Mews, you post a product order against the reservation. In OPERA Cloud via OHIP, you use the Folio API to add a charge line. The pattern is the same across all four: reservation ID from the whitelist record, charge amount and description, POST to the PMS folio endpoint.
For non-guests who have entered via a pay-and-park flow, the overstay charge is handled by the parking operator system rather than the PMS. The recognition API exit call still provides the plate and timestamp; your middleware routes the charge differently depending on whether a whitelist record exists.
A webhook-driven architecture means your middleware reacts to the exit camera event immediately. There is no batch job, no nightly reconciliation and no manual charge entry at the front desk.
Step 5: Handling Edge Cases
Several scenarios require explicit design decisions before you go live.
Hire cars and vehicle changes
Guests arriving in a hire car will not have the plate they declared at booking. Build an override flow: the guest calls reception or uses a hotel app to add a second plate to their whitelist record. Your middleware accepts an additional plate against an existing reservation ID, with the same validity window. Limit the number of plates per reservation to two or three to prevent abuse.
Valet flows
Valet operations require a different logic path. The valet driver, not the guest, presents at the entry camera. Create a valet plate record in the whitelist linked to the reservation, with an operational validity window covering the valet's working hours. The exit event writes to a valet log rather than triggering a folio charge.
Event-day non-guest overflow
When the hotel is also serving a conference or event, you may need to open the car park to non-guests with pre-booked event parking. Generate time-bounded access codes tied to plate records, using the same whitelist infrastructure but with a separate reservation type flag. These records expire automatically when their validity window closes.
Foreign plates
The recognition API returns a country code alongside the plate string when the origin is identifiable. European plates are generally readable with high confidence. For plates from outside the standard European format, confidence scores may be lower. Apply a manual review threshold for low-confidence reads rather than a blanket denial, and surface these to reception via a staff alert.
GDPR and UK Data Protection Considerations
Vehicle registration numbers are personal data under UK GDPR and the Data Protection Act 2018. The ICO's guidance on video surveillance explicitly covers ANPR systems, confirming that vehicle registrations captured by ANPR equipment fall within the scope of data protection law. The storage limitation principle is clear: personal data must not be kept for longer than necessary, and data held beyond its useful purpose is, by definition, excessive and unlikely to have a lawful basis for retention.
The architecture described in this guide is designed for zero-retention plate processing. The recognition API is called, the plate string is returned, the access decision is made, and the raw image is discarded immediately. The only data retained is the whitelist record (the guest-provided registration linked to a PMS reservation) and the entry and exit timestamps needed to calculate dwell time and any overstay charge. Both are deleted when the checkout date passes and any dispute window closes.
Your lawful basis for processing will most likely be legitimate interests or, where parking is included as a contractual service, performance of a contract. Document your chosen basis in a Data Protection Impact Assessment before deployment. Under the ICO's video surveillance guidance, organisations using ANPR must conduct a DPIA that fully addresses the impact on individuals' rights and freedoms, since such processing is likely to result in high risk to individuals.
Signage is a hard requirement. Clear and prominent signs must be in place at all entry points, informing drivers that ANPR is in use, stating the purpose of processing and providing contact details. Entrance signs must also outline the terms of parking use. British Parking Association (BPA) Approved Operator Scheme standards apply to enforcement signage on private land in the UK. Consult your legal team to ensure signage meets both the BPA Code of Practice and ICO transparency requirements before cameras go live.
ICO fines for the most serious breaches of data protection law can reach up to £17.5 million or 4% of global annual turnover, whichever is higher. A zero-retention architecture that processes the plate and discards the image immediately is the most defensible approach and also the simplest to document in a DPIA.
PMS Compatibility Notes
The integration pattern described here applies to any PMS with a webhook and folio posting capability. The specific mechanics vary by platform.
Oracle OPERA Cloud uses OHIP, Oracle's API-first gateway, which provides a rich set of REST endpoints and streaming business events. Third-party systems subscribe to events such as reservation creation and receive them in real time, allowing your middleware to react to a new booking within seconds. Folio charges are posted via the OPERA Cloud Folio API within OHIP.
Apaleo is the most developer-friendly option. Every capability, including reservations and finance, is exposed through documented REST APIs published as OpenAPI specifications, with webhooks available for real-time events across topics including Reservation and Folio. Charges are posted to guest folios via the Finance API. Apaleo uses OAuth 2.0 for authentication; verify the current token flow in the developer documentation before building.
Cloudbeds offers a REST API and webhook callbacks. Charges are posted to the primary guest folio using the POS integration pattern documented in the Cloudbeds developer portal. As noted above, charges can currently only be posted to the primary guest folio in Cloudbeds.
Mews exposes an open API with webhook subscriptions. Charges are posted as product orders against in-house reservations, giving integrators the flexibility needed for a custom parking integration without requiring a native marketplace listing.
Regardless of PMS, always verify the specific event topic names, authentication method and folio posting endpoint in the vendor's current developer documentation before building. API details change between versions, and assuming compatibility without checking is the most common cause of integration delays.
Camera Placement for Hotel Environments
Good recognition results depend as much on camera placement as on the recognition algorithm. Hotel environments present specific challenges.
Entry canopies with overhead lighting create strong shadows on the number plate. Mount entry cameras at bumper height or low on a post, angled slightly upward at five to fifteen degrees, so the plate face is lit evenly. Avoid mounting directly overhead. For covered multi-storey decks, artificial lighting must illuminate the plate zone consistently across day and night; a mix of warm and cool LED strips helps reduce glare from reflective plates.
Height-restricted barriers need cameras placed far enough back to capture a full plate before the vehicle reaches the sensor trigger point. A minimum of three metres between camera and barrier provides adequate processing time and avoids capturing the vehicle roof rather than the plate. For dual-lane entries, use one camera per lane rather than a wide-angle covering both; shared cameras reduce confidence scores significantly on off-centre plates.
In all cases, ensure the camera lens is protected from rain splash at the entry point and recalibrated seasonally. A camera pointed into strong morning or evening sun will produce washed-out frames; orient entry cameras away from the prevailing sun direction where the site layout permits.
Getting Started with NPR API
The NPR API offers a free tier suitable for integration testing and low-volume deployments. Authentication uses an API key sent in the X-API-Key request header. A basic recognition call requires only the image submitted as a multipart form field named image. Add vehicle=true to enrich responses with DVSA vehicle data including make, model and colour. Add multiple=true to detect all visible plates in a single frame. For high-volume or batch camera feeds, the batch endpoint at https://nprapi.com/api/v1/batch accepts multiple images in a single request, with job status retrieved via GET https://nprapi.com/api/v1/batch/{uuid}.
Full API documentation, including request parameters, response schemas and code samples in multiple languages, is available at https://nprapi.com/docs. Start with a single recognition call against a test image from your chosen camera position before investing in full integration work. The confidence score returned will tell you immediately whether your camera angle and lighting are suitable, or whether adjustments are needed before you write a line of integration code.
Conclusion
A hotel ANPR system built on a clean API integration removes every manual touchpoint from guest parking: the paper permit, the whitelist spreadsheet, the front desk phone call and the end-of-month charge reconciliation. Plate data flows from the PMS reservation into a whitelist, the recognition API matches it on arrival, and the barrier opens without staff involvement. Overstay charges post directly to the guest folio. GDPR compliance is achieved by design rather than by policy, because the architecture never stores a plate image in the first place.
The recognition API is the thin layer in this stack. It does one job well: returning a plate string and confidence score in exchange for an image, quickly and reliably. The business logic lives in your middleware where it belongs, and the guest record stays in the PMS. Keep those boundaries clean, handle the edge cases described above, get your signage right, complete your DPIA, and you have a system that works reliably across any property running OPERA Cloud, Mews, Cloudbeds or Apaleo.