Building an iOS subscription pricing dashboard with the App Store Connect API: a practical blueprint for 2026

A step-by-step guide to pulling subscription pricing and subscriber data from App Store Connect API endpoints and assembling a pricing health dashboard — without a third-party analytics platform.

Why a pricing dashboard is worth building

App Store Connect Analytics gives you a useful but narrow view of subscription health: trials started, subscriptions activated, churn events, and gross revenue. What it does not give you is a unified picture of how your prices are performing across territories — which markets are converting at your current tier, where automatic currency adjustments have silently reshuffled your price points, and how your pricing compares against your own historical benchmarks.

The App Store Connect API exposes this data across two separate resource families: the Subscription and Pricing endpoints for product catalog and price-point data, and the Sales and Trends Reports API for transactional subscription metrics. Building a lightweight dashboard that pulls from both — even a Google Sheet fed by a nightly script — gives you visibility that no third-party analytics platform currently provides out of the box.

This guide walks through the endpoint structure, the data each surface exposes, and a blueprint for assembling a pricing health dashboard that updates automatically. It is a practical map for building one tailored to your app, not a production-ready codebase you can drop in unchanged.

The two data sources you need

The App Store Connect API has two fundamentally different data surfaces, and they require different calling patterns even though authentication uses the same JWT mechanism for both.

For a pricing dashboard, the first two are the core. The Analytics surface is valuable for top-of-funnel data but lies outside the pricing-health scope this guide focuses on. Joining subscriber-count data from the Reports API against territory price points from the Pricing API is where the genuinely useful cross-reference happens.

Querying subscription pricing data from the API

Apple's subscription pricing endpoints sit under the App Store Connect API v1 base URL. The hierarchy moves from app → subscription groups → individual subscriptions → price points. A request for price points on a specific subscription returns a list of objects, each describing a territory, a tier number, and the resulting customer price after Apple's tax and currency handling.

The typical call sequence looks like this:

1. Fetch your app's subscription groups: GET /v1/apps/{appId}/subscriptionGroups
2. Fetch subscriptions in each group: GET /v1/subscriptionGroups/{groupId}/subscriptions
3. Fetch current prices per subscription: GET /v1/subscriptions/{subscriptionId}/prices?include=subscriptionPricePoint

The price point objects include the territory code, the currency, the customer price, and the proceeds price — the amount Apple remits to you after its commission. Crucially, they also carry a flag indicating whether a price was set manually or inherited from Apple's automatic tier-based currency conversion. That distinction matters enormously when you are trying to understand which territories have drifted from your intended pricing intent after a currency adjustment cycle.

Fetching price points for all 175 territories across a subscription with multiple tiers requires careful pagination management. Apple returns a maximum of 200 records per page with a next cursor for continued fetching. The post on API pagination and rate limits covers the cursor pattern and rate limit behavior in detail — the short version is 4,000 requests per hour per key, with burst headroom. A well-written fetcher should handle cursor-based pagination automatically, respect rate limits with exponential backoff, and cache results locally so you are not hitting the API on every dashboard refresh.

One field worth noting in the response is preserveCurrentPrice — when set, it signals that a subscriber who purchased at an earlier price will be grandfathered at that price rather than migrated to the new one. This affects your revenue projections for existing cohorts and is easy to overlook when scanning price points in bulk. The mechanics are covered in depth in our post on Apple's grandfathering rules.

Pulling subscriber metrics from the Reports API

Subscription transaction data lives in the Sales and Trends Reports API, not the pricing endpoints. These reports are delivered as compressed tab-delimited text files, fetched via GET /v1/salesReports with query parameters specifying report type, frequency, and date.

For a pricing dashboard, two report types do most of the work:

• Subscription report (daily): One row per subscription product per territory per day. Columns include subscriber count, standard subscriber count (paid, non-trial), active free-trial subscribers, and revenue. This is your source for per-territory daily subscriber and revenue data.
• Subscription Event report (daily): One row per subscription lifecycle event — new subscriber, cancellation, billing retry, reactivation, crossgrade. Useful for churn analysis by territory and product ID, and for spotting involuntary churn spikes after a price change.

A typical dashboard pulls yesterday's Subscription report nightly, aggregates by territory and subscription product ID, and joins it against the pricing data fetched from the Pricing API to produce a per-territory view of: current price, subscriber count, and implied gross revenue. That join is the core of the dashboard — everything else is presentation.

The App Store Connect Reports API guide covers authentication headers, the required vendor number parameter, and how to decompress and parse the gzip TSV files in Python or Node.js. One practical note: the Reports API is sometimes 24–48 hours behind on holiday and weekend dates. Build your pipeline to tolerate missing dates gracefully rather than treating a gap as an error.

What your pricing dashboard should track

With data flowing from both surfaces, four core views give you the most useful pricing signal for the effort involved.

1. Territory price versus PPP parity score. Join your price-point data against a purchasing power parity index — the World Bank and IMF both publish annual data. Flag territories where your current price-to-PPP ratio is an outlier in either direction. This surfaces markets where you are likely leaving conversion on the table (overpriced relative to local income) and markets where you have headroom to test a higher tier. Research from platforms like RevenueCat has consistently found that conversion rates are sensitive to price-to-income ratios at the territory level, and a PPP column in your dashboard makes those signals visible at a glance.

2. Manual versus auto-converted territories. Track which territories are on manually set prices versus Apple's automatic currency conversion. When Apple runs a currency adjustment cycle — typically following significant exchange rate moves — some territories can shift. A column flagging "price method" (manual versus auto) and "price last changed date" lets you audit drift without opening App Store Connect manually for each market.

3. Revenue concentration by territory. From the Reports API data, rank territories by proceeds. Revenue is typically highly concentrated: studies of App Store subscription portfolios have shown that a small number of markets — commonly the US, UK, Germany, Japan, Australia, and Canada — can account for a large majority of gross revenue. Track your own concentration weekly so you notice when an emerging market begins contributing meaningfully, and so you can calibrate how much optimization effort each territory deserves.

4. Price-change event versus churn correlation. Layer the Subscription Event report onto your pricing history to check whether churn rates shifted materially in territories where a price change occurred. This is correlational, not causal — other factors affect churn simultaneously — but as Phiture's research on subscription lifecycle events suggests, involuntary and voluntary churn are both detectable in the event data within a few days of a price change, long before the billing-cycle-level picture clarifies.

Automation patterns and scheduling

A pricing dashboard that requires manual refreshes is not a dashboard — it is a report template. Two automation patterns make it genuinely operational.

Nightly metrics pipeline. A scheduled job — GitHub Actions, a cloud function, a cron on your server — runs nightly to: fetch yesterday's subscription reports from the Reports API, parse and load them into a database or spreadsheet, and optionally trigger a Slack or email alert if a territory's subscriber count or revenue shifts more than a configured threshold from its 7-day rolling average. The alert threshold is the part that requires tuning: set it too sensitive and you get noise; too loose and you miss real signals. Starting at ±20% from the rolling average is a reasonable default for most subscription apps.

Weekly price-point audit. A weekly job fetches the full price-point data for all subscriptions and all territories, diffs it against last week's snapshot, and logs any changes — especially changes to the "method" flag that indicate Apple made an automatic adjustment. This is your early-warning system for Apple-driven currency moves. It is considerably lighter than nightly pricing fetches and sufficient given that Apple's price adjustment cycles are not daily events.

Authentication for both pipelines follows the same JWT pattern: generate a signed JWT using your private key and key ID, set an expiry of no longer than 20 minutes, and pass it as a Bearer token in the Authorization header. The API authentication walkthrough covers the ES256 signing algorithm and required JWT claims in detail. One practical tip: generate a fresh token per script run rather than attempting to cache and reuse tokens across runs — the 20-minute limit and clock-skew tolerance make token reuse more fragile than it is worth.

For teams that want to skip the pipeline build, RevenueCat's Charts feature and Adapty's analytics dashboard both surface some of this data. Neither currently exposes the raw price-point-versus-territory comparison that the Connect API enables directly, however, and neither lets you join your own pricing decisions against subscriber counts in a custom view. Third-party tools are a reasonable starting point; building your own pipeline gives you the flexibility that off-the-shelf tools cannot match when pricing decisions are a deliberate, recurring part of your growth strategy.

Sources and further reading

• App Store Connect API Reference — Apple Developer Documentation
• App Store Subscriptions overview — Apple Developer
• RevenueCat Blog — subscription analytics and industry benchmarks
• Phiture Mobile Growth Stack — App Store subscription research
• World Bank PPP conversion factor data
• Set a price for an in-app purchase — App Store Connect Help