Check Share Code
Get API key

Privacy Policy

Last updated 2026-10-25.

Check Share Code is a service of Sharp Studios Ltd, registered in England and Wales, company number 15591412. In this policy "we" and "us" mean Sharp Studios Ltd.

This Service processes two distinct categories of personal data with very different handling: customer data (yours) and applicant data (the subject of a check). Treat them as separate flows.

1. Customer data

When you sign up we collect your email, hashed password (if you set one), billing metadata, and aggregate usage counts (no per-check PII). This data identifies your account and supports billing, fraud prevention, and product analytics.

We also keep a log of the requests your API keys make to our API for 30 days: the time, the endpoint and path (including an asynchronous check's ID), the response status, how long it took, which of our addresses it was sent to, and the first 16 characters of the key (the part your dashboard shows). It never holds what a request or response contained, so no applicant data. We use it to support you and run the service, and a request refused for a key that looks like one of yours is shown on your dashboard so you can fix it. Each of those requests is also a line in our server logs with the same details and nothing more, as are the server's other log lines, which hold no applicant data. We keep those logs with our hosting provider and, for 14 days, with PostHog (in the EU), to monitor and debug the service.

  • Lawful basis: contract performance and legitimate interests (security, accounting).
  • Retention: while your tenant is active and for 7 years after closure (HMRC requirement on billing records).
  • Recipients: Neon (DB), Stripe (payments), Fly.io (hosting), Resend (transactional email), PostHog (product analytics, error tracking and server logs, EU).

Access requests

Until 14 October 2026 driving licence checks were sold by request. If you asked for access on their page, we collected your work email, the checks you chose, the number of checks a month you told us, the page you were on, and where you first arrived from (the referring site and campaign tags). We use it only to open access for you and contact you about it.

  • Lawful basis: steps you asked us to take before a contract, and legitimate interests (knowing which checks to open first).
  • Retention: 12 months from the request. The database record is deleted automatically; the copies in our support inbox and the founder alert are deleted by hand in the same period.
  • Recipients: Neon (DB), Resend (an email to our support inbox), Telegram (an alert to the founder). Product analytics receive the page, the checks and the volume, never your email.

Advertising measurement

We advertise in ChatGPT. When you click one of those ads, OpenAI adds a click reference to the link. We keep it with the other tags from your first visit, in your browser's local storage and, if you sign up, on your account. When you first sign in to your new account, our server tells OpenAI that the click led to a registration, sending only that click reference, a one-way code for the registration (so it is never counted twice) and the time. We never send OpenAI your email, name, IP address or device details, and our pages load no OpenAI script.

  • Lawful basis: legitimate interests (knowing which ads bring customers).
  • Retention: the click reference stays in your browser until you clear site data, and on your account with its other signup details.
  • Recipients: OpenAI, which runs ChatGPT ads and may process the report in the United States. Nothing is sent if you did not arrive from a ChatGPT ad.

2. Applicant data

When you call a check endpoint (POST /v1/check/right-to-work, POST /v1/check/right-to-rent, POST /v1/check/immigration-status or their asynchronous versions), gov.uk's form for that check is driven on your behalf with the share code, applicant date of birth, and your company name; for immigration status also the job title of the person checking and the reason for the check. The gov.uk response contains the applicant's name, nationality, photo, permission type or immigration status, conditions, and audit reference.

We keep this data for up to 7 days, only to investigate problems. For each live share code check we store the inputs (share code, date of birth, company name) and the gov.uk pages the check went through, which include the result: the applicant's name, photo, permission and conditions, and for immigration status the job title and reason you gave. We also keep what a live request sent when we refused it before it reached gov.uk (a date of birth in the wrong format, for example), so we can show you what your system sent. And we keep the answer we returned to you, without its photo and PDF. We use them only to investigate a failed or disputed check. Nothing in the product reads them, and they are deleted automatically after 7 days.

Asynchronous checks. When you use the /async endpoints, we also keep the result of the check, including the PDF, so we can deliver it to you and you can fetch it again. It is encrypted with a key held outside our database, and deleted automatically 7 days after the check finishes.

Driving licence checks

When you call POST /v1/check/driving-licence (or its asynchronous version), DVLA's "Check a driving licence" service (viewdrivingrecord.service.gov.uk) is driven on your behalf with the last 8 characters of the driver's licence number and the check code they gave you. DVLA's response contains the driver's name and title, driving status, licence issue number and validity dates, the vehicle categories they may drive with their dates and restriction codes, the number of offences and penalty points, whether there are penalties or disqualifications, and DVLA's PDF of the record. It does not contain their date of birth, address or photo.

Offences and penalty points are criminal offence data under Article 10 UK GDPR. As the Controller you need a lawful basis and a condition in Schedule 1 to the Data Protection Act 2018 before you check a licence, and you may only check one with a check code the driver created and gave you for that purpose, as DVLA's terms require. DVLA's PDF is a record of the check, not proof of driving entitlement.

We keep a licence check's inputs for up to 7 days, only to investigate problems. For each live driving licence check we store the licence number exactly as you sent it (in full or its last 8 characters) and the check code as you sent it, and what a live request sent when we refused it before it reached DVLA (a malformed licence number, or a check code already used, for example). Nothing in the product reads them, and they are deleted automatically after 7 days. Because a check code works once, we also keep a keyed hash of the code and the licence number's last 8 characters, which cannot be turned back into either, for 21 days (the life of a check code), so the same code is never sent to DVLA twice. We keep the pages DVLA showed during every check, including the record it returned (which shows the end of the licence number and the check code), and the answer we returned to you, without its PDF, for up to 7 days, to investigate failed or disputed checks, recover a record for you, and keep our reading of DVLA's service correct. When a check fails, other than DVLA refusing the code in a way our rules recognise, or needs the AI model below because DVLA's form or page has changed, we also keep a recording of it (screenshots, page snapshots and the network requests and responses of each step, including the form as sent and DVLA's PDF, showing the licence number and check code as entered) for up to 7 days. A page our own rules cannot read may be read by an AI model through OpenRouter (see International transfers), and what the model was sent and answered is kept with it. An asynchronous check's result is kept encrypted for 7 days, as above. A record of each check's timings and outcome, with no values from the check, is kept for 30 days to run the service.

Sandbox checks store no applicant data. Apart from asynchronous results, we do not keep the PDF, and we do not log share codes, names, dates of birth, photos, or PDFs. The audit log retains only timestamp, outcome code, and request duration, with no identifying values, and the request log (section 1) holds no applicant data either.

  • You are the Controller for applicant data; you must have a lawful basis (typically employment or letting compliance, or checking eligibility for a service) to process it, and for driving licence records a Schedule 1 condition as well.
  • We are the Processor acting only on your documented instructions.
  • Retention: up to 7 days after the check, then deleted automatically (the keyed hash of a driving licence check code, 21 days).

3. Cookies

We use essential cookies only: the session cookie that keeps you signed in. We do not use analytics or advertising cookies. We report signups from ChatGPT ads to OpenAI without a cookie or script, as described under Advertising measurement above. See our Cookies Notice for the full list.

4. International transfers

Customer and applicant data is processed within the UK and EEA (our database with Neon and our servers with Fly.io, both in London), with one exception. When our own rules cannot read a gov.uk or DVLA page during a check, its text may be sent to OpenRouter, Inc. (United States) to be read by an AI model, only through providers that keep no data.

5. Your rights

You have rights of access, rectification, erasure, restriction, portability, and objection under UK GDPR. Applicant data is deleted automatically within 7 days of a check (the keyed hash of a driving licence check code within 21 days). Until then, a request about a checked applicant goes to the organisation that ran the check, as the Controller, and we will help them with it. For customer data, write to matthew@checksharecode.co.uk or delete your account from the dashboard.

6. Security

API keys are stored only as SHA-256 hashes; plaintext is shown once on creation. All traffic uses TLS. Card data is handled entirely by Stripe and never touches our servers.

7. Complaints

If you are not satisfied with our handling of your data you may complain to the UK Information Commissioner's Office at ico.org.uk.