Capturing Perfect App Store and Google Play Screenshots at Scale

App Store and Google Play both reject submissions for the same boring reason: screenshots that do not match the exact required dimensions for a given device class. Design teams end up re-exporting assets by hand every time a screen changes, every time a new locale ships, or every time Apple adds a new device size to the list.

If your app has a marketing site or a hosted web preview for each screen, you do not need a design tool round-trip to produce these assets. A screenshot API can generate them directly from the URLs, at the exact pixel dimensions each store expects.

Why This Gets Painful Fast

• Multiple device classes. Apple alone asks for separate sizes for 6.9", 6.5", and iPad screenshots.
• Multiple locales. A 12-screenshot set for one language becomes 60+ files across five locales.
• Frequent re-shoots. Every UI change means re-capturing, re-cropping, and re-uploading the same set again.
• Manual QA. Someone has to check that nothing is off-center or cropped wrong before submission.

None of that is design work. It is repetitive asset generation, which is exactly what an API is good at automating.

Capturing at the Exact Required Dimensions

The Snapshot Site screenshot endpoint takes width and height directly, so you can request the exact pixel size a store expects instead of capturing at your default breakpoint and resizing afterward:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://app.example.com/preview/onboarding",
    "format": "png",
    "width": 1290,
    "height": 2796,
    "fullSize": false
  }'

Common target dimensions teams script against:

Asset	Width × Height
iPhone 6.9" screenshot	1290 × 2796
iPhone 6.5" screenshot	1284 × 2778
iPad Pro 12.9" screenshot	2048 × 2732
Google Play phone screenshot	1080 × 1920
Google Play feature graphic	1024 × 500

Because fullSize stays false for these captures, you get exactly the viewport you asked for — no scrolling, no unexpected extra content below the fold that a store would reject.

Stripping Promo Banners and Debug UI Before Capture

Preview builds often carry a staging banner, a feature flag toggle, or a "beta" ribbon that should never appear in a store listing. The v2 endpoint accepts hide, a CSS selector for anything that should be removed before the screenshot is taken:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v2/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://app.example.com/preview/onboarding?locale=fr",
    "format": "png",
    "width": 1290,
    "height": 2796,
    "hide": "#staging-banner, .debug-toolbar"
  }'

Combine that with delay if the screen animates in charts, avatars, or onboarding illustrations, so the capture happens after everything has settled.

Scripting the Full Locale Matrix

Once the request shape is right for one screen and one locale, the rest is a loop: iterate over your list of preview URLs (one per screen), your list of device dimensions, and your list of locale query params, and call the same endpoint for every combination. A 6-screen, 5-locale, 3-device-class set that used to take a designer an afternoon becomes a script that runs in minutes and can be re-run on every release candidate.

That turns app store screenshots from a recurring manual export chore into a step your release pipeline can run on its own — and re-run automatically the next time a screen changes. If you also generate marketing assets at standard device sizes, our guide on emulating iPhone, Android, and tablet screens with width and height presets covers the reusable preset table.

Store listings are one of the few places where pixel-perfect, repeatable output matters more than creative flexibility — which is exactly the kind of workload Snapshot Site is built to automate.