App submission checklist. Ship-ready.
Everything Shopify checks when you submit an app: privacy webhooks, billing integration, listing copy, screenshots, Polaris compliance, and the extra Built for Shopify requirements.
Fifteen items, one submission.
A Shopify app submission in 2026 requires: three working GDPR privacy webhooks (customers/data_request, customers/redact, shop/redact), a billing integration using Shopify's GraphQL billing API, listing copy across five fields (tagline, value prop, features, how it works, pricing), four to seven screenshots showing real merchant data, and Polaris design compliance on all embedded admin UI. Standard review takes 2 to 4 weeks; Built for Shopify review adds 2 to 4 weeks with extra performance, accessibility, and integration-depth requirements. Most first-time submissions fail on one of three items: missing or non-functional privacy webhooks, unclear billing flow, or stock-photo-style screenshots instead of real product views. Resubmissions add 1 to 2 weeks each. Plan a 6-week calendar between code-complete and launch for a first-time public app.
Three webhooks, all must work.
Shopify's three mandatory privacy webhooks implement merchant-level and customer-level data deletion rights under GDPR, UK GDPR, and the US state laws that mirror them. Every public app must register endpoints for all three in the partner dashboard. The review team tests them in every review; the most common first-time submission failure is a webhook endpoint that returns 200 OK without actually doing anything.
customers/data_request fires when a merchant requests a customer's data on behalf of that customer (a GDPR Subject Access Request). Your app has 30 days to compile the data and deliver it to the merchant. The webhook payload includes the customer email; your app should reply with 200 OK to acknowledge receipt, then run its data-export process asynchronously. customers/redact fires when a merchant requests deletion of a customer's data; your app must purge all data related to that customer within 30 days. shop/redact fires when the merchant uninstalls the app and has waited out the 48-hour grace period; your app must purge all store data at this point.
The implementation pattern: each webhook has a shared HMAC verification step (Shopify signs the payload with a shared secret; your endpoint validates the signature before processing), then branches by topic to the appropriate handler. Log every call with the incoming payload and your processing outcome; during review, Shopify expects evidence that the webhooks work. See Shopify's mandatory webhooks documentation for the exact payload schemas and HMAC validation.
Shopify billing, not Stripe.
Public Shopify apps must bill through Shopify's billing API, not through Stripe or a custom invoice system. The billing API charges merchants on their existing Shopify invoice and gives the developer 85 percent revenue share (80 percent above 1 million annual, 100 percent under 1 million with some caveats on promotional periods). The merchant sees the charge on their next Shopify invoice; the developer receives a monthly payout from Shopify.
The GraphQL mutations to know: appSubscriptionCreate creates a recurring subscription charge (monthly or annual); appUsageRecordCreate adds a usage-based charge on top of a subscription for metered features; appSubscriptionCancel cancels a subscription cleanly on merchant uninstall. Test all three in a development store before submitting; dev stores do not actually charge but do run the full approval flow, which is what the review team tests.
The merchant approval flow: merchant clicks install, your app loads, your app calls appSubscriptionCreate with a return URL, Shopify shows the merchant a charge-approval screen with your app's pricing details, merchant approves, Shopify redirects back to your app's return URL with a charge_id and status. Your app confirms the status, activates the subscription, and the merchant is live. Any deviation from this flow is a review rejection: charging before approval, no pricing shown, silent upgrades to higher tiers. The review team tests the full flow on every submission.
Five fields, specific expectations.
The tagline is 70 characters maximum and should say exactly what the app does. "Automated email for abandoned carts" works. "Revolutionize your marketing with AI-powered automation" does not (no specific benefit, marketing jargon, Shopify rejects). The value proposition is 500 characters and expands the tagline with concrete outcomes: "Recover 30 percent of abandoned carts with automated email sequences triggered by Shopify's abandoned_checkout webhook. 15-minute setup, no template design required." Specific, measurable, no fluff.
The features section lists 3 to 8 capabilities with a short description each. Ideal feature copy: a verb-first noun phrase ("Segment customers by lifetime value") plus a 1-sentence explanation of what it does for the merchant. Avoid feature lists that read like engineering tickets ("Advanced segmentation engine with real-time updates"); merchants want to know what the feature does for their business, not how it is implemented.
The pricing section is the part most often rejected. Shopify requires complete transparency: every tier, every charge trigger, every usage limit. If your app charges based on usage, show worked examples (e.g., "1,000 emails sent = $10; 10,000 emails = $80"). Hidden fees, usage caps buried in fine print, and unclear free-trial terms all cause rejection. If your pricing is genuinely complex (per-order charges with volume discounts), explain it in plain English with examples in the listing; do not rely on merchants figuring it out on the approval screen.
Four to seven, real data.
Shopify requires four to seven screenshots at 1600x900 PNG. The first three are shown in the app listing preview; the rest live on the app's detail page. Order matters: put the most visually compelling and self-explanatory screenshot first. A common ordering: main admin UI with realistic merchant data (screen 1), a secondary feature that differentiates the app (screen 2), the customer-facing output (the storefront widget, the email it sends, the checkout enhancement - screen 3), then secondary screens (settings, reports, integrations) filling out the remaining slots.
What Shopify rejects: stock photos, illustrations instead of actual UI, empty-state screens (a dashboard with no data), marketing banners around the UI (the screenshot should show the UI itself, not a product page wrapped around it), and screenshots with obvious test data ("Test Store", "Lorem ipsum"). Real data does not mean live merchant data; it means realistic fake data that demonstrates what a working install looks like. Most apps set up a polished dev-store fixture with representative products, orders, and customers specifically for screenshot capture.
Built for Shopify adds screenshot-quality requirements. BfS apps need screenshots that show native Polaris UI (not custom-styled variants), consistent color and typography across all screens, and clear visual hierarchy. The BfS review examines screenshots for design polish in addition to the functional quality check that standard review does.
Six extras, worth it for competitive categories.
Built for Shopify is the premium tier in the app store. BfS apps get a green badge, priority ranking in search results, and higher merchant trust. The six extra requirements: performance (admin UI loads in under 1 second on simulated 3G), accessibility (WCAG 2.1 AA with screen-reader testing), Polaris adoption (full use of Shopify's design system), deep integration (use of metafields, metaobjects, bulk operations, Functions where relevant), clean offboarding (data portability on uninstall, no orphaned data), and support SLA (24-hour first-response documented in the listing).
Is BfS worth pursuing? For apps in competitive categories (email marketing, reviews, upsells, loyalty) where ten or more similar apps compete in the same category, yes. The badge and ranking lift measurably improve install rates; the polish required to earn BfS also improves the product itself. For niche-category apps (specific industry, specific merchant size) where you are one of two or three competitors, skip BfS for v1 and earn it after the app has traction. The extra 2 to 4 weeks of prep work is real, and spending that time on product features for an uncompetitive niche returns less than earning BfS later when a real competitor shows up.
For the broader app-development context, see our public vs custom app decision guide and GraphQL Admin API migration guide. The submission checklist assumes you have chosen the public-app path and built on GraphQL.
Six answers.
What are the required privacy webhooks for a Shopify app?
Three mandatory GDPR-compliance webhooks. One, customers/data_request: when a merchant requests a customer's data on the customer's behalf, your app has 30 days to provide the data. Two, customers/redact: when a merchant requests deletion of a customer's data, your app must purge it within 30 days. Three, shop/redact: when a merchant uninstalls and requests deletion, your app must purge all store data within 48 hours. Missing or non-functional privacy webhooks is the most common reason for first-time submission rejection; Shopify's review team tests these in every review.
What does Shopify require for app listing copy?
Five pieces. A tagline (70 characters max) that describes what the app does in one sentence. A value proposition (500 characters max) that expands on the tagline with benefit-oriented copy, not feature lists. A features section listing 3 to 8 named capabilities. A how-it-works section explaining the merchant setup flow. A pricing explanation that clearly states tier names, what is included in each, and what triggers charges. Shopify rejects listings with unclear pricing (hidden fees, unclear usage-based charges), marketing jargon without specific benefits, or claims that cannot be verified during review.
How many screenshots do I need and what should they show?
Four to seven screenshots, 1600x900 pixels, PNG format. The first three are the most important: they show up in the app listing preview. Order them: screen 1 shows the app's main admin UI with typical merchant data (not empty state). Screen 2 shows a secondary but important feature. Screen 3 shows the customer-facing output of the app (the storefront widget, the email it sends, the checkout enhancement). Later screenshots can show settings, integrations, and secondary flows. Avoid stock photos, marketing screenshots, and empty states; Shopify wants to see the actual working app.
What is Shopify's Polaris design system and is it required?
Polaris is Shopify's design system for admin-embedded UI. Apps that embed in the Shopify admin must use Polaris components (buttons, cards, forms, banners) or have strong visual reason to deviate. Polaris compliance is enforced in Built for Shopify review and checked casually in standard review. For public apps targeting BfS, use the React Polaris library maintained by Shopify; for custom apps or standard public apps, Polaris is recommended but not strictly enforced. Deviations that consistently fail review: custom styling on Polaris components, mixed design systems within a single screen, obvious non-Polaris widgets mixed with Polaris ones.
How do I integrate Shopify's billing API correctly?
Use the GraphQL appSubscriptionCreate mutation for recurring charges and appUsageRecordCreate for usage-based billing. Test both in development stores (charges are not captured in dev) before submitting. Shopify's review team tests the full billing flow: new merchant installs, sees the charge approval screen, approves the charge, and your app grants access. Common rejections: charging before merchant approves, charging without showing a clear pricing explanation on the approval screen, not handling charge-declined edge cases, using a non-Shopify billing system (Stripe Connect, custom invoices) for subscriptions that should go through Shopify billing.
What triggers Built for Shopify additional review?
Built for Shopify has six extra requirements beyond standard app review. One, performance: admin UI must load in under 1 second on a simulated 3G connection. Two, accessibility: WCAG 2.1 AA compliance, tested with screen readers. Three, Polaris adoption: full use of the Polaris design system across every screen. Four, deep Shopify integration: use of relevant Shopify-native features (metafields, metaobjects, bulk operations) rather than workarounds. Five, post-purchase experience: smooth uninstall handling, data portability, clean offboarding. Six, merchant support quality: 24-hour first-response SLA, documented in the app listing. The extra review adds 2 to 4 weeks on top of standard review.
Approval is a checklist.
Our Shopify app development engagements include full submission prep: privacy webhooks, billing integration, listing copy, screenshots, Polaris audit, and BfS prep. Scoped quote in 48 hours.