BigCommerce platform annex

What this annex covers

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

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

BigCommerce stores run wide: long catalogues with variants and modifiers, several sales channels, and prices that change by customer group. The privacy consequence is scale. The same read that returns one order on a small store returns tens of thousands here, so the question of how much personal data an app pulls at once matters more on this platform than on any other in this set.

What this platform exposes to an app

The working surfaces are the Catalog API v3, Price Lists V3, Channels and the Orders API v2. Webhooks push store events so a run starts when the store changes rather than on a timer. Access is granted as scopes on an API account or on an installed app.

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

Scope names are exactly the kind of detail we will not write from memory:

• {{VERIFY: the exact current OAuth scope names BigCommerce uses for products, orders, customers, price lists, channels and store information, against the BigCommerce API accounts and scopes documentation. Never publish a scope name that has not been read off the current reference}}
• {{VERIFY: whether BigCommerce separates read-only from modify scopes per resource, and whether any scope covering customer or order data requires additional approval before an app may request it}}
• {{VERIFY: whether Orders is still a v2 API and Catalog still v3 for the operations listed above, and whether a newer version has superseded either, against the BigCommerce API reference}}
• {{VERIFY: the current webhook scope names, whether the two named above are still current, and how long BigCommerce retains an undelivered webhook before dropping it}}

Personal data an app can reach, and whose it is

The personal data on a BigCommerce store belongs to the merchant's shoppers and, on a B2B store, to the named people at its trade customers. Under the definitions we use across these documents they are End Customers. They are not our customers.

• End Customers. Shoppers who placed an order or hold an account. Name, email, phone, billing and shipping address, order history, customer group membership.
• Buyers at trade accounts. On B2B stores a customer record is a person at a company. The company is not personal data, the person is, and price list work touches both.
• Merchant staff. Control panel users, and whoever approves a batch in the queue.

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.

The scale point is worth being concrete about, because it is where a large store differs from a small one:

• Bulk writes are staged, not streamed. The agent prepares the whole change set, reports the record count and a sample diff, and waits. A person approves the batch rather than each row. Nothing has been written to your store at the point you are asked.
• A sample diff is a sample of your data. Where a batch touches order or customer records, the sample shown in the approval, and the copy of it in the run trace, contains personal data. We keep the sample as small as it can be and still let you judge the run. Trace retention is {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}.
• Catalogue work needs no customer scope. A merchandising or enrichment agent reads products, variants and categories, and is not granted access to orders or customers at all. On a platform this size, that separation is the main thing keeping the blast radius small.

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

BigCommerce access comes in two shapes, and the difference matters for who holds the credential.

• A store API account. Created by the merchant in the store control panel, with the scopes chosen at creation. The credentials belong to the merchant, and the merchant can revoke them without involving anyone else. For a single store, this is usually the right shape.
• A marketplace app. Installed from the app marketplace, authorised over OAuth, with the requested scopes shown to the merchant before the install completes. Worth the extra work when the same agent has to install across stores we do not own.

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

• The credential may reach every record covered by the scopes granted, not only the ones you had in mind. A scope that covers orders covers all of them, including historic ones.
• BigCommerce records the writes against your store. A price list change or a category reassignment an Agent makes is a real change to your live store.
• You can revoke it. Deleting the API account, or uninstalling the app, ends the access. See uninstall and deletion.
• Granting a scope is not the same as instructing the Agent. Every price list change waits for a person, without exception and regardless of size, and any write touching more than the record count you set waits too.

{{VERIFY: what callback endpoints a BigCommerce single-click marketplace app is required to implement, believed to include auth, load and uninstall callbacks and possibly a remove-user callback, against the current BigCommerce app development documentation}}

{{VERIFY: whether BigCommerce operates an app review before an app may be listed in its marketplace, and what it examines in relation to data handling and scope justification}}

Uninstall and deletion

A store API account

The merchant deletes the API account in the control panel and the token stops working. Nothing about that depends on us, and it is the fastest way to cut access if you ever need to.

A marketplace app

The merchant uninstalls from the apps area of the control panel. What BigCommerce does at that moment is something to confirm rather than assert:

• {{VERIFY: whether BigCommerce revokes an app's access token immediately on uninstall, against the BigCommerce app development documentation}}
• {{VERIFY: whether the uninstall callback is mandatory for a listed app, what BigCommerce sends to it, and what an app is required to do in response}}
• {{VERIFY: whether BigCommerce requires an app to delete store data after uninstall, within what period, and where that requirement is published}}
• {{VERIFY: how long BigCommerce itself retains store data after a store is closed or a trial lapses, and its backup rotation}}

What we commit to

Whichever shape the access took, 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. On a store this size that includes any staged change set still waiting for approval, which is deleted unrun rather than left in a queue.

Your own store data stays in BigCommerce. Uninstalling does not delete products, orders or customers, and it does not roll back a batch that was already approved and written. The trace records what changed and why, which is what makes a reversal possible.

Does BigCommerce have a mandatory compliance mechanism

We do not know, and this page is not the place to guess. Shopify publishes three mandatory compliance webhook topics that every app must implement. BigCommerce may require something similar, something different, or nothing at all, and each of those would need writing differently.

• {{VERIFY: whether BigCommerce operates a mandatory data-request or data-deletion callback that a marketplace app must implement, comparable to Shopify's customers/data_request, customers/redact and shop/redact. If no such mechanism exists, say so plainly here}}
• {{VERIFY: whether the BigCommerce remove-user or uninstall callbacks carry any deletion obligation, as opposed to being purely notifications}}
• {{VERIFY: whether BigCommerce 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 BigCommerce partner or app marketplace agreement requires of an app that receives a data subject request forwarded by a merchant, including any response deadline}}

Until those are confirmed: you are the controller and you answer a shopper's request. If a shopper contacts us directly, we will pass the request to you and support you in answering it.

Where BigCommerce's own policies govern, not ours

• Your agreement with BigCommerce. Your use of the platform is governed by your contract with BigCommerce, not by anything we publish, including whatever data processing terms BigCommerce offers merchants.
• BigCommerce as a processor of your store data. BigCommerce hosts your catalogue, orders and customers. What BigCommerce itself does with them is described by BigCommerce. {{VERIFY: the current URL and title of BigCommerce's merchant-facing privacy and data processing terms before linking to them}}
• Cookies in the control panel and on your storefronts. BigCommerce sets its own cookies to keep you signed in and to run carts and sessions on the storefront. Those are BigCommerce's, under BigCommerce's policies. Our cookie policy covers this website only.
• Other sales channels. Orders arriving from a marketplace or social channel were created under that channel's own terms and privacy policy before they reached your store. That relationship is between you and the channel.
• Payments. Card handling is done by BigCommerce and your payment providers under their own obligations. It is not something an app of ours touches.
• Marketplace terms. If we list an app, the partner 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.
• BigCommerce 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, Ecwid, HighLevel.
• 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 BigCommerce 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 BigCommerce publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.

Version history