How Our MOT Checker Works

The DVSA MOT History API: What It Is and How We Access It

The DVSA MOT History API is a REST API operated by the Driver and Vehicle Standards Agency, the government body responsible for setting and enforcing roadworthiness standards across Great Britain. It holds the complete MOT test record for every vehicle that has been tested since the national digital database was consolidated. The API is the authoritative, machine-readable version of the same underlying data that powers the official GOV.UK vehicle enquiry service.

Access to the API is not open to the general public. To consume it legally and reliably, an organisation must apply to the DVSA, agree to the API terms of use, and obtain a set of credentials. Those credentials consist of a client ID and a client secret, which are used in an OAuth 2.0 client credentials flow to request a short-lived bearer token. That token is then passed as a header on every API request to prove the caller is authorised. Our integration follows this flow exactly.

The API endpoint accepts a single query parameter: the vehicle registration mark (VRM). It returns a JSON document containing vehicle-level metadata and a chronological array of every MOT test on record for that registration. We parse that JSON entirely on our server and pass a structured, sanitised subset to the browser for display. The raw API response never touches the client side, which means our API credentials remain protected at all times.

OAuth 2.0 Client Credentials Flow: A Plain-English Explanation

OAuth 2.0 is the industry-standard protocol for authorising machine-to-machine API calls. In the client credentials grant type, there is no human user logging in. Instead, our server presents its client ID and client secret to the DVSA authorisation server and receives a bearer token in return. That token has a defined expiry, typically one hour, after which a new token must be requested.

Every live MOT query our tool makes first checks whether a valid cached token exists in server memory. If the token has expired, our server silently re-authenticates before making the data request. This process is invisible to you as a user: from your perspective you type a plate and receive results. The OAuth handshake adds only a few milliseconds of overhead and only when a token renewal is needed.

The bearer token is stored only in server-side memory for the duration of its validity window. It is never written to disk, never logged, and never transmitted to the browser. This means even if someone intercepted your browser traffic, they would see the formatted MOT result but have no way to derive our API credentials from it.

Number Plate Normalisation, Validation, and Sanitisation

Before any registration number reaches our server, the front-end JavaScript applies a first layer of normalisation. The input value is trimmed of leading and trailing whitespace, converted to uppercase, and all non-alphanumeric characters including spaces, hyphens, and dots are stripped. This means a user can type "ab12 cde", "AB12-CDE", or "ab12cde" and all three resolve to the identical query string "AB12CDE" that the API expects.

A lightweight regular expression then validates the resulting string against the known patterns of Great Britain registration marks. Current-format plates follow the pattern of two letters, two digits, a space, and three letters (for example, AB12 CDE). Older prefix-format plates and suffix-format plates follow different patterns. Q plates, Z plates for personal imports, and specialist vehicle registrations are also handled. Our validation layer rejects strings that cannot match any known UK registration format before they leave the browser, saving a server round trip and giving the user immediate feedback.

On the server side, a second sanitisation pass removes any character that is not in the set A-Z or 0-9. This guards against injection attempts, path traversal strings, or any payload that might have bypassed the front-end validation. The sanitised value is then URL-encoded before being appended to the DVSA API request. At no point does unsanitised user input reach the API or our server logs.

What the DVSA API Returns: Reading the JSON Response Fields

The DVSA MOT History API returns a single JSON object for each successful vehicle lookup. Understanding the structure of this response helps explain exactly what you see on screen and, equally importantly, what the tool cannot show you. The top-level object contains vehicle-level fields and a nested array called motTests that holds one entry per recorded test event.

Vehicle-Level Fields

The vehicle-level section of the response carries the registration mark, make, model, colour, fuel type, cylinder capacity in cubic centimetres, and the first-used date. The first-used date is important: it is the date the vehicle was first registered for use on UK roads, which determines when the first MOT becomes legally required (three years after first use for most private cars). Our tool uses this field to identify new vehicles that have not yet reached their first MOT due date.

The dvlaId field returned at vehicle level is an internal DVSA identifier. It is not the same as the DVLA's own vehicle identifier used in the VES API. We do not display this internal ID to users, but we use it for consistency checking when cross-referencing with DVLA data. The registrationDate field may differ from firstUsedDate for vehicles that were manufactured for stock and registered later.

The motTests Array: Per-Test Fields

Each entry in the motTests array represents one complete test event. The DVSA returns tests in reverse-chronological order, meaning the most recent test appears at index zero of the array. Our front-end renders the most recent test prominently and places older tests in a collapsible history section. The ordering is always newest first regardless of when the test was entered into the system.

How MOT Advisories Are Structured in the Response

The rfrAndComments array within each test object contains one entry per item noted during the inspection. Each entry carries a type field that classifies the item as one of several categories: FAIL, ADVISORY, PRS (pass with rectification at station), MINOR, or DANGEROUS. This classification maps directly to the UK MOT defect categories introduced in the 2018 testing directive updates. Our tool colour-codes each item accordingly: dangerous and major defects in red, advisories in amber, and minor items in grey.

Each advisory or failure item also carries a text field containing a standardised description written by the tester, and a dangerous boolean flag. The text is free-form prose rather than a structured code, which means parsing it for machine-readable subcategories is not straightforward. We display the text verbatim as supplied by the DVSA, without modification or paraphrasing, to preserve accuracy. Testers sometimes include location qualifiers such as "nearside front" or "offside rear" in the text field, and these appear in our display exactly as written.

It is worth noting that advisory items are informational rather than mandatory. A vehicle can pass its MOT while carrying multiple advisories. Advisories indicate items that are not yet at a failure standard but are deteriorating and should be monitored. Our display makes this distinction clear by grouping failures and advisories into separate labelled sections within each test row.

How Mileage Is Captured and What It Means

The odometerValue in each test record is the reading taken by the MOT tester from the vehicle's odometer at the time of the test. Testers are required to record this reading as part of the test procedure. The figure is stored in the DVSA database against that specific test event and cannot be retroactively altered once submitted. This creates a permanent mileage audit trail that is one of the most useful features of the MOT history dataset.

When a sequence of historical tests shows mileage progressing normally over the years, it provides reasonable evidence that the odometer has not been tampered with (a practice known as clocking). However, the DVSA data alone is not definitive proof of clocking, because there are legitimate reasons mileage may appear to stagnate or regress, such as an odometer replacement or an instrument cluster swap following accident damage. If the notes from a tester mention an odometer replacement, that text would appear in the rfrAndComments array for that test.

The odometerResultType field tells you the quality of the reading. When it returns "READ" the tester successfully recorded a figure from a working odometer. "UNREADABLE" means the odometer could not be read (for example a broken instrument cluster). "NO_ODOMETER" applies to vehicles such as certain motorcycles or specialist vehicles that are not fitted with an odometer at all. Where the result type is anything other than "READ", our display adds a clear qualifier note next to the mileage field.

Data Freshness: How Often the DVSA Updates and What "Real-Time" Actually Means

The phrase "real-time data" is used widely in the vehicle checking industry, but it is worth being precise about what it means for MOT data. When an approved test station completes an MOT test, the result is submitted to the DVSA's central system via the VTS (Vehicle Testing Station) software. In the overwhelming majority of cases, this submission happens automatically and immediately upon the tester signing off the test certificate. The DVSA API can return that result within minutes.

However, the DVSA does not guarantee instantaneous propagation. Their published guidance states that newly completed tests should appear in the API within approximately 24 hours, though in practice the data is typically available within a few minutes for stations with a stable connection to the DVSA system. Delays beyond a few minutes are rare but do occur, particularly for stations experiencing connectivity issues or for tests completed very close to midnight when batch processes may run.

Our tool does not introduce any additional delay between the DVSA API and your browser. We do not cache API responses at the application level: each search triggers a fresh call to the DVSA endpoint. This means the freshness of what you see is bounded only by the DVSA's own propagation time, not by any staleness in our layer. The only server-side state we maintain is the OAuth token described earlier, and that is not data, merely authentication state.

Number Plate Not Found: What Happens and Why

When the DVSA API returns a 404 response for a given registration, our tool displays a "no record found" message. There are several distinct reasons this can occur, and they are not all equally serious. Understanding the difference helps you decide what action to take.

Reasons a Lookup May Return No Result

• The vehicle is under three years old and has never been required to have an MOT. Cars, motorcycles, and most light vehicles are exempt from MOT testing for the first three years after first registration.
• The vehicle is permanently exempt from MOT testing. Vehicles first used before 1 January 1980 are currently exempt in Great Britain, as are certain agricultural vehicles, some electric vehicles manufactured before specific dates, and vehicles with a historic vehicle classification.
• The registration mark was entered incorrectly. Transposing characters is very common: the letter O and the digit 0, or the letter I and the digit 1, are frequent sources of confusion. Our validation attempts to flag obvious character confusions, but an incorrect plate that happens to match a different vehicle format will proceed to the API.
• The vehicle was registered in Northern Ireland and its records are held by the DVA rather than the DVSA. NI registrations (which follow a three-letter, four-digit format ending in Z for newer plates) are not in the DVSA database.
• The vehicle is a new import that has not yet been assigned a GB registration mark or whose test history is held under a different mark.
• The vehicle has been involved in a SORN declaration and was tested under a temporary mark during that period.

In all these cases, a no-result response does not mean the vehicle is unroadworthy or has a hidden MOT failure. It simply means the DVSA's MOT History API has no record under that specific registration mark. Our "no result" page explains the most common reasons and guides users toward the appropriate next step for their situation.

• A no-result response does not confirm the vehicle has a valid MOT. It only confirms no record was found.
• Do not assume a vehicle is exempt just because the checker returns no result. Verify exemption status using DVLA or DVSA guidance.
• A no-result for a vehicle you know has been tested is not conclusive: try re-entering the plate carefully before drawing conclusions.

Test Centre Names, Tester IDs, and Anonymisation in the API Data

Each test record in the API response carries information about where and by whom the test was conducted. The test station name is included in the response as a text string, typically the trading name under which the VTS is registered with the DVSA. We display this as "Test Centre" in the history view so users can see a vehicle's testing history across different garages. This is useful for provenance checks: if a car has always been tested at the same independent garage in the same town, that pattern is informative.

The DVSA does include a tester ID field in the raw API response, but this is an anonymised numerical identifier rather than the name of the individual tester. The DVSA anonymises tester identities in the public-facing API specifically to protect the privacy of individual vehicle examiners and to prevent harassment of testers whose pass/fail decisions are disputed. Our tool does not display the tester ID field at all, as it carries no actionable meaning for the end user and showing an opaque number would only create confusion.

The testStationName field can sometimes carry a generic or abbreviated name rather than the full trading name of the garage. This happens when the station was registered under a parent company name rather than its local brand. If the name displayed looks like a corporate abbreviation, the vehicle was likely tested at a franchised dealership or a large chain workshop that operates multiple stations under a single DVSA registration.

How Results Are Rendered on Screen: Front-End Architecture and Privacy by Design

Our tool is built as a static website. The HTML, CSS, and JavaScript files that make up the user interface are served from a CDN and contain no server-side rendering logic. When you load the page, you are downloading a set of completely static assets that have no knowledge of any vehicle. The MOT query itself is made via a serverless function, a small piece of server-side code that runs only when invoked by a search and terminates immediately after returning a response.

The serverless function receives your sanitised registration, authenticates with the DVSA API using the OAuth flow described above, fetches the JSON response, and returns a structured result object to the browser. Crucially, the function does not write anything to a database, does not append the registration to any log file, and does not associate the query with any user session or IP address. The result object travels from the function directly to your browser over HTTPS and is rendered into the result card by JavaScript running entirely client-side.

This architecture means there is no server-side record of what plates have been searched. Even if someone were to gain access to our server infrastructure, they would find no historical lookup data to extract. The only record of a search ever existing is in your own browser's memory for the duration of your session. When you close the tab or navigate away, that data is gone. This is privacy by design rather than privacy by policy.

HTTPS and Data in Transit

All communication between your browser and our servers, and between our servers and the DVSA API, takes place over TLS (Transport Layer Security), which is the technology underlying HTTPS. We enforce TLS 1.2 as a minimum and strongly prefer TLS 1.3 where the client supports it. HTTP requests to our domain are automatically redirected to HTTPS with a 301 permanent redirect, and we serve a Strict Transport Security header to instruct browsers to always use HTTPS for our domain in future visits.

The DVSA API endpoint also enforces HTTPS, meaning all OAuth token requests and data queries are encrypted in transit. Our server-to-DVSA connection uses modern cipher suites and verifies the DVSA server's TLS certificate against its root certificate authority. This protects against man-in-the-middle interception at every step of the data journey.

Cookie Policy and What We Do Not Track

Our MOT checker does not set any cookies during a vehicle lookup. There are no session cookies, no tracking cookies, no analytics cookies placed on your device when you perform a search. The tool functions entirely without client-side state persistence. This is an intentional design decision driven by two goals: to keep the service genuinely privacy-respecting and to avoid the regulatory overhead of cookie consent banners that add friction to the user experience.

We do use standard server-access logs at the infrastructure level, which record the IP address, timestamp, and URL path of each HTTP request. These logs are a standard part of server operation and are used solely for diagnosing technical faults. They are not linked to any personal profile, not shared with third parties, and are rotated after a short retention period. Importantly, the URL path logged for a MOT query does not include the registration number, which is passed as a JSON body rather than as a URL parameter.

If you use a browser that itself applies tracking protection (such as Firefox with Enhanced Tracking Protection or Brave), those protections have nothing to block on our site because we do not load any third-party tracking scripts, analytics libraries, or advertising tags. The network activity from a MOT search on our site consists of a request to our own domain only. No third-party domains receive any signal that a search took place.

What This Checker Cannot Tell You

The DVSA MOT History API is authoritative for MOT testing data, but it does not cover every aspect of a vehicle's background that a buyer or owner might want to know. Being clear about these limitations is an important part of honest disclosure. The following information is outside the scope of what our tool can provide.

• Outstanding finance: whether the vehicle is subject to a hire purchase agreement, conditional sale, or other secured finance arrangement. This information is held by credit reference agencies and finance houses, not the DVSA.
• Insurance status: whether the vehicle currently has a valid insurance policy in force. The Motor Insurance Database is operated by the Motor Insurers Bureau and is not accessible via the DVSA API.
• Stolen vehicle status: whether the vehicle has been reported stolen to the police. This information is held on the Police National Computer and is not returned by the DVSA API.
• Write-off category: whether the vehicle has been declared a Category A, B, S, or N insurance write-off. Write-off data is held by insurance companies and the MIAFTR register, not the DVSA.
• Number of previous owners: registered keeper history is held by the DVLA in its licensing records and is not available through the MOT History API.
• Import history: whether the vehicle was originally manufactured for a market other than the UK and subsequently imported.
• Recall status: whether any outstanding manufacturer safety recalls apply to the vehicle. Recall data is held by the DVSA's separate recall database, not the MOT history system.

For a full background check on a used vehicle, you would typically combine an MOT history check (which our tool provides free) with a paid HPI or similar vehicle provenance check that covers finance, stolen, and write-off status. Our tool is not a substitute for a full provenance check when purchasing a vehicle. See our comparison page on MOT checker versus HPI check for a detailed breakdown of what each type of check covers.

Vehicles With No MOT History: New Vehicles and Electric Cars

Vehicles that are fewer than three years old from the date of first use have not yet reached their mandatory first MOT date. If you search for a registration that belongs to a car registered within the last three years, the DVSA API will typically return either a 404 (no record found) or a response object with an empty motTests array alongside the vehicle-level metadata. Our tool handles both cases and displays an informative message confirming the vehicle's age and estimated first MOT due date rather than showing a confusing "no result" error.

Electric vehicles (EVs) are subject to the same MOT testing requirements as petrol and diesel cars once they pass the three-year threshold. The MOT test for electric vehicles was updated from 2023 to include high-voltage system safety checks, with testers required to inspect warning lights and the integrity of high-voltage cables. When an EV appears in the DVSA data, the fuel type field in the vehicle-level section of the JSON response will carry a value such as "ELECTRIC" or "ELECTRIC DIESEL" (for plug-in hybrids). Our result card displays this fuel type, and we include a note for EV owners explaining the additional safety checks introduced in the updated testing standards.

Some electric vehicles manufactured before May 2018 were previously exempt from MOT testing under the historic vehicle exemption, but subsequent regulatory changes brought most of these back into the testing regime. If an EV returns no result, it may genuinely be exempt under a specific category, but this is now uncommon for mainstream production electric cars. If you are unsure whether your EV requires an MOT, the DVSA's own vehicle enquiry tool on GOV.UK is the definitive reference.

API Rate Limits, IP Blocking, and Trade API Restrictions

The DVSA MOT History API applies rate limiting to prevent abuse and to ensure fair use across all registered API consumers. The precise rate limits are governed by the terms of the API agreement and can change over time, so we do not publish exact figures here. In broad terms, the API permits a reasonable volume of queries per day for legitimate informational services. Our serverless architecture means each query originates from our server infrastructure rather than individual user IP addresses, so users do not personally encounter rate-limit responses.

The DVSA does impose additional restrictions on high-volume "trade" users, meaning organisations using the API primarily to enrich their own commercial databases rather than to answer individual consumer queries. Trade-level usage requires a separate agreement with the DVSA and is subject to different terms. Our use of the API falls within the consumer information category: we make queries in response to individual user searches and do not perform bulk scraping, background batch processing, or systematic database building from the API data.

IP-level blocking can occur if the DVSA's systems detect query patterns that resemble automated scraping rather than human-driven searches. Our tool includes sensible protections against this: we do not allow queries to be triggered programmatically without a genuine user interaction, and we apply our own client-side rate limit to prevent rapid-fire repeated submissions from a single browser session. If our IP were ever to be blocked by the DVSA, our error handling layer would return a graceful "service temporarily unavailable" message rather than a raw API error to the user.

Comparison With the Official GOV.UK Vehicle Enquiry

The official GOV.UK vehicle enquiry service at gov.uk/check-mot-status provides MOT status information drawn from the same DVSA database that we query. So why use our tool instead of the government service? The two services are complementary rather than competing, and each has distinct characteristics that make one or the other more useful depending on your needs.

The key practical difference is that our tool surfaces the full history, advisories, and mileage data in a single consolidated view, whereas the GOV.UK service splits current status and historical detail across separate pages that require multiple navigations. For someone doing a quick pre-purchase check on a used car, having all the information on one page is significantly more convenient. For official regulatory purposes, the GOV.UK service is always the authoritative reference.

Mock and Test Data: How We Develop and Test the Integration

Building and maintaining a live integration with a government API requires a safe development environment that does not incur rate-limit usage against the production quota. The DVSA provides a sandbox environment for registered API consumers, which returns predefined mock responses for a set of test registration numbers. These mock registrations are documented in the DVSA developer portal and include examples of vehicles with a passing MOT, a failing MOT, multiple advisory items, mileage anomalies, and a no-history response.

Our development workflow uses these sandbox test registrations for all non-production work. When a developer runs the tool locally or in a staging environment, the configuration points to the DVSA sandbox endpoint rather than the live production API. This means no real vehicle data is processed during development and testing, and mock responses never make it into the production codebase. The switch from sandbox to production is governed by an environment variable that must be explicitly set to the production API URL and key, requiring a deliberate action rather than happening accidentally.

We also maintain a set of our own internal regression tests that replay the DVSA's mock responses and verify that our parsing, normalisation, and display logic handles each case correctly. If a DVSA API update changes the structure of the JSON response, our regression suite catches the breakage before it reaches users. These tests run automatically on every code deployment as part of our continuous integration pipeline.

Browser Compatibility, Mobile Optimisation, and Accessibility

Our tool is designed and tested to work correctly on all mainstream browsers in current and recent versions. This includes Chrome, Firefox, Safari, Edge, and Samsung Internet. We use standard HTML5 and CSS features with no proprietary browser extensions. JavaScript is required for the actual MOT lookup (since the API call is made via the Fetch API), but the page loads and renders correctly in browsers with JavaScript disabled, displaying a clear message that JavaScript is needed to perform a search.

The responsive layout adapts to screen sizes from 320px wide (small smartphones) up to 2560px (large desktop monitors). The registration number input, search button, and result card stack vertically on small screens and arrange into a wider layout on larger viewports. Touch targets are sized to a minimum of 44x44px in line with WCAG 2.1 criterion 2.5.5, making the tool comfortable to use on touchscreens without precise tap accuracy. Font sizes scale with the browser's base font size setting, meaning users who have increased their default font size for accessibility reasons will see the tool text scale accordingly.

We target WCAG 2.1 Level AA conformance throughout the site. Specific measures include: all images carry descriptive alt text; colour is not used as the sole means of conveying information (the pass/fail status is communicated by both colour and a text label); the result card is announced to screen readers via an ARIA live region when it becomes visible; focus order follows a logical sequence; and all interactive elements are reachable and operable by keyboard alone. The skip-to-content link at the top of the page allows keyboard and screen reader users to bypass the navigation and reach the search tool directly.

Open Source, API Licensing, and Our Independence

The DVSA MOT History API is made available under the Open Government Licence v3.0, which permits free use and republication of the data for both commercial and non-commercial purposes, provided the source is attributed and the licence is acknowledged. Our use of the API complies with these terms. The data you see in our results is Crown copyright and is attributed to the DVSA as required by the licence.

Our front-end codebase uses only open-source libraries, all of which are licensed under permissive licences (MIT or Apache 2.0). We do not use any proprietary third-party data enrichment services, paid data brokers, or licensed commercial datasets. What you see is purely the DVSA's own data, rendered through our own open-source front-end, with no third-party data layered on top.

We are an independent commercial website and are not affiliated with, endorsed by, or in any way a part of the DVSA, the DVLA, the Vehicle and Operator Services Agency, or any UK government department. The tool is provided as a free public service. We sustain the cost of running the service through display advertising and, where relevant, affiliate links to insurance or vehicle history products. These commercial relationships do not affect the MOT data we display: the DVSA data is what it is, and we cannot alter it even if we wished to.

The Complete Step-by-Step Lookup Process

To bring all of the above together into a clear sequence, here is the precise journey from your keypress to the result card on screen.

1. You type a registration number into the input field. Client-side JavaScript normalises the input to uppercase and strips non-alphanumeric characters as you type.
2. When you press "Check MOT", the JavaScript validates the normalised string against a set of UK registration mark patterns. If validation fails, an inline error message appears immediately and no network request is made.
3. If validation passes, the script sends an HTTP POST request over HTTPS to our serverless function endpoint, carrying the sanitised registration as a JSON body parameter.
4. The serverless function checks its in-memory OAuth token store. If the current bearer token is still valid, it proceeds. If the token has expired, it sends a client credentials grant request to the DVSA authorisation server and stores the new token.
5. The function sends a GET request to the DVSA MOT History API endpoint, passing the registration as a URL path segment and the bearer token as an Authorization header.
6. The DVSA API queries its database and returns a JSON response, either a vehicle record with a motTests array, a 404 for no record, or an error code for service unavailability.
7. The serverless function parses the JSON, extracts the fields we display, and returns a structured result object to the browser over HTTPS. The raw API response is discarded and never stored.
8. The browser JavaScript receives the result object, constructs the result card HTML, injects it into the DOM, and triggers an ARIA live region announcement for screen readers. The result card becomes visible.
9. The serverless function terminates. No record of the lookup remains on the server.

Data Accuracy Disclaimer and Known Edge Cases

While the DVSA database is the definitive record of MOT tests conducted in Great Britain, the system is not infallible. Test stations occasionally submit results with transcription errors, such as an incorrect mileage reading or a wrong test date. If such an error is submitted, it will appear in our display exactly as the DVSA holds it. Corrections to the DVSA database must be requested through the test station that conducted the original test. We have no ability to correct or dispute records in the DVSA system.

Vehicles that have been re-registered, for example following a change of keeper who opted for a personalised plate, will have their MOT history associated with their current registration. If the history appears shorter than expected (for example, only a few tests for a vehicle that looks older), it is possible the vehicle was previously registered under a different mark and the history from that mark may be accessible by querying the original registration separately, if you know it.

A very small number of test records in the DVSA database contain data anomalies inherited from the digitisation of older paper records. These typically manifest as unusually early test dates, mileage readings of zero, or missing test centre information. Where we detect an anomaly of this type (for example a mileage of zero that is clearly not a genuine reading), we apply a display qualifier rather than silently omitting the data. Transparency about data quality is more useful than hiding records that look anomalous.

Official Government Resources

The following official UK government sources provide authoritative information relevant to this topic:

• GOV.UK: Official MOT history checker
• DVSA — the data source behind MOT records

All MOT history data displayed by our tool originates from the DVSA and is made available under the Open Government Licence — the primary source documents are listed above.

Frequently Asked Questions

How does the OAuth 2.0 authentication work when I search for a plate?

When you press "Check MOT", our server first checks whether it holds a valid bearer token from the DVSA authorisation server. If a valid token exists, it uses that token immediately. If the token has expired, our server sends a client credentials grant request to the DVSA auth endpoint using our client ID and secret, receives a new token, and then proceeds with your query. This entire process takes a few milliseconds at most and is invisible to you. The token is stored only in server memory and is never shared with your browser or written to any persistent storage.

What does the DVSA API rate limit mean in practice for users?

The DVSA applies usage limits to all registered API consumers to prevent abuse. Because our queries originate from our server infrastructure rather than from individual users' IP addresses, individual users never hit rate limits directly. Our own server manages query volume within the terms of our API agreement. In the very unlikely event that our total query volume approached a DVSA limit, our system would queue requests rather than drop them. We have not encountered this situation in practice because the DVSA's limits are designed for legitimate consumer services of our scale.

Why does the mileage shown sometimes seem lower than I expect for an older car?

Mileage in the MOT history is recorded at each test date only. Between tests, there is no continuous tracking. If a car covers unusually low mileage in a given year, the recorded figure at the next test will reflect that. Additionally, odometers can roll over at 100,000 or 999,999 miles depending on the instrument type, which can cause an apparent mileage decrease in the data. Some older vehicles also had analogue odometers that testers could not read reliably, resulting in "unreadable" entries. None of these scenarios necessarily indicate odometer fraud, though a significant unexplained decrease in recorded mileage is a legitimate concern worth investigating further.

Can I use this tool to check a vehicle's MOT before buying it privately?

Yes, and this is one of the most common legitimate use cases. Checking the MOT history before buying a used car gives you the test date, pass/fail history, advisory items from recent tests, and mileage at each test point. This is genuinely useful information. However, an MOT history check alone is not a full vehicle background check. It does not tell you whether the vehicle has outstanding finance, has been written off, or has been reported stolen. For a used-car purchase, combining our free MOT check with a paid HPI or similar provenance check is standard due diligence.

Does searching for a plate on your site leave any trace or affect the vehicle's record?

No. Querying the DVSA MOT History API is a read-only operation. Looking up a vehicle's MOT history does not modify, flag, or annotate the record in any way. The DVSA database is not updated by lookups, only by test events submitted by authorised test stations. On our side, we do not store the registration number you searched, so there is no record of the lookup in our systems either. The search is entirely invisible to the vehicle owner, the DVSA, and anyone else.

What happens if the DVSA API is down or returns an error?

Our error handling layer catches all non-200 responses from the DVSA API and translates them into user-friendly messages. A 404 response results in the "no record found" flow described above. A 429 rate-limit response triggers a short retry with exponential backoff. A 5xx server-side error or a network timeout results in a "service temporarily unavailable" message with a suggestion to try again in a few minutes. In all cases, the raw API error code and message are suppressed from the user-facing display. We log 5xx errors internally (without the associated registration number) for monitoring purposes.

Is your tool accessible to users with disabilities?

We target WCAG 2.1 Level AA conformance. The site is fully navigable by keyboard, all images have descriptive alt text, the result card is announced to screen readers via an ARIA live region when search results appear, and colour is never the sole means of conveying status information (each status badge carries both a colour and a text label). The skip-to-main-content link at the top of the page allows keyboard and screen reader users to bypass navigation. If you encounter an accessibility barrier, please contact us and we will address it promptly.

How is our tool different from a direct call to the DVSA API?

The DVSA MOT History API requires an approved application and credentials that are not publicly available. Our tool handles the authentication, rate management, error handling, and data presentation on your behalf, with no account or technical knowledge required. We also combine MOT data with road tax data from the DVLA VES API into a single view, which requires separate credentials and logic. The result is a formatted, human-readable summary rather than raw JSON that would need to be interpreted manually.

Can developers access your API or source code?

Our front-end codebase uses open-source libraries and the source is viewable in the browser via developer tools. However, we do not currently offer a public API wrapper over our DVSA integration, nor do we publish our serverless function code, as it contains configuration that references our DVSA credentials environment. Developers wishing to build their own MOT checking tools should apply directly to the DVSA for API access through their official developer portal. We are happy to discuss technical questions via our contact page.