1. Why compliance matters
Compliance is where most Shopify apps fail — and it's the part that's easiest to get wrong if you're not building specifically for Shopify. There are two distinct reasons it matters: App Store review and legal liability.
App Store review
Shopify's review process checks compliance rigorously. Missing GDPR webhooks, an inaccessible privacy policy, or improper data handling means rejection — you can't list your app until it's fixed. The single most common rejection reason across all Shopify apps is missing or broken GDPR webhook endpoints. Apps built with generic AI tools fail here repeatedly because those tools don't generate Shopify's specific compliance requirements.
Legal liability
Beyond Shopify's rules, you're handling real people's personal data, which is governed by GDPR (EU), CCPA (California), and similar regulations worldwide. Non-compliance carries genuine legal and financial risk independent of Shopify — regulatory fines under GDPR can be substantial. Compliance isn't just a hoop to jump through for listing; it's a legal obligation when you process customer data.
Tools like Lovable and Base44 generate web apps that look functional but omit Shopify's compliance requirements entirely — no GDPR webhooks, no data deletion handling, no per-merchant isolation. Apps built this way fail review and, if somehow deployed, create real legal exposure. Shopify-specific generation includes these requirements by default, which is a major reason it passes review where generic tools don't.
2. The three mandatory GDPR webhooks
Every Shopify app — without exception — must register and respond to three GDPR webhook topics. Shopify sends these webhooks when merchants or their customers exercise data rights. Each must verify the webhook HMAC and return a 200 status.
customers/redact
Sent when a store owner requests deletion of a specific customer's personal data (for example, when that customer invokes their right to be forgotten). Your app must delete all personal data it holds about that customer. Return a 200 immediately to acknowledge, then process the deletion. If you don't store customer data, acknowledge and return 200 anyway — the endpoint must exist.
shop/redact
Sent 48 hours after a store uninstalls your app. Your app must delete all data associated with that store — every record tied to that shop domain. This is both a compliance requirement and good hygiene: you shouldn't retain data for stores that no longer use your app. The 48-hour delay gives merchants a grace period in case they reinstall.
customers/data_request
Sent when a customer requests a copy of the personal data a store holds about them. Your app must compile and provide the personal data it stores about that customer, so the merchant can fulfill the customer's data access request. Return a 200 to acknowledge, then make the data available to the merchant.
| Webhook | Triggered when | You must |
|---|---|---|
customers/redact | Customer data deletion requested | Delete that customer's data |
shop/redact | 48h after store uninstalls | Delete all that store's data |
customers/data_request | Customer requests their data | Provide the data you hold |
All three must verify the request's HMAC signature using your app secret before acting, and return a 200 status within Shopify's timeout. Reviewers explicitly test that these are registered and respond correctly — this is the compliance check most apps fail.
3. Protected customer data
Shopify classifies personal information about a store's customers — names, email addresses, physical addresses, phone numbers, order history — as protected customer data, and gates access to it.
Requesting access
If your app needs access to protected customer data, you must request it and complete Shopify's data protection requirements, which include a questionnaire about why you need the data, how you'll use it, and how you'll protect it. Shopify reviews these requests. Apps that request protected customer data face additional scrutiny.
Request only what you need
The guiding principle is data minimization: request access only to the protected customer data your app genuinely needs for its core function. An app that displays product reviews doesn't need customers' physical addresses. Over-requesting data access raises review scrutiny, increases your compliance burden, and creates unnecessary legal exposure. Scope your data access tightly.
Handling requirements
If you do access protected customer data, you're subject to stricter handling requirements: encryption, access controls, retention limits, and the ability to delete it on request (via the GDPR webhooks). Treat protected customer data as a liability to minimize, not an asset to accumulate.
4. Privacy policy requirements
A live, accessible privacy policy is required for App Store listing and verified during review. It's not a formality — it's a legal document that must accurately describe your data practices.
What it must cover
- What data you collect: Be specific — merchant data, customer personal data, usage analytics, etc.
- How you use it: The purposes for which you process each type of data.
- How you store and secure it: Where data lives, how it's protected (encryption, access controls).
- Third-party sharing: Any services you share data with (hosting, analytics, email providers).
- Data rights: How merchants and customers can request access to or deletion of their data.
- Retention: How long you keep data and what happens when an app is uninstalled.
- Contact: How to reach you with privacy questions.
It must be accurate
Your privacy policy must reflect what your app actually does. A boilerplate policy that claims practices you don't follow is both a review risk and a legal liability. If your app stores customer emails in a PostgreSQL database hosted on Railway, your privacy policy should say so. Accuracy protects you legally and builds merchant trust.
A surprising number of submissions are rejected because the privacy policy URL returns a 404 or a placeholder page. Before submitting, open your privacy policy URL in an incognito window and confirm it loads a real, complete policy. This is a trivial check that prevents a multi-day rejection cycle.
5. Data handling and storage
How you store and manage data is both a compliance requirement and an architectural concern. The core principles:
Per-merchant data isolation
Your app serves many stores from one codebase. Every piece of data must be scoped to the store it belongs to, and every query must filter by the requesting store's shop domain. Returning one merchant's data to another is a critical security and compliance failure. This isolation must be enforced at the data layer — it's not optional. Generic AI tools generate single-tenant architecture by default and miss this entirely; Shopify-specific generators scope by shop throughout.
Data minimization
Store only the data your app needs to function. Every piece of personal data you store is a liability — it must be secured, it's subject to deletion requests, and it increases your exposure in a breach. If you can accomplish your app's function without storing a piece of personal data, don't store it.
Deletion capability
You must be able to delete data on request — both individual customer data (customers/redact) and entire store data (shop/redact). Design your data model so deletion is clean: when you delete a store's data, every related record across every table should be removed. Orphaned personal data after a deletion request is a compliance violation.
Retention
Don't keep data indefinitely. Delete store data after uninstall (the shop/redact webhook drives this). Consider retention limits on logs and analytics that contain personal data. Define a retention policy and enforce it.
6. Security requirements
Shopify expects apps to follow security best practices, and security failures can fail review or, worse, cause breaches with legal consequences.
HMAC verification everywhere
Every request from Shopify — the OAuth callback, every webhook — includes an HMAC signature you must verify using your app secret before acting on it. Skipping HMAC verification means an attacker could forge requests to your app. This is non-negotiable and is checked in review.
Secure credential storage
Store access tokens, API secrets, and any sensitive credentials securely — never in client-side code, never in your repository, always in environment variables or a secrets manager. Per-merchant access tokens must be stored encrypted and scoped to their store.
HTTPS only
Your app must be served over HTTPS. Shopify requires it, and OAuth and webhook delivery depend on it. Any host you deploy to (Railway, Fly, your own server) must have a valid TLS certificate.
Session security
Use Shopify session tokens (via App Bridge) for authenticating embedded app requests. Don't roll your own insecure session scheme. Session tokens are short-lived and verified, which is what keeps embedded apps secure inside the Shopify admin.
Least-privilege scopes
Request only the API scopes your app actually uses. Each scope you request is access you're responsible for protecting. Over-requesting scopes increases both your security surface and review scrutiny.
7. App Store policy rules
Beyond technical compliance, Shopify has policy requirements that govern app behavior. Violating these can block listing or get a live app removed:
- No misleading functionality: Your app must do what your listing claims. Screenshots and descriptions must reflect actual behavior.
- No prohibited categories: Shopify prohibits certain app types and content. Review the current App Store requirements before building in a sensitive category.
- Honest reviews only: Never incentivize, fake, or manipulate reviews. This can get your app removed and your Partner account penalized.
- Proper billing: Charge through the Shopify Billing API, not external processors, for App Store apps. Your listed pricing must match your actual charges.
- No interfering with Shopify or other apps: Your app must not break the merchant's store, the Shopify admin, or other installed apps.
- Respect merchant data: Use merchant and customer data only for the purpose the merchant installed your app for. Don't repurpose it.
Shopify periodically updates its App Store requirements. Before submitting — and periodically after listing — review the current official requirements to ensure your app remains compliant as policies evolve.
8. Compliance checklist
Run through this before every submission:
- All three GDPR webhooks (
customers/redact,shop/redact,customers/data_request) registered and returning 200 - Webhook HMAC verification on every incoming webhook
- OAuth callback HMAC verification
- Privacy policy live at the URL you provided (test in incognito)
- Privacy policy accurately describes your data practices
- Protected customer data requested only if genuinely needed, with data protection requirements completed
- Per-merchant data isolation enforced on every query
- Access tokens and secrets stored securely (env vars / secrets manager, not in code)
- App served over HTTPS with valid TLS
- Only least-privilege API scopes requested
- Store data deletion is clean (no orphaned records after
shop/redact) - Listing accurately reflects actual app functionality
- Billing through Shopify Billing API, matching listed pricing
The cheapest time to handle compliance is when the app is built, not bolted on before submission. If you generate your app with a Shopify-specific builder like Shopivibe, the GDPR webhooks, HMAC verification, and per-merchant isolation are generated correctly from the start. You still own the privacy policy and protected-data decisions, but the technical foundations — the parts most commonly missed — are handled.