What School Streets Are and Why ANPR Now Powers Them
A School Street is a road outside a school entrance that carries a temporary restriction on motor vehicles during drop-off and pick-up windows. The aim is straightforward: remove through-traffic from the area around the school gate, give children, parents and staff a safer and cleaner space to arrive and leave, and nudge families toward walking and cycling. Restrictions are implemented under a Traffic Regulation Order and typically cover a window of 30 to 60 minutes during morning and afternoon school peak times, operating on school days in term time only.
The model began with volunteers operating pop-up barriers or gates at each entry point. That worked during pilots but it does not scale. Recruiting, training and rostering enough volunteers for two daily sessions, five days a week, across a growing estate of schemes proved unsustainable. Councils across England responded by moving to camera-based enforcement using Automatic Number Plate Recognition (ANPR), a shift accelerated by the commencement of Part 6 of the Traffic Management Act 2004. From 31 May 2022, local highway authorities outside London were able to apply to the Secretary of State for civil enforcement powers over moving traffic contraventions, allowing them to issue Penalty Charge Notices without police involvement. Driving through a restricted School Street during an operational window is among the enforceable moving traffic offences under those powers.
The result is a fast-growing category of local authority software requirement. Councils need platforms that can ingest a camera trigger event, run a plate read, check it against a permit database and either clear the vehicle or open a PCN workflow, all within a few seconds. This guide walks through the technical pipeline in enough detail for a development team to build or extend such a system, using NPR API as the recognition engine.
Exemption Categories and Enforcement Logic
Before writing a line of code, it is worth being precise about who is allowed through during a restriction window, because the exemption data model flows directly from policy. Councils vary in their detail, but the common categories across England are: residents and businesses with a postal address within the restricted street; blue badge holders who need to access a property inside the zone; registered carers and healthcare workers attending patients within the street; school staff with an operational need to access the school site; emergency service vehicles; council waste collection vehicles; school buses and contracted school transport; and Hackney carriage taxis. Some councils add liveried commercial delivery vehicles to an automatic exemption list; others do not, asking businesses to schedule deliveries outside operational hours.
Each category carries different registration and evidence requirements. A resident typically supplies a V5C logbook or lease agreement together with proof of address. A blue badge holder supplies the badge number and expiry date alongside the vehicle registration mark (VRM). A carer supplies a letter from the resident's GP or the council's adult social care team. School staff are registered via the school itself. Emergency services, waste vehicles and school buses are usually auto-approved from fleet lists rather than individual applications. The key point is that every permitted vehicle is ultimately reduced to a VRM stored in the exemption database, sometimes with a validity window, a permit category and a scheme identifier.
System Architecture Overview
A production School Streets enforcement system consists of five logical layers. First, a fixed ANPR camera at each entry point to the restricted street, triggered by a vehicle crossing the detection zone and posting a captured image to a cloud endpoint. Second, a recognition service that converts the image to a plate string and confidence score. Third, an exemption database lookup that checks whether the returned VRM appears on the active whitelist for the specific scheme and the current time window. Fourth, an enforcement decision engine that either clears the event or raises a contravention record. Fifth, an evidence store and downstream integration layer that packages the event for a civil enforcement back-office or a third-party Civil Enforcement Authority system.
Camera hardware and its network connectivity sit outside this guide, but from an integration perspective all you need from the camera is a reliable HTTP POST of a JPEG or PNG image to your ingest endpoint whenever a trigger is fired. The rest of the pipeline runs in your application layer.
Calling the NPR API
The recognition step is a single HTTP call. Send a POST request to https://nprapi.com/api/v1/recognise with your API key in the X-API-Key header and the captured image as a multipart/form-data body. A minimal curl example:
curl -X POST https://nprapi.com/api/v1/recognise \
-H "X-API-Key: your-api-key-here" \
-F "image=@trigger.jpg" \
-F "vehicle=true"Setting vehicle=true instructs the API to append DVSA vehicle data, including make, model and colour, to the response alongside the plate read. For a School Streets system this is useful because it allows you to cross-check the captured image against the registered attributes of the VRM, which is covered in detail below. If the entry point has multiple lanes or you need to detect all plates visible in a single frame, add multiple=true. In that mode the response returns a plates array in which each item carries registration, confidence and country fields.
In single-plate mode the response JSON looks like this:
{
"success": true,
"registration": "AB12CDE",
"confidence": 94,
"credits_used": 1
}The confidence field is an integer between 0 and 100. For enforcement purposes you should establish a minimum acceptance threshold, typically 85 or above, below which the event is flagged for manual review rather than automated PCN issuance. Reads below that threshold still need to be retained as evidence but must not trigger automatic enforcement. This is a policy decision as much as a technical one, and your system design should make the threshold configurable per scheme.
For high-volume deployments or offline catch-up scenarios, the batch endpoint at https://nprapi.com/api/v1/batch accepts multiple images in a single request as images[] fields. Poll the job status at https://nprapi.com/api/v1/batch/{uuid} until processing completes. This is useful for clearing a backlog after a connectivity outage at the camera site.
Building the Exemption Whitelist
The exemption database is the operational heart of the system. A minimal schema for a permit record needs at least: a unique permit ID; the VRM it covers; the scheme ID it applies to (each School Street location should carry its own identifier); the permit category drawn from the taxonomy above; valid-from and valid-to dates; and a status flag so records can be suspended or revoked without deletion. Store the applicant reference for audit purposes and, where relevant, supporting evidence references such as a blue badge number and its expiry date.
The lookup at enforcement time is straightforward: given a VRM, a scheme ID and a timestamp, does an active permit record exist? In SQL that is a simple indexed query. Index on VRM and scheme ID together. Given that enforcement windows are short and camera triggers can cluster, query performance matters. A well-indexed relational database handles this comfortably, but if you are running a multi-authority SaaS platform at scale, consider caching the active whitelist for each scheme in memory for the duration of each operational window and invalidating it on any permit change.
The permit registration flow requires a public-facing web form, a council back-office review interface and a webhook or event to invalidate the cache when a permit is approved or revoked. Applications that arrive mid-window must not take effect until reviewed and approved. Build in clear status transitions: submitted, under review, approved, active, suspended, expired.
Schedule Logic: Term Dates, Windows and Edge Cases
A School Streets restriction applies Monday to Friday in term time only. Every individual school has its own term dates, its own morning window and its own afternoon window. Your schedule model must capture this per-school granularity; a single global term calendar is not sufficient.
At a minimum, store for each scheme: a list of operational date ranges (term start to term end), the morning window as a start time and end time, and the afternoon window in the same format. Then implement a function is_active(scheme_id, datetime) that returns true only when the given timestamp falls within an operational date range and within one of the time windows on a weekday.
Several edge cases demand explicit handling.
Bank holidays: England and Wales bank holidays sometimes fall within term dates. Most councils treat these as non-operational days regardless of the academic calendar. Maintain a bank holiday list, refreshed annually from the official government data feed, and exclude those dates from the active schedule.
Half-terms and teacher training days: some schools take a training day at the start of a term while others do not. The safest approach is to load each school's official term dates directly from the school rather than deriving them from a local authority-level calendar. Provide an admin interface that allows council staff to mark a specific date as non-operational for a given scheme without editing the underlying term record.
Clock changes: store all times in UTC and convert to local time at schedule evaluation. The operational windows are defined in local clock time, so an 8:30 am morning window means 8:30 am British Summer Time in summer and 8:30 am GMT in winter. Getting this wrong produces false PCN events on the days clocks change, which is precisely the kind of edge case that generates complaints and appeals.
Real-Time Enforcement Decision
Once you have a plate string and a confidence score from the API, the enforcement decision follows a sequential check. First, is the scheme currently active? Call is_active(scheme_id, now()). If false, log the event and exit without further action. Second, is the confidence score above your acceptance threshold? If not, flag for manual review. Third, does the VRM appear in the active whitelist for this scheme? If yes, log a cleared event and exit. If no match is found, open a contravention event record.
A contravention event record should capture: the scheme ID; the camera ID; the trigger timestamp in UTC; the plate string; the confidence score; the full API response JSON; the captured image filename; and the relevant contravention code from the council's Traffic Regulation Order. At this point the event enters a queue for human review before a PCN is formally issued. Fully automated PCN issuance without a human review step is not recommended and is inconsistent with how most civil enforcement authorities operate. The reviewer confirms the plate read, checks the image, confirms no matching exemption exists and authorises dispatch.
Using Vehicle Data to Cross-Check Plates
When you set vehicle=true on the recognise call, the API response includes the make, model and colour associated with the registered VRM from DVSA data. This gives you a lightweight fraud detection layer. Compare the returned make and colour against what the camera image shows. If the plate reads as a small silver hatchback but the vehicle in the image is a large black van, that is a signal worth flagging: the plate may be cloned, misread or obscured.
Do not automate a rejection on a mismatch alone. Camera angle, lighting conditions and paintwork variations mean false mismatches will occur. Instead, route any event where vehicle attributes do not broadly agree with the image to a mandatory review queue, separate from the standard contravention queue, so a reviewer can assess it with both the image and the DVSA data in front of them.
Evidence Packaging for Civil Enforcement
For a contravention to survive appeal, the evidence bundle must be complete and tamper-evident. Store for each event: the original captured image with an unambiguous filename incorporating the camera ID and trigger timestamp; the plate string; the confidence score; the full API response JSON including vehicle data fields; the scheme ID and active TRO reference; the contravention code; the result of the exemption lookup; and the name of the reviewing officer who authorised the PCN. Images should be stored as received and must not be post-processed or enhanced before storage. Generate a hash of each image file at ingest and store it alongside the file so integrity can be verified later if challenged on appeal.
UK GDPR Considerations
ANPR data, including vehicle registration numbers and the images captured by enforcement cameras, is personal data under UK GDPR. The captured image of a vehicle in a public street is also personal data where the driver or passengers could be identified from it. Local authorities operating School Streets enforcement have a clear lawful basis under Article 6(1)(e): processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority, grounded in the civil enforcement powers conferred by the Traffic Management Act 2004.
In practice this means several things for your system design. You must complete a Data Protection Impact Assessment (DPIA) before the system goes live; ICO guidance makes clear that a DPIA is required for any ANPR deployment in a public space. Images and associated data should be retained only for as long as is necessary. Where no contravention is recorded, images from cleared events should be deleted on a short cycle, typically a matter of days. Contravention images must be retained long enough to support an appeal but should be deleted once all appeal rights are exhausted. Your privacy notice, displayed on signage at each entry point to the scheme, must explain clearly what data is collected, the lawful basis, the retention period and how individuals can submit a Subject Access Request.
The NPR API call sends an image to an external processor. Ensure your data processing agreement with the API provider is in place, that data is not retained by the processor beyond the response cycle, and that all transfers comply with UK GDPR requirements.
Webhooks and Downstream Integration
Most council back-office enforcement systems and third-party Civil Enforcement Authority platforms expect to receive contravention events via a webhook or a standardised data feed rather than a manual export. Design your system to emit a webhook POST for each authorised contravention event, carrying the scheme ID, the contravention code, the VRM, the trigger timestamp and a secure URL to the evidence bundle. Use HMAC signing on the webhook payload so the receiving system can verify authenticity.
Where the downstream system expects a specific XML or JSON schema, build an adapter layer that maps your internal event model to the required format. Keep the adapter thin and the internal model clean so you can add or swap downstream targets without touching enforcement logic.
Testing and Quality Assurance
Build a test harness that covers at minimum four scenarios. First, a clearly exempt plate during an active window, which should produce a cleared event and no contravention. Second, a non-exempt plate during an active window, which should produce a contravention event. Third, a non-exempt plate outside an active window, such as during a school holiday or outside the operational time, which should produce a logged event with no enforcement action. Fourth, a low-confidence read, which should route to the manual review queue regardless of whitelist status.
Beyond happy-path testing, test against low-light and partial-plate scenarios using real images rather than synthetic ones. Night-time captures, rain on the camera lens, sun glare and partially obscured plates are all conditions your reviewers will encounter. Establish minimum image quality standards at the camera configuration level where possible, and log image quality metrics alongside each API call to build evidence for camera maintenance decisions.
Run load tests against the recognition endpoint to confirm that your ingest pipeline can handle the burst of triggers that occurs at the start of a restriction window, when multiple vehicles may attempt entry in quick succession. The API is stateless at the recognition layer, so horizontal scaling of your ingest service is straightforward.
Putting It All Together
The technical pipeline for a School Streets ANPR enforcement system is not especially complex in any single part. The challenge is getting every part right together: accurate plate reads, reliable schedule logic, a well-structured whitelist, sound evidence packaging and clean downstream integration. A recognition API that accepts an image and returns a structured JSON response with a plate string, a confidence score and optional vehicle data removes one of the harder pieces of that puzzle from your backlog.
If you are building or extending a School Streets platform for a local authority, start by integrating the NPR API recognition endpoint into your camera ingest service. The free tier at nprapi.com gives you enough credits to validate the recognition pipeline against your own camera hardware before committing to production volumes. From there, layer in the exemption whitelist, the schedule engine and the enforcement decision logic in sequence, and test each component against the scenarios above before going live with camera enforcement at any scheme. Full API documentation is available at nprapi.com/docs.