Data and security
The short version: the widget checks a license and renders a model. What the visitor clicks goes to your page, not to us. Below is the longer version, because "we take privacy seriously" is not an answer.
What the widget sends to us
- The license key and the domain it is running on Sent to our API to check that this domain is licensed. Nothing about the visitor travels with it.
- A request for the widget configuration Returns the feature set and presentation settings for that license. Same request for every visitor.
- The 3D model files Static assets, cached by the browser. No per-visitor component.
That is the whole list. Two API calls, both about the license rather than the person using it. Run the widget unlicensed and even those stop, because there is nothing to validate.
What stays on the visitor's device
- Which body zone was clicked Emitted to the page that embeds the widget through postMessage. It is not sent to us.
- Anything typed into the optional form Client-side only, handed to your page for export. Disabled entirely in the Shopify app.
- Which body model the visitor selected A rendering preference. It does not leave the frame except as an event to your page.
What we never collect
- Visitor names, emails or account identifiers
- Symptom descriptions, diagnoses or medical history
- Behavioural profiles or advertising identifiers
- Analytics cookies set by the widget
- Cross-site tracking of any kind
Why a zone click is not health data
This is the question every compliance review asks, and the honest answer has two halves.
Inside the widget, a zone click is a navigation event. It is not tied to an identity, it is not stored on our side, and it carries no statement about the visitor's health. Somebody clicking a knee on a storefront is the same category of signal as somebody clicking a "Knee supports" link in a menu. Nobody treats a category click as a medical record, and there is no principled reason to treat this one differently.
The other half matters more. The moment you attach that selection to a named person or a patient record, it becomes health data in your system, under whatever regime applies to you. That processing happens in your form handler and your database. We are not in that path, which is exactly why the widget does not need a data processing agreement for visitor data and your intake pipeline does need the same care it already needed.
If you are building a clinical intake flow, the clinic intake guide goes through where that line sits in practice and what to store.
Controls you get
Per-domain licensing. A license is bound to the domains you register. Staging and production count separately, which is occasionally annoying and entirely the point: a key cannot quietly start working on a site you did not intend.
Origin-validated messaging. The postMessage envelope is versioned and carries a fixed source identifier, so your listener can reject anything that is not the widget. The API contract documents the exact shape.
No form on storefronts. In the Shopify app the form and pain-submission controls are hard-disabled rather than hidden. A storefront is not a place to collect symptoms, and the feature cannot be switched back on by a theme setting.
Not a medical device. The widget records a location and stops there. It does not diagnose, triage or recommend anything, and every reading of that location stays with you and your clinicians.
Reviewing us for a procurement process
Send the questionnaire. We would rather answer a specific question about subprocessors, retention or a data processing agreement than point you at a badge. For the legal wording, the privacy policy and terms are the binding documents.