Shopify, Meta and Google App Review: A Field Guide to Approval

Every platform's app review checks the same three things. Are you a real business? Do you only ask for the permissions you actually use? Can a reviewer see each permission being used in a working app? If you have a live website and privacy policy, a short permission list with one sentence of justification per permission, a narrated screencast and working test credentials ready before you submit, most rejections never happen.

I've taken apps through review on Shopify, Meta, Google and TikTok, for our own products and for clients. The platforms word things differently, but the reviewers want the same evidence. This guide covers what's common, then each platform's specifics.

The three things every reviewer checks

1. You're a real business

Reviewers want to know someone accountable is behind the app. What they look at:

• A live website on your own domain, with your company name on it and matching the name on the app. No placeholder sites, no example.com.
• A privacy policy at a public URL on that domain. It should say what data you collect from the platform, why, how long you keep it and how to delete it.
• A real contact email, ideally on the same domain.
• Business verification where the platform has it. Meta has business verification. Google has brand verification for OAuth apps, which is now also required for Basic Google Ads API access.

2. You only ask for what you use

This is the most common rejection reason I see, on every platform. My rule from the TikTok access video: don't select all and hope.

For every permission or scope, write one sentence: "We use X to do Y, which the user sees on screen Z." If you can't write the sentence, remove the permission. You can add scopes later as you build features.

3. The reviewer can see it working

Reviewers don't read your code. They watch your screencast and click through your app. So:

• A narrated screencast, in English or with English subtitles. Start logged out, install or log in, go through OAuth, and show each permission being used. Say out loud what's happening.
• Test credentials that work. If your app needs a login, give the reviewer one with full access. If it needs an ad account with data, make sure it has data.
• A deployed app on HTTPS. Reviewers can't reach your localhost.

Before you submit: the shared checklist

• Live website, company name matches the app
• Privacy policy URL and terms of service URL on your domain
• App name, icon and description that say what it does
• Permission list with one justification sentence each
• App deployed on HTTPS with the production redirect URLs registered
• Narrated screencast covering install/login → OAuth → each permission
• Test account and credentials for the reviewer
• App registered in your company's name, not a contractor's

Shopify: getting a public app into the App Store

Shopify's review is the most hands-on. A reviewer installs your app on a test store and tries it. These are the requirements I check first, from Shopify's app requirements checklist.

Installation and authentication

• OAuth comes first. When a merchant installs, your app must authenticate before anything else happens. That includes merchants who installed, uninstalled and are now reinstalling. A splash page or a signup form before OAuth fails review.
• After OAuth, go straight to the app UI. Don't drop merchants on a blank page.
• Embedded apps use session tokens, not third-party cookies or local storage, and use App Bridge for redirects and the admin integration.

Compliance webhooks

Every public app must subscribe to Shopify's three mandatory privacy webhooks and handle them:

• customers/data_request: a customer asked what data you hold.
• customers/redact: delete a customer's data.
• shop/redact: delete a shop's data after it uninstalls.

Respond with a 200 and actually do the work. You also need to verify the HMAC on every webhook:

import base64, hashlib, hmac

def verify_shopify_webhook(raw_body: bytes, hmac_header: str, api_secret: str) -> bool:
    digest = hmac.new(api_secret.encode(), raw_body, hashlib.sha256).digest()
    computed = base64.b64encode(digest).decode()
    return hmac.compare_digest(computed, hmac_header)

# In your handler: verify with the raw request body and the
# X-Shopify-Hmac-Sha256 header *before* parsing JSON. Return 401 if it fails.

Billing

If you charge, charge through Shopify's billing (the Billing API or managed pricing). Merchants must be able to upgrade or downgrade without contacting support or reinstalling. Sending merchants to Stripe for an App Store app is a rejection.

APIs and data

• Build new public apps on the GraphQL Admin API. Shopify treats REST Admin as legacy.
• Protected customer data: if you read customer names, emails, addresses or phone numbers, request protected customer data access in the Partner Dashboard and explain why, field by field. Request only what you use.

Performance

Your app must not lower the storefront's Lighthouse performance score by more than 10 points. Shopify weights the home page, product pages and collection pages. Load theme app extension scripts deferred and keep them small.

The listing

• App icon: 1200 × 1200 px, JPEG or PNG, no text, no screenshots, no Shopify trademarks.
• Feature media and screenshots: 1600 × 900 px. Three to six desktop screenshots.
• Screencast: the complete setup and main features, in English or with English subtitles.
• Test credentials for any third-party platform your app connects to, with full access.
• A description that matches what the app does. Don't list features you haven't built.

Custom apps skip all of this

If the app is only for one merchant, or a store your agency manages, make it a custom app instead. It doesn't go through App Store review. Many agency tools should be custom apps.

Meta: App Review for the Marketing API

For an ads tool, Meta's review is mostly about advanced access to permissions.

Standard vs advanced access

Your app starts with standard access. With standard access, permissions like ads_management only work for ad accounts that people with a role on your app can access. That's fine for internal tools on your own business's accounts. Combined with a non-expiring system-user token, it's often all an agency needs.

To let other businesses, meaning your clients, connect their own accounts to your app, you need advanced access, which goes through App Review.

What to request

For a typical agency ads tool:

• ads_read: reading insights for reporting.
• ads_management: creating and editing campaigns. Only request it if your tool writes.
• business_management: only if you work with Business Manager assets, like listing a client's ad accounts through their business.
• Ads Management Standard Access: a feature, not a permission, that raises your Marketing API rate limits. Request it once you have real usage.

What to prepare

1. Business verification in Meta Business Settings. Have your legal company name, address and a document that matches them.
2. App settings: privacy policy URL, app icon, category and a data deletion instructions URL.
3. Per-permission use description: what you do with it and where in your app a user sees that.
4. A screencast per permission, or one that covers all of them. Show a user logging in with Facebook Login for Business, choosing their assets, and then the feature that uses each permission. For ads_read, show your report with their data. For ads_management, show a campaign being created or edited, and show it in Ads Manager after.
5. Reviewer access: a test user or instructions for logging in, with an ad account that has data.

After approval

Meta asks app admins to complete an annual Data Use Checkup, confirming your use of each permission still matches what was approved. Miss it and you can lose access. Put it on a calendar.

Google: OAuth verification and Google Ads API access

Google has two separate reviews for an ads tool, and people mix them up.

Review 1: OAuth app verification

The Google Ads scope, https://www.googleapis.com/auth/adwords, is a sensitive scope. While your consent screen is in Testing, only listed test users can connect, and their refresh tokens expire after 7 days. To let clients connect and keep tokens long-term, publish the app. That triggers verification.

What Google wants:

• A verified domain. Your homepage, privacy policy and redirect URIs must be on domains you've verified in Google Search Console.
• Branding. App name and logo that match your website. The homepage must explain what the app does.
• A privacy policy that says how you use Google user data, including the Google Ads data.
• A scope justification: why you need adwords, in a sentence or two.
• A demo video, usually an unlisted YouTube link. Show the OAuth flow with the consent screen visible, including the browser URL bar with your client ID, then the feature that uses Google Ads data.

Review 2: Google Ads API access level

This changed on September 9, 2026. Google retired developer tokens. Access levels (Test, Explorer, Basic, Standard) now belong to the Google Cloud project that owns your OAuth client, and you apply on the Google Ads API Overview page in the Cloud Console.

• Explorer gives you production access with a lower daily limit, usually approved automatically.
• Basic requires brand verification of the Cloud project first. Google then reviews it automatically, within minutes.
• Standard is a manual audit against Google's Required Minimum Functionality.

The full walkthrough, including the errors you'll hit, is in the complete Google Ads API access guide.

One thing from my old Basic-access video still holds: describe a real business and a specific use case, on a live website. Google wants to know you won't abuse the API.

TikTok, briefly

TikTok's developer app review is the most straightforward of the four. Complete your developer profile with a real company and a live website that matches it. Register an HTTPS advertiser redirect URL, request only the scopes you use, and describe your business plainly. In my experience it takes three to seven business days. Full steps in how to get TikTok Marketing API access.

Why apps get rejected, and the fix

Plan review into the project

The biggest mistake isn't a rejected submission. It's treating review as the last step. Review can take longer than the build, and a rejection resets the clock.

What I do instead:

1. Week one: register the apps in the client's company name, verify the business and domain, and publish the website and privacy policy.
2. While building: use test accounts, demo data or standard access. Google's Test and Explorer levels, Meta's standard access and Shopify development stores all let you build before approval.
3. As soon as the core flow works: record the screencast and submit. Don't wait for every feature.
4. After approval: add features that need new scopes in small, separate review requests.

How Scalvo can help

Getting apps approved is a service we offer on its own: Shopify App Store apps, Meta advanced access, Google OAuth verification and Google Ads API access, and TikTok developer apps. We prepare the business details, the permission justifications, the screencast and the test setup, and handle reviewer replies. See app approval and launch. If you need the app itself built too, see SaaS product build, or book a call.