AI Speedforce
Start a project

Shopify platform annex

What a Shopify app can reach, whose personal data that is, and what Shopify requires when a merchant uninstalls. Our per-app privacy policies at /legal/apps/ inherit this page rather than restating it.

Effective {{TODO: effective_date}} Last updated 23 August 2026 Version 0.1-draft

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 Shopify 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 Shopify 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 Shopify. See where the platform's policies govern.

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

What this platform exposes to an app

Shopify's main surface for an app is the Admin GraphQL API. An app declares access scopes, the merchant grants them at install, and the app can call nothing outside them. A second surface is webhooks, where Shopify pushes an event payload to the app when something happens in the store.

The table below lists the resources our agents work with on Shopify, taken from the surfaces named on the Shopify platform page. It is not the whole Admin API. It is the part an app of ours would ask for.

Resource or scope What it contains Includes end-customer personal data
orders Order records: line items, totals, discounts, shipping and billing addresses, the contact email and phone on the order, fulfillment and financial status. Yes. Name, address, email and phone of the shopper.
customers Customer records: name, email, phone, saved addresses, order history, tags, and the marketing consent state the merchant holds. Yes. This is the most sensitive resource on the list.
fulfillmentOrders, fulfillmentCreateV2 Which items ship from which location, carrier and tracking references, and the delivery address. Yes. Delivery addresses and tracking are personal data.
refundCreate, orderEditBegin Write operations against an existing order. The operation itself carries the order and line items it changes. Yes, by reference to the order it acts on.
products, productVariants, productUpdate Catalogue: titles, descriptions, options, prices, images, SEO fields. Normally no. It can, if a merchant has typed a person's details into a product field.
inventoryLevels Stock counts per location. No.
metafields, metafieldsSet Custom fields attached to any resource. The contents are whatever the merchant or another app decided to store there. Depends entirely on what the merchant stores. Treat as personal data unless you have checked.
Webhook topics orders/create, refunds/create, products/update Event payloads pushed to the app, mirroring the resource that changed. Yes for the order and refund topics. No for the product topic, subject to the metafield caveat above.
Shopify Flow action An alternative trigger. Whatever data the merchant's own Flow passes into the action. Depends on the Flow the merchant built. The merchant decides what it sends.
Embedded admin app (App Bridge) Session context for the staff user who has the app open, so the approval queue can show who cleared what. Staff of the merchant, not end customers.
Theme app extension A storefront-facing rendering surface, used only where an agent needs one. Most of our work stays in the admin and does not touch the theme. {{VERIFY: what buyer or cart context a theme app extension can read at runtime, against Shopify's theme app extension and Web Pixels documentation}}

Access to those resources is controlled by named access scopes. read_orders, write_orders, read_products, write_products and read_customers are the ones our Shopify work most often needs.

  • {{VERIFY: the complete and current scope name for every resource in the table above, against Shopify's Admin API access scopes reference. Scope names and their coverage change between API versions}}
  • {{VERIFY: whether reading orders older than a fixed age still requires a separate elevated scope, and what that scope is called today, against Shopify's Admin API access scopes reference}}
  • {{VERIFY: Shopify's current protected customer data requirements, including which scopes are treated as protected, what approval an app must obtain before requesting them, and what data-minimisation and retention commitments an app must make to keep that approval}}
  • {{VERIFY: what payment fields, if any, an order exposes through the Admin API, for example gateway name or card brand and last digits. Do not assert that no payment data is visible until this is confirmed}}

Personal data an app can reach, and whose it is

Almost all of the personal data reachable on Shopify belongs to the merchant's shoppers. Under the definitions we use across these documents, they are End Customers. They are not our customers, and they have no relationship with us.

Three distinct groups of people appear in the data on a Shopify store:

  • End Customers. Shoppers who placed an order, created an account, or otherwise appear on a customer record. Names, email addresses, phone numbers, shipping and billing addresses, order history, and any note a staff member wrote about them.
  • Merchant staff. The people who work in the Shopify admin. An embedded app sees which staff user is using it, which is how the approval queue records who cleared an action.
  • Suppliers and other contacts where a merchant has stored them in metafields or product fields. This is unstructured and unpredictable, which is why the table above treats metafields 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 consequences follow, and both matter more than they look:

  • A shopper's request comes to you first. If an End Customer asks about their data, the merchant is the controller and answers it. If they contact us directly, we will pass the request to the merchant and support them in answering it.
  • A run trace can contain personal data. A trace records what an Agent read and wrote. On Shopify that means order and customer fields end up inside the trace. Traces are covered by the retention set in the data processing addendum, which is currently {{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

Shopify apps come in two shapes, and the difference changes who holds what.

  • A custom app on your own store. Created inside your Shopify admin, for your store only. You choose the Admin API access scopes yourself, an access token is issued, and the app stays yours. This is the right shape for a single merchant, and it is what we build most often.
  • A public app. Distributed through the Shopify App Store and installable on stores we do not own. Worth the extra work only when the same agent has to run across many stores. A public app goes through Shopify's app review before it can be listed.

Either way, authorisation runs over OAuth. Shopify shows the merchant a permissions screen listing the access scopes the app is asking for, and the merchant grants or declines. Nothing is granted silently, and an app cannot widen its own scopes: asking for more means sending the merchant back through the grant screen.

When you approve that screen, you are agreeing to four things. We would rather say them plainly than leave them implied:

  • The app may read and write every resource covered by the scopes listed, not only the records you had in mind. Scopes are granted per resource, not per record.
  • Shopify records the app's actions as actions by that credential. A refund an Agent issues appears in your store as a refund by the app, with the app named.
  • You can revoke it. Uninstalling the app ends its access, and that is your control, not ours. See uninstall and deletion.
  • Granting the scope is not the same as instructing the Agent. What the Agent is allowed to do with a scope, and which writes wait for a person, is set in the configuration we agree with you in writing. By default, write actions wait for a person.

{{VERIFY: whether Shopify still requires a public app to be embedded and to use session tokens rather than cookies, and what the current App Store review requirements are for scope justification, against Shopify's app requirements documentation}}

Uninstall and deletion

A merchant uninstalls a Shopify app from the store admin, in the apps section of settings. No approval from us is involved and none is needed.

What happens to access

Uninstalling revokes the app's access token for that shop. The app can no longer call the Admin GraphQL API for that store. There is no grace period during which we could still read your records, because the credential itself stops working.

Shopify also sends an app/uninstalled webhook to the app, which is how the app learns it has been removed rather than discovering it on the next failed call.

What happens to data the app already holds

Uninstalling does not by itself reach into our systems. Anything an app copied out of Shopify before the uninstall, including run traces, still sits where it was written until it is deleted. That is the part the platform cannot do for you and the part we have to commit to.

Our commitment is that 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 that app held in the first place.

What happens inside Shopify

Your orders, customers and products stay in your store. Uninstalling an app does not delete store records. Anything an Agent wrote to your store while it was installed, a metafield, an order note, a fulfillment, stays written unless you remove it.

{{VERIFY: whether Shopify still permits an uninstalled app to be reinstalled with the same shop data, and whether any app-owned resource such as a metafield definition or theme app extension block is removed automatically on uninstall, against Shopify's app uninstall documentation}}

Shopify's mandatory compliance webhooks

Shopify has a mandatory mechanism, and it is the strictest of the six platforms covered by these annexes. Shopify defines three mandatory compliance webhook topics that an app receives:

TopicWhat it meansWhat the app has to do
customers/data_request A shopper has asked the merchant for the data an app holds about them, and the merchant has passed the request on. Return the data the app holds about that customer, to the merchant, so the merchant can answer their shopper.
customers/redact A merchant has asked that an app erase the data it holds about a specific customer. Erase the data held about that customer.
shop/redact A shop has uninstalled the app and Shopify is asking the app to erase the data it holds for that shop. Erase the shop's data.

These three topics, and what each one is for, are stable and we state them as fact. The operational detail around them is not something we will assert from memory:

  • {{VERIFY: how long after uninstall Shopify sends shop/redact, and how long after a merchant request it sends customers/redact, against Shopify's privacy law compliance documentation. Do not publish a number until it is confirmed}}
  • {{VERIFY: the deadline for responding to a compliance webhook, the required HTTP response, and the HMAC verification an app must perform, against Shopify's webhook documentation}}
  • {{VERIFY: whether all three topics are mandatory for custom apps as well as public App Store apps, and what happens to a listing that fails to respond, against Shopify's app requirements}}
  • {{VERIFY: whether Shopify sets any minimum data-retention or minimum-erasure standard an app must meet in response to customers/redact, as opposed to leaving the standard to the app}}

Where an app of ours holds Shopify data, its policy at /legal/apps/ states which endpoint answers each of these three topics and what it erases. If an app holds no Shopify data at all, its policy says that too, because a redact request against nothing is still a request that has to be answered.

Where Shopify's own policies govern, not ours

There are parts of a Shopify store where we are not in the picture at all, and it would be misleading for this annex to imply otherwise.

  • Your agreement with Shopify. Your use of Shopify is governed by your contract with Shopify, not by anything we publish. That includes their terms of service, their acceptable use policy, and the data processing terms Shopify offers merchants.
  • Shopify as a processor of your store data. Shopify hosts your orders and customers. What Shopify itself does with them is described by Shopify, and we do not restate it. {{VERIFY: the current URL and title of Shopify's merchant-facing privacy and data processing terms before linking to them}}
  • Cookies inside the Shopify admin. Shopify sets its own cookies in the admin to keep you signed in and to run the admin interface. Those are Shopify's, set under Shopify's policies. Our embedded approval queue runs inside that admin, and it does not add cookies of its own. {{VERIFY: that an embedded app using App Bridge and session tokens sets no cookies of its own under the current App Bridge version}}
  • Storefront cookies and tracking. Anything your storefront sets for carts, sessions, analytics or advertising is between you, Shopify and the apps you have installed. Our cookie policy covers this website only.
  • Payments. Card handling is done by Shopify and its payment providers under their own compliance obligations. It is not something an app of ours touches.
  • App Store listing terms. If we distribute a public app, Shopify's partner and app store terms apply to us as the developer. Those are our obligation to Shopify, not a term of your agreement with us.

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 Shopify 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 Shopify publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.

Version history

VersionDateChange
0.1-draft{{TODO: effective_date}} First published draft. Not yet reviewed by counsel.
AI Speedforce
Start a project