Wix platform annex
What our Velo code and any Wix App Market app can reach, whose personal data that is, and what happens on removal. Our per-app privacy policies at /legal/apps/ inherit this page rather than restating it.
Draft, not yet reviewed by a lawyer. These documents were prepared as a structured starting point. Every highlighted value still needs to be supplied, and the whole set needs review by qualified counsel in India before it is relied on.
What this annex covers
This is a Platform annex. It describes Wix and nothing else: what its APIs expose to an app, whose personal data that is, how a merchant installs and authorises an app, and what happens to access and data when the app is removed.
It exists so that no other page has to restate it. Every app we publish has its own privacy policy at /legal/apps/, and those policies inherit this annex instead of repeating it. An app policy names the specific permissions that app holds, the records it actually touches, and the retention that applies to it. This annex describes the outer limit: what Wix makes available to an app that asks for it.
Read the two together with these rules:
- An app never holds more than this annex describes, and normally holds far less. We ask for the narrowest permission a task needs.
- Where an app's own policy and this annex differ about what that app does, the app's own policy governs.
- This annex is a description, not a contract. It does not change your agreement with Wix. See where the platform's policies govern.
For what an Agent actually does on this platform, see the Wix platform page.
One distinction shapes everything below. Most of our Wix work is Velo backend code inside your own Wix project, not a third-party app installed from the Wix App Market. Those two are governed differently, and this annex covers both. Where a section applies to only one of them, it says so.
What this platform exposes to an app
Wix is the one platform in this set that hands you real backend code in the same project as the site. When we build in Velo, the code runs server-side in the site's own project and reads the site's data under the site's own permission rules. There is no third-party credential, because the code is part of the site.
When instead we publish an app to the Wix App Market, that app is a third party. It is installed against a site, it requests permissions, and it holds its own credentials. That is the case the phrase "what a platform exposes to an app" is really about.
The table below lists the surfaces our Wix work uses, taken from the Wix platform page.
| Resource or scope | What it contains | Includes end-customer personal data |
|---|---|---|
| wix-crm Contacts | Contact records held by the site: name, email address, phone number, labels, and the custom fields the site owner defined. | Yes. This is the primary personal data store on a Wix site. |
| wix-data collections | The site's own database collections. Contents are whatever the site owner chose to store, which very often includes form submissions. | Depends on the collection, and frequently yes. Treat as personal data unless you have checked the collection. |
| Wix Stores Catalog | Products, prices, options, images and inventory. | Normally no. |
| Wix Stores orders | Order records: buyer name, contact details, shipping address, line items and totals. | Yes. {{VERIFY: the current module and API name for reading Wix Stores or Wix eCommerce orders, and which permission covers it, against the Wix Velo and REST API references}} |
| Wix Bookings | Appointments, services, availability and attendee details. | Yes, where a booking names the person who made it. |
| Wix Blog | Posts and drafts, categories and tags. | Normally no, beyond author names. |
| Wix Automations | The trigger layer. Payloads for form fills, store events and scheduled runs, carrying whatever the triggering event contained. | Yes for form and order triggers. A form fill is personal data by definition. |
| Secrets Manager | API keys and model credentials used by backend code, kept out of front-end code. | No, but it is the most sensitive store on the site and is treated as such. |
| Wix Headless | Used only where the front end lives outside Wix. If it does not, we do not reach for it. | {{VERIFY: which APIs and permissions a Wix Headless client can reach, and whether that differs from an App Market app installed on the same site, against the Wix Headless documentation}} |
| Wix Blocks | Where we build a reusable approval widget when a team wants the queue inside the editor. A user interface surface, not a data surface of its own. | It renders whatever the widget is given. On its own, nothing. |
We are not going to name Wix permission scopes from memory, because getting one wrong would be worse than leaving the gap visible:
- {{VERIFY: the current permission or scope names a Wix App Market app requests for each resource in the table above, against the Wix app permissions documentation. Never publish a scope name that has not been read off the current reference}}
- {{VERIFY: whether Wix distinguishes permissions granted at install from permissions that require separate approval or review, and whether any contact or order permission is treated as sensitive}}
- {{VERIFY: what a Velo backend module can read without any additional grant, and how wix-data collection permissions and suppressAuth interact with that, against the current Velo permissions documentation}}
Personal data an app can reach, and whose it is
The personal data on a Wix site belongs to the site owner's visitors, leads, buyers and booking clients. Under the definitions we use across these documents they are End Customers. They are not our customers.
Wix sites concentrate personal data in a way the commerce platforms do not. A single site can hold contact records, form submissions, orders and appointments in the same project, so the practical reach of one agent is wider here than the equivalent agent on a catalogue-only platform. We scope for that, and we say so at the point where a run is designed rather than after.
- End Customers. Contacts, form respondents, buyers, and anyone who booked an appointment. Name, email, phone, address, appointment history and whatever a custom field holds.
- Site staff. The people with editor or dashboard access. An approval queue built as a Wix collection records which of them cleared an action.
- Anyone named in a free-text field. Form submissions and collection records are unstructured. A message field can contain a third party's details that nobody planned for. This is why we treat collections as personal data by default.
For End Customer Data that an Agent reads or writes on your systems, you are the controller and we are the processor. You decide what the Agent does, which systems it reaches, and what it is allowed to write. We act on your documented instructions, which are the scope and configuration we agree with you in writing.
For Service Data, we are the controller.
Two things follow:
- A visitor's request comes to you first. If an End Customer asks about their data, the site owner is the controller and answers it. If they contact us directly, we will pass the request on and support you in answering it.
- A run trace can contain personal data. A trace records what an Agent read and wrote, so contact and form fields end up inside it. Trace retention is {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}.
Where the work is Velo code in your own project, there is a further point in your favour: the data does not leave Wix in order to be read. It leaves only where the Agent sends something to a model provider, which is covered in AI and your data.
How an app is installed and authorised, and what you are agreeing to
Velo code in your own project
There is no install and no third-party grant. We are given collaborator access to your Wix project, we write backend modules in it, and the code runs as part of your site. What you are agreeing to is straightforward and worth stating anyway:
- You are granting named people at AI Speedforce access to your Wix project for the duration of the work. That access is a Wix account permission you control and can withdraw at any time.
- The code we write reads your collections under your site's own permission rules. It does not create a separate credential that outlives our access.
- Credentials the Agent needs, such as model provider keys, are held in the Wix Secrets Manager on your site, not in front-end code and not in a file we keep.
- {{VERIFY: the current collaborator role names and permission levels Wix offers, and the minimum role needed to publish Velo backend code, against the Wix account permissions documentation}}
A Wix App Market app
An App Market app is installed against a site by someone with permission to install apps, and Wix shows the permissions the app is requesting before the install completes. When you approve that screen you are agreeing that the app may reach every record covered by those permissions, not only the ones you had in mind.
- {{VERIFY: what the Wix install and consent flow shows a site owner today, whether permissions can be granted individually or only as a set, and whether an installed app can request additional permissions without a fresh grant}}
- {{VERIFY: whether Wix operates an app review process before an app may be listed in the App Market, and what it examines in relation to data handling}}
In both cases, granting access is not the same as instructing the Agent. What the Agent may do with what it can reach, and which writes wait for a person, is set in the configuration we agree with you in writing. On Wix the default is stricter than elsewhere: every outbound message and every publish waits for a person.
Uninstall and deletion
Velo code in your own project
Ending the engagement means two things happen, and you can do both without us: you remove our collaborator access from your Wix account, and the backend modules stay in your project because they are part of your site. There is no third-party access token to revoke, because none was ever issued.
Anything the Agent wrote to your collections, contacts or catalogue stays written. Removing our access does not roll back work an Agent did while it was running.
A Wix App Market app
Uninstalling from the site's dashboard is the merchant's control. What we can say without checking is limited, so here is what needs confirming rather than a confident paragraph:
- {{VERIFY: whether Wix revokes an app's access tokens immediately on uninstall, or whether a token remains valid for a period, against the Wix app lifecycle documentation}}
- {{VERIFY: whether Wix sends an app-removed or instance-removed webhook on uninstall, what it is called today, and whether responding to it is mandatory}}
- {{VERIFY: whether Wix requires an app to delete site data after uninstall, and within what period, against the Wix App Market terms for developers}}
What we commit to regardless
Whether the work was Velo code or an installed app, we delete or return the data we hold for your site within {{TODO: COMMERCIAL TERM. Days after termination within which client data is deleted or returned}}, subject to the retention terms in the data processing addendum. That commitment is ours and does not depend on what Wix requires.
Your own site data stays in Wix. Deleting data from a Wix site is done in Wix, by you, and is governed by Wix's own retention and backup behaviour: {{VERIFY: how long Wix retains site content, contacts and collection data after deletion, and its backup rotation, against the Wix support documentation}}
Does Wix have a mandatory compliance mechanism
We are not going to answer this from memory. Shopify publishes three mandatory compliance webhook topics that every app must implement, and it would be easy and wrong to assume every platform has an equivalent.
What has to be checked before anything is asserted here:
- {{VERIFY: whether Wix operates a mandatory data-request or data-deletion callback that an App Market app must implement, comparable to Shopify's customers/data_request, customers/redact and shop/redact. If no such mechanism exists, say so plainly rather than leaving this section vague}}
- {{VERIFY: whether Wix provides site owners with a built-in tool for exporting or erasing a contact's personal data, what it is called, and whether an installed app is drawn into that flow}}
- {{VERIFY: what the Wix App Market developer terms require of an app that receives a data subject request forwarded by a site owner, including any response deadline}}
Until those are confirmed, treat the position as: the site owner is responsible for answering a data subject request, and we support you in answering it. That is true whatever Wix turns out to require, because it follows from you being the controller.
For Velo work there is no platform mechanism at all, and there could not be. The code is part of your site, so a request about data in your collections is answered from your site, by you.
Where Wix's own policies govern, not ours
- Your agreement with Wix. Your use of Wix is governed by your contract with Wix, not by anything we publish. That includes their terms of use and the data processing terms Wix offers site owners.
- Wix as a processor of your site data. Wix hosts your contacts, collections, orders and bookings. What Wix itself does with them is described by Wix. {{VERIFY: the current URL and title of Wix's site-owner-facing privacy and data processing terms before linking to them}}
- Cookies set by Wix. Wix sets its own cookies in the dashboard and editor to keep you signed in, and sets cookies on published sites for session handling and any Wix feature you have enabled. Those are Wix's, under Wix's policies. {{VERIFY: which cookies Wix sets on a published site by default, and which are conditional on features the site owner enables, against the Wix cookie documentation}}
- Visitor consent on your published site. Whether your site needs a cookie banner, and what it must say, is between you, Wix and the law that applies to your visitors. Our cookie policy covers this website only.
- Payments. Card handling on Wix Stores is done by Wix and its payment providers under their own obligations. It is not something our code touches.
- App Market terms. If we publish an app, Wix's developer terms apply to us as the developer. That is our obligation to Wix, not a term of your agreement with us.
Related documents
- App policies. The per-app privacy policies that inherit this annex. Start there if you want to know what one specific app holds.
- Wix agents. What we build on this platform, the API surfaces we use, and where the human approval gate sits.
- All platform annexes: Shopify, WordPress, Ecwid, HighLevel, BigCommerce.
- Privacy policy. How we handle personal data on this website and in agency work.
- Data processing addendum. The processor terms that apply when an Agent touches End Customer Data on your systems.
- AI and your data. What reaches a model provider, and on what terms.
- Sub-processors. Every third party that may process data on our behalf.
- Security. How credentials for this platform are held.
Changes to this annex
We may update this document. When we do, we change the "Last updated" date and add a row to the version history below. Section anchors are stable and we do not rename them, so a link to a section keeps working.
Platform requirements change on the platform's schedule, not ours. Anything on this page marked {{VERIFY: ...}} has not been confirmed against Wix documentation at the time of writing and must not be relied on until it has been. If you find a statement here that no longer matches what Wix publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.
Version history
| Version | Date | Change |
|---|---|---|
| 0.1-draft | {{TODO: effective_date}} | First published draft. Not yet reviewed by counsel. |