Sub-processors.
Last updated: 28 September 2026
PitlaneHQ engages the third-party service providers ("sub-processors") listed below to deliver the Service. It is referenced by our Privacy Policy and the Customer Data Processing Addendum.
We maintain this page on a best-efforts basis and update it when we become aware of a change. We are deliberately not calling it authoritative or guaranteed complete: a page that claims that is wrong the first day a provider changes, and an accurate description of how it is kept is worth more than a stronger claim we cannot stand behind. If a provider looks missing or out of date, tell us at privacy@pitlanehq.com.au and we will correct it.
Sub-processors are categorised by the function they perform. Some are engaged for every workshop (infrastructure, payments, communications, observability); others are opt-in and are only engaged when a workshop activates the corresponding integration. A sign-in provider is different again: it is engaged only for a person who chooses to sign in with it.
Infrastructure and storage
Engaged for every workshop. Most of these providers host or back up the Service. Mapbox looks up addresses instead, and no workshop setting controls it: text a signed-in user types into an address field can be sent to Mapbox while they type.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Microsoft Azure | Application hosting, primary database, secrets management | Australia (East — Sydney) | All workshop and customer data |
| Cloudflare Inc. | CDN, DDoS protection, Web Application Firewall | Global edge network | Request metadata, IP addresses |
| Amazon Web Services | Encrypted backup storage (S3) | Australia (ap-southeast-2 — Sydney) | Encrypted backup bundles |
| Backblaze Inc. | Secondary encrypted backup storage (B2) | United States | Encrypted backup bundles |
| Mapbox, Inc. | Address autocomplete and validation when entering a customer or site address | United States | Partial address text entered into an address field |
Payments and communications
Stripe and Twilio are engaged for every workshop. Xero is engaged for PitlaneHQ's own accounts: every workshop we bill is recorded there, whether or not it uses Xero itself. Global Payments and RingCentral are engaged only where a workshop turns the relevant feature on — taking card payments, or Pitlane Phones. Note that Stripe processes PitlaneHQ's subscription billing — it is not the payment processor your workshop uses to collect payments from your own customers.Pitlane Pay, which will run on Global Payments, is not yet available. Its row is listed below prospectively, so the register is complete for when it is switched on. The Twilio SendGrid row was added to this page on 31 August 2026 and published with our release of 4 September 2026, so the notice arrived before the engagement. Forwarding supplier bills to a PitlaneHQ address for automatic reading is built to run on SendGrid Inbound Parse and is switched off. Nothing is being sent to SendGrid today. When it is switched on, SendGrid receives mail addressed to PitlaneHQ's bills domain and passes it to the Service; your workshop has an address on that domain only once it turns on its own bills forwarding address, and Settings → Bills inbox shows which state your workshop is in. Only PDF attachments are kept. Each message is held for up to 90 days if nobody converts it into a bill, and for 30 days if it was quarantined, rejected, dismissed or was a duplicate; a daily sweep then deletes the message and its stored PDF (see our Privacy Policy, section 9, for the one exception). Corrected on 12 September 2026: the RingCentral row previously said RingCentral performed speech-to-text transcription. It does not — transcription runs on Microsoft Azure AI Speech in Australia, which is now listed in the AI table. Azure AI Speech and the OpenStreetMap geocoding service were both missing from this register and have been added, and the Sentry row now states that it receives the signed-in user's name and email address rather than only an identifier. Updated on 26 September 2026: the Sentry row now also lists IP addresses, device details, request and response headers, page and request URLs, error, log and console messages, the labels of clicked buttons and links, performance timings, session recordings and the user's role, and its purpose now names log collection and session replay. Sentry already received these; the row did not say so.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Stripe Payments Australia Pty Ltd | Subscription billing for the PitlaneHQ platform itself | Australia + United States | Workshop billing contact, payment method, transaction history |
| Xero Limited (PitlaneHQ’s own accounts) | PitlaneHQ’s own bookkeeping, not a workshop integration: we record our own subscription billing in PitlaneHQ’s own Xero organisation, whether or not a workshop uses Xero itself. A workshop does not switch this on and cannot switch it off | New Zealand (company); hosted on Amazon Web Services, with processing outside Australia including in the United States | For each workshop we bill: its trading name, email address (the account owner’s, or else the workshop’s) and street address, held as a contact in our Xero organisation, and the PitlaneHQ subscription invoices, credit notes and payments recorded against it |
| Twilio Inc. | SMS delivery (booking reminders, quote approvals, customer communications) | United States | Phone numbers, message content |
| Resend (Anti-Spam Inc.) | Transactional email delivery | United States | Email addresses, message content |
| Twilio SendGrid (Inbound Parse) | Inbound email processing for supplier bills — receiving bills a workshop forwards to its PitlaneHQ bills address and handing them to the Service to be read and matched. Built and switched off: it is not in use yet, and no email is routed through it today. When PitlaneHQ switches it on in an environment, SendGrid receives mail addressed to PitlaneHQ's bills domain and passes it to the Service; a workshop has an address on that domain, and uses the inbox, only once it turns on its own forwarding address. | United States | The forwarded email and its PDF attachment: sender and recipient addresses, subject, message body, and the supplier bill itself. Only PDF attachments are kept; other attachments are not. A message with no PDF attachment is rejected and shown as such. |
| Global Payments (Pitlane Pay) | Planned card payment processing, once Pitlane Pay is enabled, where a workshop takes payment from its own customers, including in-person terminal and counter sales | Australia + New Zealand | Cardholder name, truncated card details, transaction amounts and references, settlement records. Full card numbers are handled by Global Payments and never reach PitlaneHQ systems. |
| RingCentral, Inc. | Business telephony where a workshop enables Pitlane Phones — call handling, voicemail and call recording. Transcription is performed by a separate processor listed below, not by RingCentral. | United States | Caller and recipient phone numbers, call metadata, call recordings and their transcripts, voicemail audio and transcripts |
Observability and developer tooling
Engaged for every workshop. Used to detect and resolve service issues.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Functional Software, Inc. (Sentry) | Application error tracking, performance monitoring, log collection and session replay | Germany (EU region) | Error messages, stack traces, application log messages and the details logged with them, performance timings and request identifiers; the IP address with each browser session, browser log message, error report and sampled performance trace; for each error report and each sampled performance trace, browser and device details, and page and request URLs with access-link tokens and query strings removed; on sampled performance traces, request and response headers, with cookie values, passwords and other credentials removed; with each error report and recording, the recent console messages and, in the browser, the labels of buttons and links clicked, neither of which is masked, though a full web address inside them, such as an https:// link, has its access-link token and query string removed; recordings of about one in ten browser sessions, and of most sessions in which an error occurs, except on a page opened from a payment, invitation, password-reset or other access link and on any page visited after it until the browser next loads a page in full, with all page text and form inputs masked, images blocked and phone, email and text-message links left out, though a recording includes the full address of pages visited; and the signed-in user's account identifiers and, where the account has them, name, email address and role |
AI processing
Engaged only when a workshop activates Ask the Boss or an AI assistance feature. Data submitted for AI processing is drawn from the requesting workshop, and is not used to train models served to others. The pooled repair records described in section 4 of the Privacy Policy, from which customer details are removed, are used only internally by PitlaneHQ to improve the platform. They are never shown to, or used in any feature for, another workshop. Licensed third-party technical data is excluded from any model training.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| OpenRouter (routing to Anthropic Claude on zero-data-retention endpoints) | AI inference for Ask the Boss, including draft quote/invoice planning and parts prediction. Ask the Boss may use OpenRouter when configured, or direct AWS Bedrock processing in our own AWS account in Australia otherwise. Each request asks OpenRouter to route only to zero-data-retention providers that do not collect the data. | United States and other regions (no Australian endpoint) | Depending on the features used and the user’s permissions: questions and conversation text; customer names; staff and technician names and hours worked; vehicle details, including registration numbers (rego), VINs and specifications; job numbers, status, descriptions, notes and repair history; quote and invoice descriptions, draft line items and prices; booking details; stock names, SKUs, quantities, reorder levels and locations; catalogue names and prices; and manufacturer technical data |
| Amazon Web Services (Bedrock) | Direct AI inference in our own AWS Bedrock account for Ask the Boss when OpenRouter is not configured, and AI assistance features - such as draft SMS and review replies, quote/invoice wording, technician-note cleanup, job estimation, recorded-call summarisation and vehicle image analysis - and text embedding — converting submitted text into numeric vectors so related jobs and past replies can be retrieved by meaning. Outputs are drafts for human review by default; a workshop can separately switch on automatic sending of SMS replies, which is off unless enabled and gated per message. No solely-automated decisions with legal effect. | Australia | Whatever workshop-scoped content the AI feature in use is given. That includes job, quote and message text; recorded-call transcripts; customer and staff contact details; and vehicle photographs, including bay camera captures read for number plates and exterior damage. Numeric vectors derived from submitted text are retained to support retrieval by meaning. Pooled repair records, with customer details removed, are used only internally by PitlaneHQ to improve the platform, and are never shown to, or used in any feature for, another workshop. |
| Microsoft Azure AI Speech | Speech-to-text. Two paths use it: voice dictation inside the product where a workshop enables voice input, and transcription of recorded calls where a workshop enables Pitlane Phones. This is the processor that performs the transcription referred to in the RingCentral row above. | Australia (East — Sydney) | Voice audio captured by dictation, and recorded call audio, together with the text transcribed from it |
Opt-in integrations
Engaged only when a workshop explicitly activates the corresponding integration in Settings. PitlaneHQ stops sending data to an integration's provider when the workshop disconnects it. PitlaneHQ's own accounts in Xero, listed under Payments and communications, are separate and are not affected by a workshop disconnecting its Xero. Updated on 28 September 2026: the Xero row previously said only that it synchronises invoices and contacts. It now lists what PitlaneHQ exchanges with a workshop's connected Xero organisation, including Xero Payroll data, and where Xero processes it. PitlaneHQ's own use of Xero for its subscription billing was not listed at all; it now has its own row under Payments and communications.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Xero Limited | Accounting and payroll integration for a workshop that connects its own Xero organisation. This row covers that organisation only; PitlaneHQ’s own accounts in Xero have their own row under Payments and communications. Once connected, PitlaneHQ exchanges the following with that organisation: it reads and writes invoices, supplier bills, credit notes, payments, credit-note allocations, and customer and supplier contacts, and can void invoices and credit notes and delete payments it previously recorded; it uploads attachments to supplier bills and reads the file names and Xero identifiers of those already attached, not their contents; it reads the organisation’s details (such as its name and country), its account and tax-rate settings, and the list of Xero organisations the connecting user has connected to PitlaneHQ; when the connection is made, Xero also returns the connecting user’s Xero identity (such as their name and email address); it receives the change notifications Xero sends about that organisation; and, where the workshop has also connected Xero Payroll (Australia or New Zealand), it reads employee records, earnings rates, payroll calendars and leave details, writes timesheets and leave applications, and in New Zealand can delete timesheets and leave it previously wrote. | New Zealand (company); hosted on Amazon Web Services, with processing outside Australia including in the United States | Sent to and received from Xero: customer and supplier contact details; invoice, bill and credit-note line items; payment and allocation records. Sent to Xero: supplier-bill attachments. For attachments already on a bill, Xero returns their details but not their contents, and PitlaneHQ uses only the file names and Xero identifiers. Received from Xero: organisation details, account codes and tax rates, the names of the Xero organisations the connecting user has connected to PitlaneHQ, and the connecting user’s Xero identity (such as their name and email address) when the connection is made. Where payroll is connected, received: employee records, which Xero returns in full and which can include date of birth, home address, contact, tax and bank details — PitlaneHQ keeps only each employee’s name, Xero identifier, whether they are still employed and, in Australia, a reference to their ordinary earnings rate — plus earnings rates, payroll calendars, leave balances and leave details; sent: hours worked and leave applications |
| Intuit Inc. (QuickBooks Online) | Accounting integration, used only where a workshop connects its own QuickBooks Online company. Once connected, it keeps that company in step with PitlaneHQ: it creates and updates customers, invoices, credit notes and supplier bills; creates suppliers; records customer payments, supplier bill payments, credit applied to invoices, and credit-note refunds (as a cheque linked to the credit note); uploads a supplier bill's source document to that bill; and reads those records back, along with the names of documents already attached to a bill, refund receipts, the company's home currency, and its account, tax-code, tax-rate, product and payment-method settings. When a workshop voids a credit note or reverses a supplier payment, it deletes the matching QuickBooks entries. It does not access QuickBooks Payroll. | United States (Intuit may also store or access data in other countries) | Customer and supplier contact details (name, company, email, phone, mobile, billing address); invoice, credit-note and bill line items; customer and supplier payment and refund records; supplier-bill source documents; home currency, account codes, tax codes and rates, products and services, and payment methods |
| Vehicle Visuals | Vehicle illustration / animation lookup for customer-facing quotes and inspections | United States | Vehicle make, model, and year (no personal identifiers) |
| MYOB Australia Pty Ltd | Accounting integration, not yet available — listed ahead of go-live. Once live: synchronises invoices, contacts, and payments | Australia | Customer contact details, invoice line items, payment records |
| InfoAgent (NEVDIS / NHVR vehicle data) | Vehicle registration and VIN lookup against national vehicle registers, so a plate can populate a vehicle record | Australia | Registration plate or VIN submitted for lookup, and the vehicle record returned. Vehicle records can identify an owner indirectly. |
| Bapcor / Burson Auto Parts | Parts catalogue search and stock ordering where a workshop connects its Burson trade account | Australia | Vehicle details, parts requested, workshop trade-account identifiers, order records |
| OpenStreetMap Foundation (Nominatim) | Converting a workshop site address into map coordinates, so a workshop that opts into the marketplace listing can be shown with a service area | Europe | The workshop site address submitted for lookup |
Sign-in providers
Engaged only for a person who chooses to sign in with one — a workshop does not switch it on, and it is not engaged to process a workshop's records or its customers' information. It is listed here because information about the person signing in passes between us and the provider when they use it, and only then.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Microsoft Corporation (Sign in with Microsoft) | If Microsoft sign-in is switched on and a person chooses it, Microsoft confirms their identity to sign in to PitlaneHQ; this is the person’s choice, not a workshop integration | United States | If Microsoft sign-in is switched on and a person chooses it, received FROM Microsoft: the directory identifier, tenant identifier, email address, name and, for a work or school account, whether its email domain is verified by the tenant; we keep the identifiers to recognise the person on later sign-ins; on a first sign-in a trusted email matches an existing account or pre-fills sign-up, and an untrusted email is never matched, so the person first links from Settings > Security. If Microsoft sign-in is switched on and a person chooses it, sent TO Microsoft: that they are signing in to PitlaneHQ, and their PitlaneHQ email address as a sign-in hint only when linking from Settings > Security; no workshop records or customer information. If Microsoft sign-in is switched on and a person chooses it, we do not keep a profile photo or receive or store their Microsoft password |
| Google LLC (Sign in with Google) | Signing in to PitlaneHQ with a Google Account, for a person who chooses to. Google confirms who the person is and tells us; we send Google nothing from the workshop’s records and nothing about its customers | United States | Received FROM Google: the Google Account identifier, the email address and whether Google has verified it, and the name and profile-photo link from the person’s basic Google profile. We keep the identifier, so we can recognise the person next time, and use the email address to find their existing account the first time; we do not keep the photo link. Sent TO Google: that the person is signing in to PitlaneHQ, and, when they link a Google Account to their login from their security settings, their PitlaneHQ email address as a sign-in hint |
Advertising and marketing attribution
Correcting an earlier version of this page: it listed only the analytics used on our own marketing website, and our Privacy Policy said the product itself “carries no advertising or third-party tracking”. That was wrong, and it had been wrong since the marketing-attribution feature shipped. The platforms below have been able to receive end-customer data from inside the product, for workshops that connected them, without appearing on this register. They are listed now.
What this section covers. It is about a workshop's customers. Those records reach an advertising platform only where that workshop connects its own advertising accounts in the Marketing module and switches a platform on; nothing is sent for a workshop that has connected nothing. It is not a statement about PitlaneHQ's own advertising. When someone enquires through a form on pitlanehq.com.au, or starts a trial or begins paying for PitlaneHQ anywhere in our own signup and billing flow, we send that to our advertising accounts and our own Google Analytics 4 property, none of which a workshop controls — that flow is set out under our own website and advertising below. Without this carve-out the sentence read as an absolute, and it was not one.
No advertising or analytics tag is loaded inside the product itself — these are server-to-server sends. What is sent is a conversion event as an end customer moves through the funnel (an enquiry is created, a quote is sent, a quote is accepted, an invoice is paid), carrying the identifiers the platform needs to match that customer to an ad click. Where a workshop has separately accepted the platform's customer-data terms, hashed contact lists are also uploaded to Google Customer Match, Meta Custom Audiences and Microsoft Customer Match — connecting the account alone does not turn that on. Google and Meta receive a hashed email and a hashed phone number, each only where we hold it for that customer; Microsoft receives a hashed email and never a phone number, because its list format has no phone field. Two lists are built: customers with an invoice paid in the last 540 days, and customers sent a quote in the last 90 days that has not converted.
Email addresses and phone numbers are SHA-256 hashed before they leave our servers, and so are names, for every platform that receives them but one. What is not hashed differs per platform — it is named in each row rather than folded into a general claim about hashing, because the exceptions are the part that matters. Google Analytics 4 receives no name, email address or phone number. A customer who has opted out of marketing is excluded from conversion sends. The audience uploads exclude them too, and additionally exclude anyone who has asked to be erased. Getting out of a list already uploaded works differently by platform, and the difference is worth stating rather than averaging: for Google and Meta an erasure request sends an active removal instruction for the identifiers we had already uploaded; for Microsoft it does not, because the daily upload replaces the whole list, so that person drops out when the next daily replace runs rather than at the moment they asked — and if that sync stops first, because the workshop disconnects Microsoft or withdraws the terms, they stay in the list Microsoft already holds. Consent mode is on by default for workshops outside Australia, New Zealand and the United States, or whose country we do not hold, and any workshop can turn it on. Where it is on, a conversion event is suppressed unless the customer granted the matching consent — advertising consent for the advertising platforms, analytics consent for Google Analytics 4. It works differently for the audience uploads: consent mode does not stop them, it changes what we tell Google, which is that consent is unspecified rather than granted.
For end-customer records the workshop is the responsible entity (section 1, second role); connecting an advertising account is the workshop's decision and its customers' data is disclosed on its instruction. Each platform then receives that data under the advertising terms between the workshop and that platform, and decides where it stores it. The locations below are where the receiving company is established, so far as we can state it — not a commitment by us about where the data comes to rest. We do not name a country for TikTok: which group entity contracts with the workshop depends on the advertising terms it accepted, and a country we cannot verify is worse than none.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Google LLC (Google Ads) | Conversion measurement for a workshop’s own Google Ads account — reporting back which enquiries, quotes and paid invoices came from an ad — and, where the workshop has separately accepted Google’s customer-data terms, building Customer Match audiences | United States | SHA-256 hashed email, phone number and name. Country and postcode are sent in PLAIN TEXT, because Google’s address match will not accept them hashed. Sent UNHASHED: the Google click identifier (gclid, gbraid or wbraid) carried in from the ad click. Also the conversion value, currency, an invoice or lead reference used for de-duplication, the campaign, landing-page, submission-page and referrer details recorded with the enquiry, and the consent signals where consent mode applies. Customer Match uploads carry hashed email and phone only. |
| Meta Platforms, Inc. (Conversions API) | Conversion measurement for a workshop’s own Facebook and Instagram advertising, and, where the workshop has separately accepted Meta’s customer-data terms, building Custom Audiences | United States | SHA-256 hashed email, phone number, first and last name, city, state, postcode, country, and a hashed internal customer identifier. Sent UNHASHED, because Meta will not match them otherwise: the Meta click and browser cookie values (_fbc and _fbp) picked up from the page the customer came through, the customer’s IP address, and their browser user-agent string. Also the conversion value, currency, event time, and the page URL and referrer. Custom Audience uploads carry hashed email and phone only. |
| Microsoft Corporation (Microsoft Advertising) | Offline conversion measurement for a workshop’s own Microsoft Advertising (Bing) account, and, where the workshop has separately accepted Microsoft’s customer-data terms, building Customer Match audiences | United States | SHA-256 hashed email and phone number. Sent UNHASHED: the Microsoft click identifier (msclkid) carried in from the ad click. Also the conversion value, currency and event time. Customer Match uploads carry a hashed email ONLY — Microsoft’s bulk list format has no field for a phone number, so none is sent. Those uploads run daily and REPLACE the whole list each time, which is also the only way someone leaves it: we do not issue Microsoft a removal instruction the way we do for Google and Meta. So a person drops out when the next daily replace runs — and only then. If the sync stops before that, because the workshop disconnects Microsoft or withdraws the customer-data terms, no further replace happens and they stay in the list Microsoft already holds. |
| Google LLC (Google Analytics 4 — the workshop’s own property) | Sending funnel events to a workshop’s own GA4 property so its analytics reflect the enquiries, quotes and paid invoices recorded in PitlaneHQ. Separate from the GA4 property we run on our own marketing website, listed further down | United States | The pseudonymous GA4 client identifier recorded when the customer visited, the event name, value, currency, a transaction reference, the page URL and referrer, and the campaign parameters (source, medium, campaign, term, content). No name, email address or phone number is sent to GA4. |
| TikTok (TikTok Pte. Ltd. and affiliates) | Conversion measurement for a workshop’s own TikTok advertising, via the TikTok Events API | Outside Australia (TikTok group entities) | SHA-256 hashed email, phone number and a hashed internal customer identifier. Sent UNHASHED: the TikTok click identifier (ttclid) and the _ttp cookie value picked up from the page the customer came through, the customer’s IP address, and their browser user-agent string. Also the conversion value, currency and event time. |
| LinkedIn Corporation | Conversion measurement for a workshop’s own LinkedIn advertising, via the LinkedIn Conversions API | United States | SHA-256 hashed email, and the LinkedIn first-party ad tracking identifier (li_fat_id) sent unhashed. Where we hold neither, first and last name are sent in PLAIN TEXT, so the event still carries an identifier. Also the conversion value, currency and event time. |
Our own website and our own advertising
These providers receive data about visitors to and enquirers on pitlanehq.com.au, and about people who start a trial or subscribe with us. They do not receive workshop records or a workshop's customers' personal information from inside the product, and they are not engaged to deliver the Service. They are listed here because they still receive personal information about people who come to us.
Two different mechanisms are in this table. Some of it is tags running in your browser: Google Analytics 4 (when configured), Google Tag Manager (when configured) and Meta Pixel (when configured), which load on the marketing website and the sign-up page. The rest is sends that run on our servers: when you submit an enquiry or demo request on this website, start a trial, or become a paying subscriber, we report that to PitlaneHQ's own advertising accounts, and to our own Google Analytics 4 property, so we can tell which of our ads worked. To the three advertising accounts your email address goes too, SHA-256 hashed before it leaves our servers, and your phone number as well where you gave us one on an enquiry form — the trial and subscription events carry the email alone. Google Analytics 4 gets none of that: its send carries the event, its value and a reference only, with no email address, phone number or name.Google Analytics 4 is in both halves: it has a browser tag AND receives these same server-side events, so it is the one row where the split runs through the row rather than between rows.
We are separating them out because the difference decides what you can do about it. Blocking cookies or trackers in your browser can stop the browser tags; it does not touch the server-side sends, which do not run in your browser at all — including the server-side half of the Google Analytics 4 row. There is no self-service switch for the server-side rows; the route is to ask us at privacy@pitlanehq.com.au. We handle that by hand rather than through a switch in the system, and we will stop sending further events about you. An event already sent cannot be recalled, which is the honest limit of that. An earlier version of this page listed only the browser tags, which understated what our own advertising receives; how to control the browser side is explained in our Cookie & Tracking Notice.
| Sub-processor | Purpose | Location | Data processed |
|---|---|---|---|
| Google LLC (Google Tag Manager, when configured) | Loading and managing configured analytics and advertising tags on the marketing website and the sign-up page | United States | Browser requests to load the tag container, including IP address and browser details. The tags it loads receive data according to their configuration; Google Analytics 4 and Meta Pixel are described in their own rows. |
| Google LLC (Google Analytics 4, when configured) | Aggregate traffic measurement on the pitlanehq.com.au marketing website and the sign-up page, and — from our servers rather than your browser — recording an enquiry, trial start or subscription against that same property | United States | Pseudonymous visitor identifier, pages viewed, referrer, approximate location, device and browser. The server-side events carry the event name, value, currency and a reference, with a synthetic identifier standing in for the browser one — no email address, phone number or name is sent to GA4. |
| Meta Platforms, Inc. (Meta Pixel, when configured) | Measuring the effectiveness of our own advertising on Facebook and Instagram, and building advertising audiences, through a browser tag on the marketing website and the sign-up page | United States | Pseudonymous visitor and event identifiers, pages viewed, and whether a form was submitted. If automatic advanced matching is enabled in Meta settings, Meta may receive hashed contact details (such as email, phone number and name) from forms on pages where the Pixel loads, including sign-up, demo and contact forms, through automatic advanced matching. Meta may match these details to an existing Meta account. |
| Google LLC (Google Ads — PitlaneHQ’s own account) | Measuring our own Google advertising: reporting back from our servers when someone enquires through a form on pitlanehq.com.au, starts a trial, or becomes a paying subscriber. This is our advertising, not a workshop’s, and no workshop controls it | United States | A SHA-256 hashed email address, plus the conversion value, currency, event time and a reference used for de-duplication. A hashed phone number is sent ONLY for an enquiry made through a form on our website, because that is the only one of the three events where we hold a phone number — the trial-signup and subscription events carry the email alone. No name, address or message text is sent. |
| Meta Platforms, Inc. (Conversions API — PitlaneHQ’s own account) | The same three events sent to our own Meta advertising account from our servers. SEPARATE from the Meta Pixel row above: the Pixel runs in your browser, where a tracking blocker can stop it; this does not run in your browser, so a tracking blocker cannot reach it at all | United States | A SHA-256 hashed email address, plus the conversion value, currency, event time and a de-duplication reference. A hashed phone number is sent only for a website enquiry, as above. No name, address or message text is sent. Meta may match the hashed values to an existing Meta account. |
| Microsoft Corporation (Microsoft Advertising — PitlaneHQ’s own account) | The same three events sent to our own Microsoft Advertising account from our servers, as offline conversions. We load no Microsoft advertising tag on our website, so this recipient exists because of the server-side send rather than anything running in your browser | United States | A SHA-256 hashed email address, plus the conversion value, currency and event time. A hashed phone number is sent only for a website enquiry, as above. No name, address or message text is sent, and no de-duplication reference: the Microsoft offline-events call has no field for one. |
Cross-border disclosure (APP 8)
Primary hosting, the production database, and encrypted backups (Microsoft Azure and Amazon Web Services — S3) are located in Australia (Sydney). Direct AWS Bedrock AI inference in our own AWS account, including text embedding, is carried out in Australia. Ask the Boss uses that account unless OpenRouter is configured. When configured, OpenRouter may route Ask the Boss to Amazon Bedrock outside Australia. Each request asks OpenRouter to route only to zero-data-retention providers that do not collect the data. The following sub-processors process some or all data outside Australia under contractual safeguards equivalent to Australian Privacy Principle 8. Specifically:
- OpenRouter (United States and other regions) — when configured, Ask the Boss may send questions and conversation text; customer names; staff and technician names and hours worked; vehicle details, including registration numbers (rego), VINs and specifications; job numbers, status, descriptions, notes and repair history; quote and invoice descriptions, draft line items and prices; booking details; stock names, SKUs, quantities, reorder levels and locations; catalogue names and prices; and manufacturer technical data outside Australia, depending on the features used and the user's permissions. OpenRouter has no Australian endpoint. Each request asks OpenRouter to route only to zero-data-retention providers that do not collect the data.
- Sentry (Germany) — GDPR-equivalent jurisdiction, Standard Contractual Clauses in place.
- Stripe, Twilio, Resend, Backblaze, Cloudflare, Intuit, Vehicle Visuals (United States) — contractual safeguards under the relevant Data Processing Addendums; reliance on APP 8.2(a) (recipient bound by substantially similar law) and APP 8.2(b) (your consent, where applicable).
- Google (United States), for Sign in with Google — only for a person who chooses to sign in with Google, and at that person's own request. Beyond the fact that the person is signing in to PitlaneHQ, the most we send Google is their PitlaneHQ email address, as a hint when they link a Google Account to their login; the rest of the exchange is Google telling us who they are.
- Microsoft (United States), for Sign in with Microsoft — if Microsoft sign-in is switched on and a person chooses it, the exchange is at that person's request, Microsoft confirms their identity, and we send their PitlaneHQ email address as a hint only when they link from Settings > Security; no workshop records or customer information.
- Xero (New Zealand company; hosted on Amazon Web Services, including in the United States) — two separate flows. For a workshop's own Xero organisation, only where that workshop connects it, the disclosure is made on its instruction and under the terms it accepts with Xero. For PitlaneHQ's own accounts, the billing details of each workshop we bill are recorded in our own Xero organisation, under our own terms with Xero, whether or not that workshop uses Xero itself.
- Twilio SendGrid (United States) — same basis as Twilio, once the supplier-bill inbound feature is switched on. Not in use today.
- Google, Meta, Microsoft and LinkedIn (United States), and TikTok (outside Australia) — for a workshop's customers, only where that workshop has connected its own advertising accounts or its own Google Analytics 4 property, and the disclosure is then made on that workshop's instruction. A workshop switching this on should tell its own customers what it means for them. The send itself is performed by our servers and we choose the fields; what the workshop controls is whether the connection exists at all. Disconnecting the platform stops further sends; it does not by itself remove anyone from an audience already uploaded. An erasure request sends an active removal to Google and Meta; for Microsoft the person drops out when the next daily upload replaces the list, and stays in the list Microsoft already holds if that sync stops before then.
- Google (both Google Ads and Google Analytics 4), Meta and Microsoft (United States), for our own advertising — a separate disclosure on the same basis, made on PitlaneHQ's own instruction rather than a workshop's, and covering people who enquire through our website, and people who start a trial or begin paying for PitlaneHQ through our own signup and billing flow. No workshop is involved and no workshop can switch it off. See our own website and advertising above.
Notification of changes
We will provide workshops with at least 30 days' notice before engaging a new sub-processor that will process workshop or customer personal information. Notice will be provided by:
- An in-product banner visible to workshop administrators
- An update to this page (this date in "Last updated" will change)
- For material changes, an email to the workshop's registered billing contact
If your workshop objects to a new sub-processor for a good-faith reason, contact us at privacy@pitlanehq.com.au within the 30-day notice window and we will work in good faith to either resolve the concern or, if unable to do so, permit you to terminate the affected Service component.
Contact
Questions about sub-processors or our supply chain:
- Email: privacy@pitlanehq.com.au
- General enquiries: hello@pitlanehq.com.au