Stop spending Saturday night in App Store Connect

A practical guide to the App Store Connect API: what it covers, how authentication works, the gotchas around price points and localizations, and why most homegrown scripts fall short of production tooling.

Anyone who has shipped more than a couple of iOS apps has spent a launch evening clicking through App Store Connect, setting prices in 175 territory dropdowns one at a time, copying screenshots into 39 language slots, and pasting "What's new" into 39 description fields. It is one of the most thankless workflows in software, and the cost is mostly hidden — measured in weekend evenings, missed launch windows, and copy-paste errors that put the wrong description into the German listing.

This is exactly what the App Store Connect API was built for. Used well, it eliminates 90%+ of the manual clicking from the App Store side of running an iOS business — turning a 4-hour Saturday afternoon into a 2-minute scripted run.

What the App Store Connect API actually covers

Apple introduced the App Store Connect API in 2018 and has expanded its scope steadily since. As of 2026, the API supports operations across roughly these areas:

• Pricing — read and write app prices, in-app purchase prices, and subscription pricing per territory
• Localizations — read and write app metadata, version metadata, IAP localizations, subscription localizations, and subscription-group localizations across all 39 supported languages
• Builds and TestFlight — list builds, manage testers, generate invites, fetch crash reports
• App store submissions — submit for review, manage release phases, schedule a release
• Sales and finance — fetch sales reports, financial reports, payment data
• Users and access — invite teammates, manage roles

For most indie developers, the highest-value categories are pricing and localizations — these are the operations that genuinely take hours per release if done by hand and seconds via API.

How authentication works (and why it's easy to mess up)

Apple uses a JWT-based authentication model for the API. You generate an API key in App Store Connect under Users and Access → Integrations → App Store Connect API. Apple gives you three pieces:

• Issuer ID — a UUID identifying your team
• Key ID — a 10-character identifier for the specific key
• Private key (.p8 file) — an EC-256 private key you download once (you cannot re-download it)

To make a request, you sign a JWT with the private key (using ES256), set the iss claim to your Issuer ID, the kid header to your Key ID, an audience of appstoreconnect-v1, and an expiration no more than 20 minutes in the future. The signed JWT goes in the Authorization: Bearer ... header on every request.

The pricing endpoints — what they look like in practice

For subscriptions, applying PPP-adjusted prices across 175 territories looks roughly like this in pseudo-API terms:

1. Fetch the list of price points available for your subscription (each subscription has its own price-point IDs, encoded with the subscription ID embedded — this is a critical Apple-specific detail many developers miss)
2. For each territory you want to update, find the price point that matches your target local price
3. POST a subscriptionPrices resource that links the subscription, the territory, the price point ID, and an effective start date

For in-app purchases the flow is similar but uses a different endpoint family. The two are not interchangeable.

Here is what's interesting: Apple's price-point IDs are subscription-specific. If you fetch price points for one subscription, you cannot reuse those IDs on another subscription. The IDs are base64-encoded JSON containing the subscription ID, territory, and price index. This is documented but easy to miss, and it's the most common reason early API integrations break in unexpected ways.

The localization endpoints — five separate resource types

Localizations split into five separate API resources, each with its own endpoints:

Pushing a full set of localizations for a release means PATCHing each of these resource types for each locale. With 6 target locales and all five resource types, that's 30 API calls — automatable in seconds, but tedious to do manually through the web UI.

Rate limits, quotas, and what to actually expect

Apple does not publish a hard rate limit for the App Store Connect API in the same way that Twitter or GitHub do. From practical experience and Apple's developer forums, the API is generous for normal use — bulk applying prices across 175 territories or pushing localizations to 39 locales does not get throttled when done at reasonable concurrency (5-10 parallel requests).

What does happen:

• Individual API calls can be slow under load (1-3 seconds per write is common)
• Apple's backend occasionally returns 5xx errors on writes; you need to retry with exponential backoff
• Some operations are eventually-consistent — a price you just set may not appear in immediate read calls for a few seconds

Production-grade tooling handles all three: parallel requests with bounded concurrency, automatic retry on 5xx with backoff, and a verification step that re-reads what was written.

The DIY tax most teams underestimate

Many indie developers reach for Fastlane (free, Ruby-based) or write their own Python/Node scripts. These work — but the operational cost adds up:

• Token rotation, JWT signing, EC-256 key handling — all of this is re-implemented per project
• Retry logic, error handling, partial-failure recovery — what happens when 3 of 175 territories fail? Most homegrown scripts fail loudly and require manual cleanup
• Audit logging — who changed which price when, on which app, with what result?
• Secret management — the .p8 private key is sensitive. Storing it in a repo, on a CI runner, or in a teammate's laptop are all common but suboptimal
• UI — when a non-engineer (designer, marketer, founder) needs to push a localized "What's new", they shouldn't have to use a CLI

Each of these is solvable, but together they explain why most apps end up under-using the API even though the engineering team theoretically has access.

What we built and why it's different

appsops.store wraps the App Store Connect API with three things most homegrown scripts don't include: a real web UI, encrypted secret storage (your .p8 key is encrypted at rest with Fernet/AES-128 and decrypted only in memory at the moment of an authorized API call), and an audit log of every change you make. The same dashboard does PPP pricing and localization, so you don't have to switch between tools.

Concretely, what takes hours by hand becomes:

• Bulk price update across 175 territories — one click after picking a tier mapping
• Push localizations to all 39 languages — paste a CSV, click apply
• Schedule a price change for a future date — subscription pricing supports this; we expose it as a date picker, not raw API calls

Worth doing even if you only have one app

Some developers think API automation is something you graduate into once you have ten apps. That's backwards. It's most valuable when you have one app — because that one app's launch evenings, price experiments, and localization rollouts can each soak a weekend if done by hand. With one app and the API, those rollouts take minutes. The compounding benefit is that you're more likely to actually do price experiments and localization updates, which directly drives revenue.

References and further reading

• Apple — App Store Connect API documentation
• Apple — How to create an App Store Connect API key
• Fastlane — open-source CLI for App Store Connect automation
• Why a $9.99 app shouldn't cost ₹830 in India — PPP pricing in practice
• Why App Store localization matters — pillar guide