Ecwid platform annex

What this annex covers

This is a Platform annex. It describes Ecwid 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 Ecwid 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 Ecwid. See where the platform's policies govern.

For what an Agent actually does on this platform, see the Ecwid platform page.

Ecwid has one structural feature that no other platform in this set shares: the store is embedded in a site built on something else. That host site is not an Ecwid surface and is not covered by Ecwid's policies or by this annex. Where the host page matters to what an agent does, this annex says so and points at the annex that does cover it.

What this platform exposes to an app

The working surface is the Ecwid REST API v3, reached with an OAuth token issued for one store. Catalogue writes go out through /batch, so a catalogue-wide pass runs as batched writes rather than a request per product and stays inside the rate limits. Webhooks push events to the app so a run starts on a store event rather than a polling loop.

The table below lists the surfaces our Ecwid work uses, taken from the Ecwid platform page.

Ecwid controls access with OAuth scopes, and each agent holds only the scopes its task needs, so a cleanup agent cannot reach orders. We are not going to write scope names from memory:

• {{VERIFY: the exact current OAuth scope names Ecwid uses for reading and writing products, categories, orders, customers and store settings, against the Ecwid API documentation. Never publish a scope name that has not been read off the current reference}}
• {{VERIFY: whether Ecwid separates read and write scopes per resource, and whether any scope covering customer or order data requires additional approval before an app may request it}}
• {{VERIFY: the current webhook event names Ecwid supports and whether the two named above are still current, against the Ecwid webhooks documentation}}
• {{VERIFY: whether Ecwid, now part of Lightspeed, has renamed the product or its API surface, and whether these annexes should refer to it by a different name}}

Personal data an app can reach, and whose it is

The personal data on an Ecwid store belongs to the merchant's buyers. Under the definitions we use across these documents they are End Customers. They are not our customers.

• End Customers. Buyers who placed an order or created an account. Name, email, phone, shipping and billing address, order history, and anything typed into an order comment.
• The merchant. Store profile and business contact details. On a one-person store the merchant's details are personal data too, and this annex does not pretend otherwise.
• Anyone named on the host page. Where the agent reads the host site to reconcile it against the catalogue, whatever is on that page is in scope for that read. It is governed by the host platform, not by Ecwid.

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 Ecwid-specific points:

• Most Ecwid stores are run by one or two people. There is no second reviewer to catch a bad write and often no team dashboard anyone opens. So approvals reach you by email with the trace attached, and the default gate is stricter than we would set on a larger store: every price write, every inventory write and every message a customer would read waits for you.
• Two sources of truth. When the Ecwid catalogue and the host page disagree about the same product, the agent reports the difference rather than picking a winner. It does not copy personal data from one to the other.

A run trace can contain personal data. On Ecwid that means order and customer fields, and the value a write replaced, end up inside the trace. That record of the replaced value is what makes a mistake reversible, and it is also why traces are treated as personal data. Trace retention is {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}.

How an app is installed and authorised, and what you are agreeing to

An Ecwid app is authorised over OAuth against one store. The merchant is shown what the app is asking for, grants it, and an access token is issued for that store. An app cannot widen its own access without sending the merchant back through a grant.

When you grant it, you are agreeing to these things:

• The app may reach every record covered by the scopes granted, not only the ones you had in mind. Scopes are granted per resource, not per product or per order.
• Ecwid records the app's writes against your store. A catalogue change an Agent makes is a change to your live catalogue.
• The scopes are written down in the build, so you can see what was granted and withdraw it. That is a commitment we make regardless of what the grant screen shows.
• Granting a scope is not the same as instructing the Agent. Price and inventory writes, and every outbound message, wait for a person by default.

{{VERIFY: what the Ecwid install and consent flow shows a merchant today, whether scopes can be granted individually or only as a set, whether tokens expire, and whether Ecwid operates an app review before an app may be listed in its app market}}

Uninstall and deletion

A merchant uninstalls an Ecwid app from the store control panel. No approval from us is involved.

What we can state

What we hold on our side is our commitment to make and does not depend on what Ecwid does: on uninstall we delete or return the data held for that store 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. Each app's own policy at /legal/apps/ states what it held.

Your own store data stays in Ecwid. Uninstalling an app does not delete products, orders or customers. Anything an Agent wrote to your catalogue while it was installed stays written unless you change it back, and the trace records the value it replaced so you can.

What has to be checked

The platform side of uninstall is exactly the kind of detail that changes, so we will not assert it:

• {{VERIFY: whether Ecwid revokes an app's access token immediately on uninstall or whether the token remains valid for a period, against the Ecwid API documentation}}
• {{VERIFY: whether Ecwid sends an application-uninstalled or equivalent webhook, what it is called today, and whether subscribing to it is mandatory for a listed app}}
• {{VERIFY: whether Ecwid requires an app to delete store data after uninstall, within what period, and whether that requirement sits in the API documentation or the app market developer agreement}}
• {{VERIFY: how long Ecwid itself retains store data after a store is closed, and its backup rotation}}

Does Ecwid have a mandatory compliance mechanism

We do not know, and we are not going to guess. Shopify publishes three mandatory compliance webhook topics that every app must implement. It would be easy to assume every platform has an equivalent, and wrong to write that assumption down as though it were checked.

• {{VERIFY: whether Ecwid operates a mandatory data-request or data-deletion callback that an app must implement, comparable to Shopify's customers/data_request, customers/redact and shop/redact. If no such mechanism exists, say so plainly here rather than leaving the section vague}}
• {{VERIFY: whether Ecwid gives merchants a built-in tool for exporting or erasing a customer's personal data from the control panel, and whether an installed app is drawn into that flow}}
• {{VERIFY: what the Ecwid or Lightspeed developer agreement requires of an app that receives a data subject request forwarded by a merchant, including any response deadline}}

Until those are confirmed, the position is: you are the controller and you answer a buyer's request. If a buyer contacts us directly, we will pass the request to you and support you in answering it. That is true whatever Ecwid turns out to require, because it follows from the roles rather than from the platform.

Where Ecwid's own policies govern, not ours

• Your agreement with Ecwid. Your use of Ecwid is governed by your contract with Ecwid, not by anything we publish, including whatever data processing terms Ecwid offers merchants.
• Ecwid as a processor of your store data. Ecwid hosts your products, orders and customers. What Ecwid itself does with them is described by Ecwid. {{VERIFY: the current URL and title of the merchant-facing privacy and data processing terms for Ecwid, and whether they are published under the Ecwid or Lightspeed name, before linking to them}}
• Cookies in the Ecwid control panel and on the embedded storefront. Ecwid sets its own cookies to keep you signed in to the control panel and to run carts and sessions on the storefront widget. Those are Ecwid's, under Ecwid's policies. {{VERIFY: which cookies the Ecwid storefront widget sets on a host page by default, since these appear on the host site's domain and affect what the host site's cookie notice must say}}
• The host site. This is the one people forget. The page your store is embedded in runs on a different platform, sets its own cookies, and is covered by its own terms. If the host is WordPress, see the WordPress annex. Our cookie policy covers this website only.
• Payments. Card handling is done by Ecwid and its payment providers under their own obligations. It is not something an app of ours touches.
• App market terms. If we list an app, the developer agreement applies to us as the developer. That is our obligation, 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.
• Ecwid agents. What we build on this platform, the API surfaces we use, and where the human approval gate sits.
• All platform annexes: Shopify, Wix, WordPress, 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 Ecwid 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 Ecwid publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.

Version history