Bulk price update

What a bulk price update is

A bulk price update sets new prices for many SKU/territory combinations in a single operation. The alternative is changing prices one product, one country at a time in App Store Connect or Google Play Console: at meaningful catalog scale, that's thousands of clicks per push.

The motivating math is straightforward. A typical mobile app might have:

• 5 to 30 SKUs (subscriptions, in-app purchases, lifetime unlocks, consumable packs)
• 175 App Store territories
• 70-plus Google Play countries

Even a small catalog produces thousands of SKU/territory combinations. A larger subscription app with multiple billing periods can easily reach tens of thousands of price configs per release.

Manual updates at that scale are not practical. Bulk updates exist because the alternative is full-time clicking.

Bulk updates on App Store Connect

Apple supports bulk pricing operations through the App Store Connect API. The relevant endpoints handle:

• Creating price schedules per in-app purchase or subscription
• Setting per-territory overrides
• Scheduling future prices
• Deleting conflicting future schedules (a common cause of API errors)

The API enforces several constraints that scripts have to handle:

• Prices must map to valid rungs on the price point ladder
• Conflicting scheduled future prices must be removed before a new schedule is created
• Rate limits throttle high-volume request bursts
• Subscription products require separate handling from in-app purchases

Bulk updates on Google Play

Google Play exposes bulk pricing through the Google Play Developer API, with a different shape from Apple's:

• Prices are free-form decimals in each supported local currency, not snapped to a ladder
• The API uses service account authentication, not user-token OAuth
• Subscription base prices and offers (intro pricing, free trials) are separate concepts with separate update calls
• October 2025 deprecated the older Pricing Templates feature, so per-product per-country updates are now the only path

A tool or script that handles both stores effectively maintains two parallel integrations with non-overlapping shapes.

Common operational failure modes

Bulk update operations fail at scale in predictable ways:

• Rate-limit storms: naive retries hammer the API, the request budget collapses, the whole batch wedges
• Partial pushes: some SKU/territory combinations succeed, some fail, no clean way to identify the boundary
• Conflicting future prices: an unresolved scheduled price prevents the new push for that product/territory
• Stale ladder snapshots: a cached copy of Apple's price point matrix produces valid-looking targets that the API rejects
• Currency override gaps: Apple's USD-quoted territories vs. Google's local-currency rendering create silent storefront mismatches

Production-grade bulk update tooling handles all of these. Hand-rolled scripts typically handle two or three.

When you need a bulk update path

The threshold is operational, not theoretical:

• More than a handful of SKUs
• Both stores in scope
• Subscription products with multiple billing periods
• Periodic pricing adjustments (quarterly, FX-triggered, or Apple matrix-update triggered)
• Any team scenario where someone else on the team needs to push prices without code access

Below that threshold, console-based per-product updates are fine. Above it, the lack of a working bulk path becomes the binding constraint on how often you can revisit pricing.