Privacy Policy

1. Introduction

This Privacy Policy explains how AdaptivMapr (“we”, “us”, “our”) collects, uses, and shares personal data when you use the AdaptivMapr platform, our website at adaptivmapr.com, our REST API, MCP server, and the dashboard including Chat (collectively, the “Services”).

The policy is written to comply with the EU General Data Protection Regulation (GDPR), the Swiss Federal Act on Data Protection (nFADP, in force since 2023), the UK GDPR / Data Protection Act 2018, and the California Consumer Privacy Act / California Privacy Rights Act (CCPA / CPRA). Where mandatory local rules apply, they take precedence over the general language below.

For the records you submit to be mapped (files, rows, schemas) you are the controller and AdaptivMapr is your processor; that relationship is governed by our Data Processing Addendum at /legal/dpa. This Privacy Policy applies in full where AdaptivMapr is the controller: for account holders, billing contacts, people who contact support, website visitors, and the security and error records described in §3.

2. Data we collect

2.1 Account data

• Email address — the identifier your account is built on — and, if you sign in with Google, the name and profile picture Google shares;
• Sign-in records kept by our authentication provider (Supabase Auth): when you signed in and how. There is no password: sign-in is Google or a one-time email link or code;
• Workspace name, your role in it (owner, admin or member) and the other members of workspaces you share;
• Your acceptance of these policies (version, time, email, IP address and browser user agent) and, if you accept the BAA for a workspace, the name, title, email, IP address and browser of the person who accepted it.

2.2 Usage data

• API request metadata: time, endpoint, response status, duration, workspace and key identifiers, billed units;
• Mapping decisions: source header text, the target field chosen, the cascade layer that chose it and its confidence. Per-workspace statistics of confirmed header-to-field pairs and confirmed layouts (header rows) are kept so the next map of the same shape is faster; they are never shared with another workspace;
• Uploads: file name, size, type, column and row counts, and the parsed content for the retention window described in §7;
• The audit log of your workspace: key creation and revocation, commits and confirmations, settings changes, billing events, support ticket ids, and the actor's email.

2.3 Billing data

• Stripe customer ID, the prepaid wallet balance, a ledger of charges and top-ups, the monthly plan if you take it, and invoice and payment status;
• Billing name, address and VAT number, if you supply them at checkout (held by Stripe);
• We never see your card number, expiry, or CVC — you enter them on Stripe's own payment page.

2.4 Technical data

• IP address. Cloudflare, which runs the whole application, processes it for every request. We use it for rate limiting on the keyless public endpoints (/v1/match, /v1/validate-row, the website demo and browser error reports): the rate-limit counter in our database is keyed by a truncated keyed hash of the address, never the address itself, and every counter row is deleted automatically once its time window is more than a day old (§7). It is also recorded with a policy or BAA acceptance (§2.1);
• Browser user agent, recorded with an acceptance; for an error report, only the browser family and major version;
• Server logs and operational events: route, status, timing, error type and the workspace, key and request identifiers involved. We do not write file content to them.

2.5 Browser error reports

When a page of our site or dashboard hits an error, your browser sends us a short report automatically. There is currently no setting to turn this off. A report carries the error type, its message scrubbed and cut to 300 characters, the top five stack frames (script path, line and column), the page path without its query string or fragment, a Next.js error digest, the build id and a repeat count; for a failed dashboard API call, its method, path, status and request id. Email addresses, long numbers, keys and tokens, and anything following a field name such as “patient”, “name” or “value” are removed in your browser and again on our server. We never collect form values, page text, cookies, or request or response bodies. The server adds your browser family and major version, Cloudflare's request id and, if you are signed in, your workspace id. Reports are kept only in Cloudflare's logs and analytics (§7) — there is no database table for them.

2.6 Prompt-injection signals

Text that is about to be sent to one of our AI features — a Chat message or instruction, or text taken from a file (sheet names, headers, sample cells, document text, macro source) — is checked by an automated detector for attempts to manipulate the AI. Only when the detector flags something do we keep a record: which rules fired and a score, the feature and channel (dashboard, API key, MCP or anonymous), whether the run was PHI-routed, the model tier, region and request id, the workspace id, your user id (dashboard) or an identifier derived from the API key, the input's length and a SHA-256 hash of it, and an excerpt of the matched text only — up to 300 characters either side of a match in an instruction, 80 characters either side in file-derived text, never more than 2,000 characters and never the whole input. An excerpt can contain personal data or PHI that happened to sit next to the match. No IP address or email is recorded. Nothing is blocked, changed or rerouted because of it. Incognito Chat runs are never recorded.

2.7 Support requests

A support request from the dashboard (topic, subject, message and, if you leave the box ticked, diagnostics) is sent as ordinary email through our email provider to our support mailbox, with your address as the reply-to. It is not a secure or encrypted channel for regulated data: do not put patient information (PHI) in a support request. If a request contains some anyway, we delete it and ask you to send it again without it. The optional diagnostics, which the form shows you before you send, are your last 15 API calls (method, path without query, status, request id), your last 10 browser errors, the last dashboard page, the viewport size, time zone and browser user agent. We do not store the text of a request in our database: the audit log keeps its id, topic, message length and the request ids attached to it. Copies remain in the support mailbox. No confirmation email is sent.

2.8 Data we deliberately do not collect

• Row content beyond the clamped sample in schema-only mode — only column headers and up to three sample values (≤80 characters each) leave your environment;
• Biometric data, precise geolocation, behavioural or advertising analytics, advertising identifiers;
• Sensitive categories of personal data, except where they appear in the records you submit — which we process as your processor under the DPA and, for PHI, the BAA.

3. How we use data

• To provide the Services — authenticate you and your API keys, run the mapping cascade (including the model layers described in §5), return mapping recommendations, validate and transform rows, keep remembered chats;
• To bill correctly — charge the prepaid wallet, run the monthly plan, report usage to Stripe, issue invoices;
• To support you — answer support requests, troubleshoot incidents (including from browser error reports), communicate planned maintenance;
• To keep the Services secure — rate limiting, abuse detection, the audit log, and the prompt-injection signal log (§2.6), which we use to detect and study attempts to manipulate our AI processing and to train and evaluate a model that detects such attempts;
• To make your next map faster — your workspace's own statistics of confirmed header-to-field pairs and confirmed layouts (no row values), used only for that workspace;
• To send account email — sign-in links, security and destructive-action notices, billing and quota notices, and short onboarding emails after sign-up;
• To meet legal obligations — keep accounting records, respond to lawful requests from authorities.

We do not use your data for behavioural advertising, and we do not sell or share personal data with third parties for their own purposes (within the meaning of CCPA / CPRA). We do not use the records you submit to train foundation models, ours or anyone else's; our mapping ranker was trained on synthetic and public data. The one training use of your content is the prompt-injection signal excerpts described in §2.6.

4. Legal bases (GDPR / nFADP)

Where GDPR or nFADP applies, we rely on the following legal bases:

• Contract (Art. 6(1)(b) GDPR) — to provide the Services you have signed up for, including authentication, billing, and support;
• Legitimate interest (Art. 6(1)(f) GDPR) — to operate the platform securely (abuse detection, rate limiting, error reports, the prompt-injection signal log, incident response) and to send essential service communications;
• Legal obligation (Art. 6(1)(c) GDPR) — to keep accounting records and to respond to lawful requests;
• Consent (Art. 6(1)(a) GDPR) — for any optional marketing communications. You can withdraw consent at any time.

5. Sharing, models & subprocessors

We share data with the following categories of recipients, all bound by written agreements or terms with confidentiality and security obligations:

• Hosting — Cloudflare runs the application and holds uploads for their retention window; Supabase (in Zurich, Switzerland) holds the database and handles sign-in;
• Payments — Stripe receives your billing name, email, address, VAT number and card details (which we never touch);
• Email — Resend delivers the email we send (an SMTP relay takes over only if Resend is not configured), including support requests to our support mailbox;
• Sign-in — Google, if you choose Sign in with Google;
• Models — see below.

How the mapping cascade uses models. Columns are matched first by three deterministic layers (statistics, heuristics, fuzzy matching). Columns they leave unresolved go to our own mapping ranker — a model on our own hardware in Switzerland (or, for a workspace with no region pin when that hardware is unreachable, the same model on RunPod in the EU) — which receives column names and a statistical profile of each column computed on our servers (value kind, length range, uniqueness, share of empty cells), never a cell value. Columns still unresolved, and every Chat, convert and reshape request, go through phi-cloud, our model gateway, which forwards the call to a model provider: for a PHI-routed run only a PHI-eligible provider resident in your workspace's region, under a BAA; for a standard run a general-purpose model from Inception Labs (US) or Z.ai (Zhipu AI). In schema-only mode a model receives column headers and at most three sample values of at most 80 characters; in full-data mode it can receive full rows. Spreadsheet macro edits send the whole workbook to Monopea, operated by the same operator as AdaptivMapr, for the duration of the edit.

There is no setting that keeps a map away from these models. Which layers run is decided by our configuration and by which columns are left unresolved. What you control is how much a model can see — schema-only or full-data mode — and whether a run is PHI-routed. Keyless public calls (/v1/match without an API key and the website demo) use only the three deterministic layers.

The complete subprocessor list, with each one's role, location and agreement, is at /legal/subprocessors (also in DPA Article 8). The systems you connect yourself — a CRM, a storage bucket, a spreadsheet, a webhook endpoint — receive data on your instruction and are your own vendors.

6. International transfers

Our database is in Switzerland (Zurich). Cloudflare serves requests from its global network, and some subprocessors are located in, or transfer data to, the United States or other third countries — including the general-purpose model providers used for standard runs. For these transfers we rely on:

• The EU Standard Contractual Clauses (Modules 2 and 3, Commission Decision 2021/914) for transfers out of the EEA;
• The UK Addendum issued by the UK ICO for transfers out of the UK;
• The Swiss adequacy decisions and supplementary clauses where the recipient country does not appear on the Swiss list of adequate jurisdictions;
• The EU-US Data Privacy Framework where the recipient is certified.

A PHI-routed run keeps its model processing inside the region pinned for the workspace (CH, EU, UK or US).

7. Retention

• Parsed upload content — held in Cloudflare KV under a time-to-live your workspace sets (24 hours by default; 0, 168 or 720 hours are the other options) and discarded automatically when it expires. Our database keeps a mirror: in full-data mode the full rows are cleared from it within 15 minutes of expiry. A committed upload is deleted from both at commit. An upload that expires without being committed leaves its record in the database — file name, column headers, the clamped sample of at most three rows and the mappings — until the workspace is deleted. A retention setting of 0 means the upload is never written to KV and is deleted when the mapping is committed. The expires_at returned with every upload is the authoritative expiry;
• Workspace content — saved schemas, mapping statistics, confirmed layouts, saved reshape programs, settings, members and API key records: for the life of the workspace, deleted with it. Remembered chats and their files: until you delete the chat or the workspace;
• Audit log — each entry is kept for seven years (2,557 days) while the workspace exists, then deleted by a daily sweep; the whole log is erased with the workspace (§8);
• Prompt-injection signals — deleted automatically after 180 days by a daily cleanup, or earlier with the workspace. Only AdaptivMapr operators can read them; you receive your workspace's records in the data export;
• Server logs, operational events and browser error reports — kept by Cloudflare: Workers Logs for 7 days, Analytics Engine for Cloudflare's retention period for that product (currently three months);
• Rate-limit counters — one row per workspace, key, connector or (for the keyless public endpoints) hashed address per time window of at most an hour; deleted by a daily cleanup once the window is more than a day old, or earlier with the workspace;
• Support requests — not stored in our database; copies remain in our support mailbox, which has no automatic deletion period;
• Billing ledger — one row per wallet charge, top-up and plan reset (amounts, dates, kinds and Stripe references, no file content). Kept after the workspace is deleted, for accounting, with nothing left that links it to the workspace or to you. Stripe keeps its own invoices and payments;
• Signed agreements and policy acceptances — the BAA / DPA a workspace accepted and each person's acceptance of these policies, with the identity details in §2.1. Kept after account or workspace deletion as evidence of the agreement, then deleted automatically: a signed agreement six years after its workspace was deleted, an acceptance six years after that person last accepted these policies once their account no longer exists;
• Erasure records — one anonymous record per erasure (see §8), kept indefinitely;
• Backups — our database provider takes daily backups, kept for 7 days. Data you erase remains in those backups until they age out; we do not restore an erased workspace from them.

8. Your rights

For a plain-English summary of what we store and the self-serve export and deletion options, see our Your Data page (/data).

Depending on where you reside, you may have the following rights with respect to your personal data:

• Access — request a copy of the personal data we hold about you;
• Rectification — correct inaccurate or incomplete data;
• Erasure — request deletion (see below for what is kept);
• Restriction — limit our processing in certain circumstances;
• Portability — receive your data in a structured, machine-readable format. Workspace owners and admins can download one JSON file from Settings → Account;
• Objection — object to processing based on legitimate interest;
• Withdrawal of consent — for any consent-based processing;
• Not to be subject to automated decisions producing legal or similarly significant effects without human review. The AdaptivMapr cascade is a decision-support tool; final acceptance of a mapping decision happens in your environment, not ours.

What erasure does. Deleting a workspace erases everything in it, for every member: uploads and their stored copies, connectors and their secrets, API keys, chats and stored files, schemas, saved mappings and reshape programs, settings, and the workspace’s audit log. Its phi-cloud key is revoked and its Stripe customer profile is deleted, which also cancels any subscription. Deleting your account erases every workspace where you are the only member and removes you from workspaces you share with others — those stay with their members, including their audit log of what you did there, but your email is removed from their uploads and approvals. Then your sign-in is deleted. The audit log is erased with the workspace. What remains is one anonymous erasure record — a one-way hash of the workspace id, the time, and how many records were removed — so an erasure can be shown to have happened without keeping whose it was. The billing ledger, signed agreements and policy acceptances are kept as described in §7. An erasure is all-or-nothing in our database and is never reported as done unless every step finished; if account deletion fails, your sign-in is kept so you can try again. What we cannot erase on demand: Cloudflare's logs and analytics (identifiers, no file content) expire under Cloudflare's retention, Resend keeps its log of sent email, a few short-lived markers expire within 7 days, and database backups age out after 7 days. Audit entries of workspaces erased before 9 October 2026 were detached from the workspace rather than deleted; a one-off cleanup removes them, and any that remain are deleted automatically six years after they were written.

To exercise these rights, email dpo@adaptivmapr.com. We will respond within one month of receipt (extendable by two further months for complex requests, with notification). If you believe we have failed to handle your request properly, you have the right to lodge a complaint with your local supervisory authority — for Swiss residents, the FDPIC (edoeb.admin.ch); for EU residents, the supervisory authority of your member state.

9. Children's privacy

AdaptivMapr is a B2B platform and is not directed at children. We do not knowingly collect personal data from anyone under 18. If you believe we have inadvertently collected data from a minor, please contact us and we will delete it.

10. Cookies and browser storage

The site and dashboard use only strictly necessary cookies: the sign-in session issued by our authentication provider and a CSRF protection token. The dashboard keeps its support diagnostics (§2.7) in your browser tab's session storage and a few interface preferences in local storage. We do not use analytics, advertising or social media cookies. Sign in with Google loads Google's script on the sign-in pages; cookies Google sets on its own domain are governed by Google's privacy policy. If we add optional analytics in the future, we will ask for your consent before any non-essential cookie is set.

11. Changes to this Policy

Material changes will be notified to the email address on file for the workspace at least 30 days before they take effect, and signed-in users are asked to accept the new version in the dashboard. The version of this document is the “Last updated” date at the top of the page.

12. Contact

For privacy questions or to exercise your rights, contact our data protection contact at dpo@adaptivmapr.com. General company contact: hello@adaptivmapr.com.