Sub-processors

Last updated: 3 October 2026 — wa.me (WhatsApp share links) added: the client portal builds and opens one when a customer taps Send on WhatsApp on a supplier-introduction link, so the invitation text and their IP address reach a Meta-operated host. Web only — portal.html is stripped from the installed app, so the App Store privacy answers are unaffected. It was missing, and this page's claim below is an absolute one, so it was untrue until this row existed. 26 August 2026 — Stripe row rewritten: billing went live on the afternoon of 25 August 2026, and Stripe's DPA was confirmed to be in force automatically as part of the Stripe Services Agreement. 19 August 2026 — Overpass API added (nearest-A&E/defib EAP lookup). 15 August 2026 — OpenStreetMap tiles added; see note 4.

This is the complete list of third parties that RouteRound sends data to. It was compiled by reading the source code — every outbound network call in src/ and netlify/functions/, every external link the app builds and opens, and the Content Security Policy in netlify.toml — rather than from memory. If a service is not on this list, RouteRound does not send data to it. Note 3 below is the one qualification to that sentence.

Four things to note before the table:

  1. Where data is processed. The live Supabase project runs in AWS eu-west-3 (Paris, France). Data at rest is therefore in the EU, not the UK — RouteRound is not UK-only hosted and does not claim to be. Transfers from the UK to the EEA are covered by the UK's adequacy regulations, so the mechanism for that leg is UK adequacy: no International Data Transfer Agreement, no standard contractual clauses and no transfer risk assessment are needed for it. Two related questions are not answered by that and are marked separately below. First, whether our suppliers' own support and engineering staff reach the data from outside the EEA. This is governed by each supplier's own DPA rather than by the database region, and the DPAs of Supabase, Netlify and Resend have now been read for it. For all three the answer is yes. Supabase's contracting entity is Supabase Pte. Ltd in Singapore rather than the US company, but its DPA reserves the right to process anywhere Supabase or its sub-processors keep facilities, promises only that data directed to a region is stored and primarily processed there, and describes staff placed around the world working a follow-the-sun model — and its published sub-processor list names Supabase, Inc., a US company, as the one providing support services, with no location given for it or for anyone else on that list (supabase.com/legal/dpa; supabase.com/legal/customer-resources/subprocessor-list). Netlify's DPA opens its transfer section by anticipating that Netlify and its sub-processors may process outside the EEA, Switzerland and the UK (netlify.com/pdf/netlify-dpa.pdf, clause 14.1). Resend's DPA says its primary processing operations are in the United States, and every entity on its sub-processor list is marked USA (resend.com/legal/dpa; resend.com/legal/subprocessors). None of the three publishes any commitment to keep support inside the EEA, so do not tell a buyer that support is EEA-only. What each relies on to make those transfers lawful is in the register at the foot of this page. Second, Netlify's function and CDN edge regions, which are a different thing from the database region — a function can execute outside the EU even though the database sits in Paris. That one is answered in the Netlify row below: they execute in Ohio.
  2. Some of these are contacted by your browser, not by our servers. Where that is the case the data never passes through our infrastructure at all. Two of them — the google.com/maps navigation links and the wa.me WhatsApp share links in the client portal — are reached only at the moment somebody taps a link, and nothing is sent until they do. All of it is still listed, because it is still a disclosure of personal data to a third party and you are entitled to know about it.
  3. The app also renders two kinds of ordinary outbound link that are not sub-processors. Both are on the Tree Preservation Order screens: a fixed link to nationalarchives.gov.uk (the Open Government Licence attribution required by the data licence), and — after a check returns a result — a link to the responsible council's own website, whose address comes from planning.data.gov.uk and can therefore be any host. No personal data travels in either URL and both carry rel="noreferrer", so the page you came from is not disclosed; but opening one does disclose your IP address to that site, the same as visiting it directly would. They are named here so that "if it is not on this list we do not contact it" is not read more absolutely than it is true. They are not in the tables because nothing is sent to them and there is no processor relationship to record.
  4. This page missed one until 15 August 2026, and how it did is worth writing down. OpenStreetMap has been receiving map-tile requests from your browser on the tree-preservation-order screen for as long as that screen has existed, and it was not on this list. The compilation method described above should have caught it: tile.openstreetmap.org is sitting in the Content Security Policy in netlify.toml, in plain sight, on the img-src line. It was missed because the checks went looking for scripts and fetches, and a map tile is neither — it is an <img> tag, so it never appears in a fetch( grep and never runs a line of third-party code. A page whose whole value is that it is exhaustive has to say when it was not. If you audit this list yourself, the lesson is that img-src, font-src and media-src disclose an IP address just as surely as connect-src does.

Always used

Sub-processor Service What actually reaches them Why Contacted by Where processed
Supabase Database, authentication (including the authentication emails it sends) and file storage Everything in a cloud account. Sign-in email addresses and password hashes. The complete JSON backup of an account or organisation: sites (addresses, postcodes, coordinates, access and gate-code notes), customer contact names, phone numbers and emails, all jobs including GPS check-in and check-out fixes, job notes, risk assessments, waste transfer notes, equipment and vehicle checks, custom form answers, the staff register with names, phones, emails and qualifications, quotes, invoices, stock records and company settings. Not one snapshot but many: every push writes that backup twice — over the live row, and as a new row in an append-only history table, so Supabase can be holding tens of complete historical copies of an account, each restorable and each containing everything listed above. Read the retention on that history carefully, because it is not a 30-day ceiling. Trimming is done by a database trigger that fires only when that same account or organisation pushes a new snapshot; it then keeps the 20 most recent plus the newest of each day for the previous 30 days. Nothing is scheduled and nothing sweeps in the background, so an account that stops pushing — a lapsed subscriber, a dormant organisation, or an account frozen the moment an erasure request arrives — keeps whatever survived its last push, indefinitely, until the account or organisation is deleted. The live row and every history row also carry the first 120 characters of the browser's user-agent string, recorded so you can tell which device made a backup. Separately, in a private file bucket: job photographs, drawn signature images and photographs of qualification certificates. Two honest limits on how long content stays there, and the first is not confined to the bucket. The sync merge has no delete markers for anything except sites. A site is soft-deleted with a timestamp, so removing a site propagates; everything else — jobs, the staff register, the customer and client list, quotes, invoices, custom form answers, stock records and compliance requirements — is destroyed outright on the device with nothing left behind to record that it was deleted. The next merge pull, whether from another device or from the cloud copy itself, silently re-adds the row, and the next push writes it back over the live backup and into a fresh history snapshot. So deleting one employee, or one customer, is not a reliable erasure. Nothing short of deleting the whole account or organisation dependably removes an individual person's record from Supabase. The second limit is the bucket itself: the app only ever uploads to, lists and downloads from it — it never deletes an individual file — so a photograph removed on a device stays in Supabase Storage and is downloaded again on the next pull. The bucket is emptied only when the whole account or organisation is deleted. Also the client-portal tables: customer email addresses and names, sign-in timestamps, the published schedule, completed-job records and portal requests. Sharing a schedule with a customer's email address also creates a real Supabase Auth user for that customer, which is how the portal sign-in link works; deleting a contractor's own account removes the portal rows it created (including the customer record, where no other contractor still shares with them) but does not delete those customers' Auth users, which remain in the project. Supabase also sends email on our behalf — the portal sign-in link, the contractor magic link, the sign-up confirmation and password resets are all sent by Supabase Auth It is the database, the sign-in system and the file store behind cloud accounts and the portal Both — the browser reads and writes directly under row-level security; our server functions write with a privileged key AWS eu-west-3 (Paris, France). Data at rest is in the EU, not the UK; the UK→EEA transfer relies on UK adequacy. Supplier support access from outside the EEA is a separate question — see note 1
Netlify Application hosting and serverless functions All HTTP traffic to the app and portal, therefore IP addresses, request metadata and anything in a request body. The cloud-sync, org, tpo, intro, delete-account, billing and stripe-webhook functions all run here, so the schedule payloads, email content, site coordinates, supplier-introduction tokens, account-deletion requests and Stripe billing traffic pass through Netlify's compute Hosting, and running the seven server-side functions Everything Netlify, Inc., 512 2nd Street, Suite 200, San Francisco, CA 94107 — the entity named as data importer in its own DPA, and the one a self-serve account contracts with. On the evidence in this repo the functions run in the United States: netlify.toml sets no function region, and Netlify's documented default is cmh, US East (Ohio); overriding it needs a Pro or Enterprise plan, so it can only have been changed deliberately. This is therefore a separate question from the Supabase region above and is not answered by it — the database sits in Paris while the functions that read and write it execute in Ohio. Transfers rely on the UK Extension to the EU-US Data Privacy Framework, which Netlify's DPA states it has certified to, falling back to the EU Standard Contractual Clauses as amended by the UK Addendum if that lapses or does not apply (clauses 14.2 to 14.4). Confirmed by measurement on 25 August 2026: the functions execute in the United States. netlify.toml now does set region = "lhr" (London) on every function, and it makes no difference on this deployment path — the site's own functions_region still reads us-east-2, and a UK request to a function takes about 235 ms against about 80 ms for a static asset from the same origin, which is a transatlantic round trip and nothing else. The account is on Netlify's Pro plan, so the region can be changed, but only through the site-level setting in Netlify's UI. Until that is done and re-measured, this row describes Ohio, because that is where the code actually runs.
postcodes.io UK postcode lookup (free, no API key) The postcode or address text being looked up. Note: where a full postcode cannot be extracted from what you typed, the raw search text is sent, which may be a full street address. And it is not always one address at a time. After a spreadsheet import the app geocodes every newly created site that has no coordinates, automatically, with no prompt — and a button in Settings does the same across the whole existing site book. Each of those sites sends its stored postcode, or, where it has none, its stored full street address. So importing a customer list discloses that entire list of site locations to postcodes.io in one sweep. This is the bulk geocoding disclosure that actually happens today; the comparable Google route-optimisation one described below is not enabled Turning a postcode into coordinates without a Google Maps key — used for the depot and for locating sites Your browser Maintained by Ideal Postcodes, the trading name of IDDQD Limited, Floor 3, 207 Regent Street, London W1B 3HH. Where the free endpoint actually runs is not published, and there is no terms page, privacy notice or DPA covering it that we could find, so record the location as not stated rather than as UK
Open-Meteo Weather forecast (free, no API key) The latitude and longitude of your depot — the yard or base address you entered in Settings — at the precision it is stored. That is the only coordinate ever sent, and it is the same fixed point on every request: no customer site coordinate is sent, and nothing about the part of the map you happen to be looking at is sent. No name, address text or account identifier goes with it The weather overlay on the planning board, so you can avoid booking outdoor work in heavy rain Your browser Operated by OpenMeteo GmbH, Hintere Schilligmatte 6, 6463 Bürglen (UR), Switzerland. Its own feature page says its servers operate in Europe and North America, so a request can be answered from outside Europe and we neither choose nor see which server takes it. Its terms say free-API request logs, including IP addresses, are kept for 90 days
planning.data.gov.uk National Planning Data platform (UK Government, free, no API key) The latitude and longitude of the site being checked, at the precision they are stored. No name, email, address text or account identifier is sent with it — but a pinpoint coordinate of a customer's site is frequently a private home, so treat this as location data about your customer rather than as anonymous Checking whether a site sits in a Tree Preservation Order zone or a conservation area before tree work Our server — the browser never contacts it directly, so it is our server's IP address that reaches them, not yours UK Government service
Google (google.com/maps navigation links) Ordinary map and directions links opened from the app. No API key, no Google account of ours and no Google script are involved — this is separate from the Google Maps Platform row below, and unlike that row it is live today Only when you tap Navigate on a day, or an address link on a job. The link is a google.com/maps URL that carries the location in the query string: for a single job, the site's coordinates — or, where the site has none, its postcode or its name; for a day's round, the depot and every stop on that round, as coordinates to six decimal places, in one URL. Opening it gives Google those locations, your IP address and whatever else your browser sends to any website. Printed day sheets carry the same links, which reach Google only if somebody opens them One-tap turn-by-turn driving directions on a phone, without us embedding a map Your browser, and only when you tap the link Not a processing location, because it is not our processing. The app builds a google.com/maps URL and the person's own browser opens it: no API key, no Google account of ours, no Google script, no contract. Under Google's own privacy policy the controller for a UK user of Google services is Google LLC, 1600 Amphitheatre Parkway, Mountain View, California — the same as if you had typed the address into Google Maps yourself. So record it on the register as a disclosure to a third-party controller, not as a processor appointment. One detail worth knowing: the per-job links, and legs 2 onwards of a long round, carry rel="noreferrer", but the first leg of a day's round is opened with window.open(..., 'noopener'), which does not suppress the referrer — so on that one link Google is also told the visit came from routeround.co.uk. Our Referrer-Policy limits that to the bare origin, never the page path
OpenStreetMap Foundation Map tiles on the tree-preservation-order screen. No API key, no account of ours and no third-party script — the tiles are plain <img> requests your browser makes to tile.openstreetmap.org Only on the Tree Preservation Order screen, and only after you press Show map on a completed check — the tiles are not requested until then. Each request discloses your IP address, your browser's user-agent string, routeround.co.uk as the referring site, and the tile's own coordinates, which are what give the disclosure its weight: a fixed 320×240 view at zoom 14–19 is a handful of tiles, and together they identify the patch of ground you are standing on or checking, to within a few tens of metres. On the "check this spot" route that is the operative's own live position, so read this as location data about your employee as well as about the site. No name, address text, account identifier or coordinate from anywhere else in the app is sent, and no tiles are fetched for any other screen Showing where a tree-preservation-order or conservation-area boundary actually falls relative to the spot you checked, instead of only telling you that it does Your browser, and only after you press Show map A disclosure to a separate controller, not a processor appointment — and the OSMF says so itself. Its published FAQ answers the question directly: "No. There is no Data Controller - Data Processor relationship between you and the OSMF and using our services does not create such a relationship… The OSMF operates as an independent Data Controller and is not processing personal data on your behalf." So there is no DPA to sign and no point asking; record it on the register the same way as the google.com/maps links above. The entity is the OpenStreetMap Foundation, a company limited by guarantee registered in England and Wales, number 05912761, St John's Innovation Centre, Cowley Road, Cambridge CB4 0WS — a UK controller, which is the one genuinely comfortable fact in this row. Everything about where is less comfortable. Tiles are served over Fastly's global CDN, and OSMF's privacy policy states that which cache server answers is "determined by the operation of the content distribution network at the time of the request". Note the carve-out carefully: OSMF commits that "Personal data other than any associated with a tile request… is stored in the United Kingdom and the Netherlands" — tile-request data is expressly outside that commitment, and OSMF publishes no location commitment, no retention period and no transfer mechanism for it. Its own suggested wording for sites like ours is that the browser connects to servers "located in the United Kingdom and in other countries", and that is as precise as it can honestly be made. Because OSMF is an independent controller, its onward transfers are its compliance problem rather than ours; ours is to tell you this is happening, which is what this row is for
Meta (wa.me WhatsApp share links) Ordinary WhatsApp share links opened from the client portal. No API key, no WhatsApp Business account of ours, no Meta script and no Meta code of any kind runs in the app — this is the same shape as the google.com/maps row above, and it is live today Only when a customer, having created a supplier-introduction link in the portal, taps Send on WhatsApp. The link is a https://wa.me/?text=… URL carrying the whole invitation message in its query string: the fixed invitation wording, the sender's own display label (the "from" name they typed, in practice their name and the organisation they work for) and the one-time introduction link including its token. Opening it gives the host that text, their IP address and whatever else their browser sends to any website. rel="noreferrer" is set, so the page they came from is not disclosed. Nothing about the contractor's schedule, sites, staff or customers is in the URL, and nothing is sent unless the control is tapped — the three sending options beside it are "Copy link", "Copy message" and a mailto: link, and neither of those contacts any third party at all (a mailto: opens the person's own mail client). Web only. portal.html is stripped from the installed native bundle (scripts/strip-native-web-entries.mjs), so this link does not exist in the iOS or Android app and the App Store privacy answers are unaffected So a customer can send the invitation from their own WhatsApp, in their own words. RouteRound never emails the firm being invited and has no address for it — the portal says so on the screen — so the person's own mail client or WhatsApp is the entire delivery mechanism The customer's own browser, and only when they tap the link Not a processing location, because it is not our processing. The portal builds a wa.me URL and the person's own browser opens it: no API key, no account of ours, no third-party script, no contract. So record it on the register as a disclosure to a third-party controller, not a processor appointment — the same standing as the google.com/maps links and the OpenStreetMap tiles above. wa.me is operated by Meta as part of WhatsApp. Which Meta entity is the controller depends on the recipient's own WhatsApp account and is not something this repository can establish, so it is recorded as not established here rather than guessed — the honest answer differs from the Google row, where Google's own privacy policy names a single controller for a UK user of its services. There is no DPA to sign and no point asking; what is ours to do is tell you the disclosure happens, which is what this row is for
Overpass API (OpenStreetMap data) Nearest-A&E-and-defibrillator lookup on the Emergency Action Plan form. No API key, no account of ours, no third-party script — the browser POSTs a query to overpass-api.de Only on the EAP form, and only when someone taps Find nearest A&E & defib — nothing is sent until then. What reaches it is the site's coordinates (and nothing else: no name, address text, account identifier or any other coordinate). It returns nearby hospitals and mapped defibrillators for the crew to confirm. A pinpoint coordinate of a site is frequently a private property, so treat this as location data about your customer; where the site coordinates are the crew's own working location it is location data about your employee too Suggesting the nearest A&E and defibrillator to save re-typing, always as a suggestion the user checks — never as authority Your browser, and only when the button is tapped A disclosure to a third-party controller, not a processor appointment — the same standing as the OpenStreetMap tile row above. overpass-api.de is a community-run public endpoint serving OpenStreetMap data; there is no contract, no API key and no DPA to sign. It publishes no location commitment, no retention period and no transfer mechanism for query data, so record the location as not stated. The lawful basis and the privacy information are yours as controller; ours is to tell you the disclosure happens, which is what this row is for

Two things about the OpenStreetMap row that are not data protection points but belong beside it.

We are inside their usage policy, and it was built that way on purpose. The OSMF Tile Usage Policy asks for visible licence attribution, a real HTTP referer, HTTPS, sane caching and no bulk prefetching. The map carries © OpenStreetMap contributors linking to their copyright page; our Referrer-Policy of strict-origin-when-cross-origin sends the origin rather than stripping it, which is what they ask for and what a restrictive policy would have broken; tiles load only on demand behind a Show map press, at one fixed size and one zoom at a time, with no prefetch and no offline caching. The comment in TpoMap.tsx shows the developer read the policy before writing the code.

But the policy is explicit that this is not a service to build a business on. In its own words: "Our tile servers are not [free for everyone to use]: they are funded by donations and sponsorship"; "Commercial services, or those that seek donations, should be especially aware that access may be withdrawn at any point"; "Availability is best-effort: there is no SLA or guarantee"; and access "may be blocked without prior notice". That is a business-continuity risk rather than a compliance one, and it is realised without warning, so there is no window in which to migrate. If the tree-preservation-order map becomes something customers rely on, the honest answers are a paid tile provider or self-hosting — which is exactly where the policy's own "Alternatives" section points. The decision, recorded on 25 August 2026: we stay on the community tile service for now, and we accept the risk knowingly. The reasoning is that this map is a secondary aid on one screen of one trade's workflow, it loads only behind a Show map press, and the check it illustrates — whether a tree preservation order or conservation area applies — still returns its answer in full when no tile ever loads. Nobody is prevented from doing their job if the tiles stop.

What would change it. We move to a paid tile provider or self-host if any of these becomes true: the map stops being optional to the workflow; usage grows to where our request volume is no longer plainly incidental; or OSMF contacts us about it. Because the policy allows access to be withdrawn without notice, the migration path is chosen in advance rather than researched under pressure — a paid provider, as the policy's own "Alternatives" section suggests.

Used only when configured

These are switched on by setting an environment variable. If the variable is not set, the code makes no call to that provider at all — the feature simply degrades. Read each "currently in use?" cell for what does and does not stop: switching Resend off, for instance, does not stop Supabase Auth sending its own emails.

Sub-processor Service What actually reaches them Why Contacted by Currently in use?
Resend Transactional email Recipient email addresses — up to five per report, typed in by the contractor, so they can be any address at all. Then: schedule-change notices naming sites and dates, each line also carrying the contractor's free-text note to that customer about that visit where one is set — typically access, key or gate instructions, or the reason nobody was let in; that note is not written to the customer's portal record, so this email is the only place it goes, and it reaches Resend whenever it has been filled in. Also: team invitation emails; and completion reports, which carry considerably more than their name suggests, in two places. The attachment is completion-report.pdf, a page-image render of the entire Proof-of-Service sheet exactly as it appears on screen. That means the site's postcode, address and what3words; the customer's contact name and phone number; GPS check-in coordinates to five decimal places; free-text job notes; waste-transfer counterparty names, addresses and permit numbers; vehicle registration and odometer reading; the job photographs; photographs of staff qualification certificates; and the drawn signature images — client acceptance, the risk-assessment assessor, the waste-transfer transferor and transferee, and the operator who signed the equipment or vehicle check. Before-and-after photographs are attached instead of the PDF, and only when PDF generation fails. The email body is sent every time, whether or not the PDF succeeded, and it names the crew who were on each job and lists each crew member's qualifications with expiry dates and an EXPIRED marker where one has lapsed. In the same block, a line above the names gives the arrival and departure clock times and the minutes spent on site — so, read together, an attendance record showing which identified employees were at that address between which times. Alongside those: the site postcode, the EWC waste codes, the free-text "Work done" note, the free-text skip reason where a job was not done, and, where paperwork was overridden, a "Completed without" line naming the documents the job was signed off without plus the free-text reason given. So employee personal data — including working-time data — does leave to the mail provider, and onward to whichever addresses the contractor typed Notifying customers when a schedule changes, emailing completion reports, inviting colleagues Our server only Only when RESEND_API_KEY and RESEND_FROM are set. Without them Resend is never called and the app carries on — schedule notices, completion reports and team invitations are simply not emailed. That is not the same as no email at all: Supabase Auth still sends the client-portal sign-in link (the portal cannot be entered without it), the contractor magic link, the sign-up confirmation and password resets. Those never touch Resend, and they are sent whether or not these variables are set. Confirmed on 25 August 2026: RESEND_API_KEY and RESEND_FROM are both set on the live Netlify site, so this integration is active and email is really being sent through Resend.
Stripe Payment processing and subscription billing for the Pro plan. Added 2026-07-31 Not only people who pay — everyone who taps a billing button. The billing function creates the Stripe customer, carrying the account's sign-in email address and its Supabase user id (a UUID) as metadata, as soon as it has verified the session — before it looks at what the request was asking for, and before anybody is redirected to Stripe. So a signed-in cloud user who taps Subscribe once and then abandons checkout without entering a card has still disclosed their email address and account identifier to Stripe, permanently. The same happens on a Manage billing (portal) request, and on a malformed request naming an action we do not recognise. Read the population as every signed-in cloud user who has ever tapped a billing button, not "subscribers". Until the keys were set on the afternoon of 25 August 2026 none of this happened at all — the function answered 503 before reaching this point, so the population was empty. That is no longer the case, and the next person to tap Subscribe joins it. The user id is also stamped on the subscription itself, so the webhook can tell whose payment an event belongs to — a pseudonymous identifier tying the Stripe record to the RouteRound account. Beyond that, whatever billing address and card details are entered directly into Stripe's hosted checkout and customer portal. Card numbers never reach RouteRound: what we store is a Stripe customer id, a subscription id, the price id, the status, the renewal date and whether the subscription is set to cancel at the end of the period. Nothing about a subscriber's clients or staff is ever sent to Stripe. Deleting a RouteRound account does not touch Stripe: the deletion endpoint makes no Stripe call whatsoever, so the customer object — email address, and any billing address collected at checkout — and its invoices survive and must be dealt with by hand in the Stripe dashboard Taking payment for the Pro subscription, and letting a subscriber change card, download invoices and cancel Both — our server creates the customer, the checkout session and the portal session; your browser is then sent to Stripe's own hosted pages by a top-level redirect. No Stripe script runs inside the app YES — in use since the afternoon of 25 August 2026. STRIPE_SECRET_KEY, STRIPE_PRICE_ID and STRIPE_WEBHOOK_SECRET are all set on the live site, so the 503 that used to stop every request before it reached Stripe is gone. Every signed-in cloud user on the web sees the Pro pitch and an enabled Subscribe button, and tapping it now discloses their email address and account id to Stripe for real instead of failing first. Stripe's own services agreement settles the entity question: for an account whose country is the United Kingdom the contracting entity is Stripe Payments Europe, Limited, with Stripe Payments UK Ltd joined as an additional party only where the Stripe Financial Services Terms or other service terms say so. Stripe Technology Europe Ltd does not appear for the UK at all. 🔴 STRIPE WENT LIVE ON THE AFTERNOON OF 25 AUGUST 2026, AND THIS ROW IS NOT YET COMPLETE. Earlier the same day none of STRIPE_SECRET_KEY, STRIPE_PRICE_ID or STRIPE_WEBHOOK_SECRET was set, and this row said so. All three are now set; a live price exists (price_1U8NBjCGYD3TDhxa5uGDDsl8, £29.00/month, tax behaviour exclusive); the billing function now answers 401 rather than 503, and the webhook answers 400 on an unsigned request rather than 503. Billing can therefore charge a real card today, and the first person to press Subscribe will disclose their email address and account id to Stripe. Article 28 is satisfied, and the earlier note here saying otherwise was wrong. Stripe's DPA (version dated 18 November 2025) states that it "is subject to and forms part of the Agreement" — the Stripe Services Agreement accepted when the account was opened — and its clause 1 provides that an account outside the Americas enters that DPA with Stripe Payments Europe, Limited. There is no separate acceptance step for the standard DPA, so it has been in force since the account existed. Checked against stripe.com/legal/dpa on 26 August 2026. Stripe is also merchant of record for the subscription under Managed Payments: it adds UK VAT at checkout and accounts for it under its own VAT registration, and it issues the VAT invoice — see clause 6.1 of the terms and section 21.
Google (Google Maps Platform) Maps display, geocoding and route optimisation Addresses and postcodes submitted for geocoding; coordinates submitted for reverse geocoding; a whole day's round in a single route-optimisation request — the depot plus every stop's coordinates, which is a materially larger disclosure than one address lookup; and map tile requests, which carry IP address and the area being viewed. Google's JavaScript runs in your browser Rendering the map, converting addresses to coordinates, and ordering a day's stops by real road distance Your browser NOT ENABLED. Verified 2026-07-31 against the live production bundle at routeround.co.uk: no Google Maps API key is present, so the map, Google geocoding and Google route optimisation never run and nothing is sent to the Google Maps Platform API. postcodes.io is used instead. Read that narrowly: it does not mean nothing reaches Google. The google.com/maps navigation links in the Always used table are live today and do carry site coordinates and postcodes. The Maps Platform code path exists and would activate if VITE_GOOGLE_MAPS_KEY were ever set — re-verify this row, including the route-optimisation call, if you add one.
what3words Three-word address conversion Coordinates, or a three-word address, plus the API key in a request header Converting between coordinates and three-word addresses for hard-to-find site entrances Your browser NOT ENABLED. Verified 2026-07-31 against the live production bundle: no what3words API key is present, so nothing is sent to what3words. Re-verify if you add a key.

Stripe sits differently from the rest of this table: for the payment data it collects it is a controller in its own right, not merely our processor. That does not take it off this list — the email address and account identifier of anyone who has tapped a billing button still leave our systems and reach Stripe — but it does mean the arrangement with Stripe is not a plain processor appointment, and the DPA row below should be filled in with that in mind.

Not used

Stated explicitly because buyers ask:

What each one needs from you before launch

For every sub-processor in the two tables above:

  1. Accept their Data Processing Addendum and record the date. Most publish one you can accept online or by countersignature.
  2. Record the country of processing and the transfer mechanism you rely on (UK adequacy, the UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses).
  3. Carry out a transfer risk assessment where the mechanism requires one. Adequacy does not require one, so the UK→EU leg into the Supabase project in Paris does not need one. Whether a supplier's own staff reach the data from outside the EEA is a question about each supplier's DPA rather than about the database region; that has now been checked and the answer is yes for Supabase, Netlify and Resend alike, so the mechanisms recorded below are doing real work. See note 1.
  4. Note the review date. Once a year is a reasonable cycle for a business this size.
Sub-processor DPA accepted (date) Country of processing Transfer mechanism Reviewed
Supabase France — AWS eu-west-3 (Paris) for the stored data; support from wherever its people are, which is not stated UK adequacy (UK→EEA) for the stored data; UK Addendum to the EU SCCs for the rest — supabase.com/legal/dpa, Schedule 2
Netlify US — functions execute in cmh (Ohio), measured 25 August 2026. netlify.toml does set region = "lhr" on every function, but it is not applied on the CLI deploy path; the governing site-level setting is still US UK Extension to the EU-US DPF, falling back to the EU SCCs as amended by the UK Addendum — netlify.com/pdf/netlify-dpa.pdf, cl. 14
Resend US — its DPA says primary processing is in the United States, and every entity on its sub-processor list is marked USA UK Addendum to the EU SCCs, and the UK Extension to the EU-US DPF — resend.com/legal/dpa
Stripe Ireland (Stripe Payments Europe, Limited is the UK contracting entity); its DPA records transfers to Stripe, LLC in the US Data Privacy Framework self-certification, otherwise the EU SCCs as amended by the ICO's UK Addendum — stripe.com/legal/dpa
Google — Maps Platform (not enabled) n/a — no key configured n/a while no key is set n/a
Google — google.com/maps links (live) n/a — no key, no account, no processor appointment Google LLC (US) is the controller for a UK user under Google's own privacy policy n/a — a disclosure to a third-party controller, not a transfer we make
what3words n/a — no key configured n/a while no key is set n/a
postcodes.io Not stated — maintained by IDDQD Limited (London); where the free endpoint runs is not published No contract in place; keyless public API — see the paragraph below
Open-Meteo Switzerland (OpenMeteo GmbH); its own site says servers operate in Europe and North America No contract in place; keyless public API — see the paragraph below
planning.data.gov.uk n/a — UK public body UK n/a
Overpass API (OpenStreetMap data) n/a — no key, no account, no processor appointment Not stated — overpass-api.de is community-run and publishes no location for query data n/a — a disclosure to a third-party controller, not a transfer we make
Meta — wa.me WhatsApp share links (live, web portal only) n/a — no key, no account, no processor appointment Not established here — wa.me is Meta-operated, and which entity controls the data depends on the recipient's own WhatsApp account n/a — a disclosure to a third-party controller, not a transfer we make
Outbound links only — nationalarchives.gov.uk, and council websites named by planning.data.gov.uk (note 3) n/a — no data is sent and there is no processor relationship n/a n/a

For the two keyless public APIs contacted by the browser — postcodes.io and Open-Meteo — a formal DPA may not be available. If it is not, record that, record what is sent (a postcode, or the depot coordinate), and note the assessment that this is low-risk. Do not leave the box blank as though it were an oversight.

The google.com/maps links are a different shape again: there is no API key, no account and no processor appointment behind them, because the disclosure happens when a person opens a link to a public website. A DPA is unlikely to be the right instrument. Record what is disclosed (site coordinates or postcodes, and for a round the whole day's stops), decide how you are describing it, and do not leave it off the register on the grounds that we do not make the call ourselves.

The wa.me share links are the same shape, with one difference worth keeping straight: the person who makes the disclosure is the portal customer, about themselves and about the firm they are inviting — their own display label and the invitation token go into the URL, and their own browser opens it. Nothing of the contractor's goes with it. So the register entry is a disclosure to a third-party controller, as above; what the portal owes that customer is the plain statement that tapping the button hands the message to WhatsApp, which the screen already makes obvious by naming the control after it.

Changes to this list

We will give subscribers at least 30 days' notice before adding or replacing a sub-processor, by email to the account address and by updating this page. See clause 8.5 of the DPA.

This list is published at /legal/sub-processors, which is a stable URL a business buyer can link to and re-check. Nothing in the product notifies anyone when this page is amended, so the 30 days' notice above is a commitment kept by hand. To be told when this page changes, email jack@routeround.co.uk asking to be added to the sub-processor notification list. We keep that list by hand and write to it before a change takes effect. It is deliberately an email list rather than a feature: a notification the product sends is a thing that can silently break, and this is a commitment we would rather keep in a way we notice failing.