A Daily Revenue Pipeline for 4 Wallpaper Apps: 8 Weeks Running App Store Connect API + AdMob With Claude Code

Three days lost on App Store Connect JWT auth

The first wall was JWT authentication for App Store Connect API. You generate a .p8 API key under Users and Access, then build a JWT using the Key ID and Issuer ID.

The first code Claude Code wrote for me looked like this:

# Did not work
import jwt
import time
 
def make_token(key_path: str, key_id: str, issuer_id: str) -> str:
    with open(key_path, "rb") as f:
        private_key = f.read()
    headers = {"alg": "ES256", "kid": key_id, "typ": "JWT"}
    payload = {
        "iss": issuer_id,
        "iat": int(time.time()),
        "exp": int(time.time()) + 1200,
        "aud": "appstoreconnect-v1",
    }
    return jwt.encode(payload, private_key, algorithm="ES256", headers=headers)

This returned 401 Unauthorized. Working through it with Claude Code, three traps surfaced.

First, iat and exp need to share the same time snapshot. Writing exp = int(time.time()) + 1200 and iat = int(time.time()) separately means the call to time.time() could differ by microseconds on fast machines, which sometimes shows up as boundary expiry errors during debugging. Capture now once and reuse it.

Second, the scope field can break some endpoints. Apple's sample code sometimes includes scope, but the Sales/Trends Reports endpoint was more stable without it.

Third, and the decisive one, handcrafted ES256 implementations can confuse DER and raw signature formats. PyJWT handled this correctly out of the box, but the early manual cryptography implementation Claude Code drafted returned a raw 64-byte signature (r + s concatenated). Apple's API expected DER. This is not stated explicitly in the docs — you only discover it by reading the library source. The final working version is below.

# Worked
import jwt
import time
 
def make_token(key_path: str, key_id: str, issuer_id: str) -> str:
    with open(key_path, "rb") as f:
        private_key = f.read()
    now = int(time.time())
    payload = {
        "iss": issuer_id,
        "iat": now,
        "exp": now + 1200,
        "aud": "appstoreconnect-v1",
    }
    return jwt.encode(
        payload,
        private_key,
        algorithm="ES256",
        headers={"kid": key_id, "typ": "JWT"},
    )

I recommend PyJWT 2.8 or newer. After three days of debugging, I left a comment at the top of the script that reads: "Generate JWT with PyJWT 2.8+. If you must implement ES256 by hand, sign in DER format." Having Claude Code write down lessons learned right next to the code is one of the things I value most about working with it on solo projects.

Sales Report retrieval: gzip and empty-report days

Once JWT works, fetching Sales Reports is straightforward. The endpoint is https://api.appstoreconnect.apple.com/v1/salesReports with filter[frequency]=DAILY and filter[reportDate]=YYYY-MM-DD. The response is gzip-compressed TSV with Content-Type: application/a-gzip.

Two traps live here.

# Trap 1: Forget to decompress gzip and your CSV parser eats garbled text
# Trap 2: Zero-sales day returns 200 (not 404) with a header-only body
 
def fetch_daily_sales(token: str, vendor_id: str, report_date: str) -> bytes | None:
    url = "https://api.appstoreconnect.apple.com/v1/salesReports"
    params = {
        "filter[frequency]": "DAILY",
        "filter[reportDate]": report_date,
        "filter[reportType]": "SALES",
        "filter[reportSubType]": "SUMMARY",
        "filter[vendorNumber]": vendor_id,
        "filter[version]": "1_0",
    }
    headers = {"Authorization": f"Bearer {token}"}
    r = requests.get(url, params=params, headers=headers, timeout=30)
    if r.status_code == 404:
        # Apple has not finalized aggregation yet (can happen on early morning UTC-8 calls)
        return None
    r.raise_for_status()
    return gzip.decompress(r.content)

The truly nasty case is "a 200 response with only the TSV header line on a zero-sales day". I missed this at first and was happily logging "revenue 0 yen" until a Slack alert showed wallpaper app B sitting at zero for two days. The real cause was a holiday delaying Apple's aggregation, leaving a header-only TSV behind. After Claude Code added a check that treats header-only TSVs as None and re-queues them, the false alerts stopped.

A simple exponential backoff was enough for retry:

def fetch_with_retry(fn, *args, max_retry: int = 4) -> bytes | None:
    for attempt in range(max_retry):
        try:
            result = fn(*args)
            if result is not None:
                lines = result.decode("utf-8").splitlines()
                if len(lines) <= 1:
                    return None  # header-only TSV
                return result
        except requests.HTTPError as e:
            if e.response.status_code in (429, 500, 502, 503):
                time.sleep(2 ** attempt)
                continue
            raise
    return None

My ASC key happily handled around 30 req/min with no issue. Four apps × one fetch per day never came close to hitting it.

AdMob Reporting API: localization settings and date filters

AdMob is a Google API, so OAuth2 service account auth is straightforward. google-api-python-client makes the rest easy.

from googleapiclient.discovery import build
from google.oauth2 import service_account
 
SCOPES = ["https://www.googleapis.com/auth/admob.readonly"]
 
def get_admob_client(sa_path: str):
    creds = service_account.Credentials.from_service_account_file(
        sa_path, scopes=SCOPES
    )
    return build("admob", "v1beta", credentials=creds)

The trap is localizationSettings. I left it out initially and AD_REQUEST figures occasionally came back inconsistent. Setting currencyCode: "JPY" and languageCode: "ja" made earnings come back in JPY, which removed the need to convert USD inside my aggregation layer.

report_spec = {
    "dateRange": {
        "startDate": {"year": 2026, "month": 5, "day": 22},
        "endDate":   {"year": 2026, "month": 5, "day": 22},
    },
    "dimensions": ["DATE", "APP", "AD_UNIT", "COUNTRY", "FORMAT"],
    "metrics": [
        "AD_REQUESTS", "MATCHED_REQUESTS",
        "IMPRESSIONS", "CLICKS",
        "ESTIMATED_EARNINGS",  # returned in JPY
        "IMPRESSION_CTR",
    ],
    "localizationSettings": {
        "currencyCode": "JPY",
        "languageCode": "ja",
    },
    "timeZone": "Asia/Tokyo",
}

The timeZone: "Asia/Tokyo" line is the key bit. AdMob defaults to the account's timezone, but you can override it per report. This way, the timezone correction for ASC (Pacific to JST) and the AdMob timezone setting are decoupled and clearly visible at the call site.

If you join "Pacific 5/22 revenue" with "JST 5/22 AdMob earnings" naively, you end up off by 17 hours. My pipeline pre-shifts ASC reports forward 17 hours so they sit on JST day boundaries.

-- JST-aligned daily summary
CREATE TABLE daily_summary (
    jst_date TEXT NOT NULL,
    app_id TEXT NOT NULL,
    asc_revenue_jpy INTEGER,        -- App Store Connect (PT -> JST adjusted)
    admob_earnings_jpy INTEGER,     -- AdMob (already JST via report spec)
    admob_impressions INTEGER,
    admob_ecpm_jpy REAL,
    subscriber_count INTEGER,
    PRIMARY KEY (jst_date, app_id)
);

This is an operational approximation, not an accounting-grade reconciliation. For interpreting daily variation through a human lens it works. A 1-2% gap between monthly sums and the ASC dashboard does not matter for this purpose.

Alerting: "25% day-over-day" and "three straight days at -15% same-weekday"

After eight weeks of operation, I learned that being too conservative with alert thresholds trains me to ignore Slack messages, while being too loose buries the signal that actually matters. The rules I settled on are these.

1. 25% or more day-over-day variation on per-app ASC revenue or AdMob earnings triggers an alert.
2. Three consecutive days of "same-weekday down 15%" triggers a structural eCPM warning.
3. Day 7 subscription retention moves ±3 points from the trailing 14-day median, alert.
4. AdMob mediation CPI on a single ad unit drops 30% or more, per-unit alert.
5. App Store Connect API 401/403 in a row, immediate auth alert.
6. Two straight days of empty Sales Reports for the same app, treat as aggregation delay.

Rule 6 is what handles the header-only TSV case I described above. With it in place I can distinguish Apple-side aggregation delay from genuine zero-revenue days.

A sample alert SQL looks like this:

WITH yesterday AS (
  SELECT app_id, asc_revenue_jpy, admob_earnings_jpy
  FROM daily_summary
  WHERE jst_date = date('now', '-1 day', 'localtime')
),
day_before AS (
  SELECT app_id, asc_revenue_jpy AS prev_asc, admob_earnings_jpy AS prev_admob
  FROM daily_summary
  WHERE jst_date = date('now', '-2 day', 'localtime')
)
SELECT
  y.app_id,
  y.asc_revenue_jpy, d.prev_asc,
  ROUND( CAST(y.asc_revenue_jpy AS REAL) / NULLIF(d.prev_asc, 0) - 1.0 , 3) AS asc_pct,
  y.admob_earnings_jpy, d.prev_admob,
  ROUND( CAST(y.admob_earnings_jpy AS REAL) / NULLIF(d.prev_admob, 0) - 1.0 , 3) AS admob_pct
FROM yesterday y JOIN day_before d ON y.app_id = d.app_id
WHERE ABS(CAST(y.asc_revenue_jpy AS REAL) / NULLIF(d.prev_asc, 0) - 1.0) >= 0.25
   OR ABS(CAST(y.admob_earnings_jpy AS REAL) / NULLIF(d.prev_admob, 0) - 1.0) >= 0.25;

The NULLIF(prev, 0) is a small but important detail. Without it, a freshly launched app with zero revenue the day before causes the Monday morning alert job to crash.

Three numbers from eight weeks: AdMob +14.3%, retention split, and a habit change

Three concrete numbers from eight weeks of operation drove real operational decisions. App names are anonymized; these are averages across the four apps.

First, AdMob rewarded eCPM improved by +14.3% on average. The daily summary surfaced "this one ad unit's eCPM has been dropping since Friday" during the second week of May. I rebalanced the mediation waterfall over that weekend and CPM recovered the following week. Without the morning digest I would not have noticed until the next Tuesday at the earliest. The biggest single app gained +21.8%.

Second, Day 7 subscription retention has a structural weekday/weekend gap. People who sign up on weekends had Day 7 retention 4.2 points higher on average than weekday sign-ups. My working hypothesis is that weekend sign-ups are "give it a try" while weekday sign-ups skew toward "I clicked the rewarded ad and forgot." This split led me to test different subscription creative on weekdays versus weekends.

Third, the habit of glancing at four apps' revenue every morning is the change that matters most. Under the manual routine, weekends would stack and I would put off Monday's check until Tuesday. With Slack pushing the digest at 7:00 JST, it now takes 30 seconds while my coffee brews. I only dig deeper when one number looks off. The psychological cost of operating four apps in parallel dropped significantly.

Where Claude Code actually mattered: log triage, not raw coding

Looking back over the eight weeks, Claude Code's biggest contribution was not the speed of writing code. It was working through stuck logs with me and leaving a note about the cause next to the code.

The DER-vs-raw JWT bug, the missing localizationSettings behavior, the header-only Sales Report pattern — none of these are stated in the public docs. Asking Claude Code "what's likely causing this 401" and getting three candidates, then verifying with a minimal reproduction script, let me close each one in half a day to a day.

What I appreciated most is that Claude Code tends to factor a minimal reproduction case out into its own file and compress logs to a single JSON line per event. When I write reproductions on my own I scatter print calls across the source. Claude Code's reproductions are structured logs that jq filters cleanly, which makes incident triage faster than I expected.

Both of my grandfathers were temple carpenters, and the joints they assembled hold up for decades. I have always felt the same about code. Code that just "ran" tends to break a few weeks later. After eight weeks of running this pipeline, what I can say is that the gap between "it ran" and "it does not break" is wider than most write-ups admit. Claude Code helps narrow that gap, and it fits the operational scale of indie development very well.

A minimum setup you can ship over a weekend

Reproducing eight weeks of operation from scratch is daunting, so here is the smallest version you can ship in a weekend.

# 1) Virtualenv
python3 -m venv .venv && source .venv/bin/activate
pip install pyjwt cryptography requests google-api-python-client \
            google-auth google-auth-httplib2
 
# 2) Layout
mkdir -p revenue_pipeline/{secrets,raw,scripts,db}
 
# 3) Drop your ASC .p8 and AdMob service account JSON into secrets/
 
# 4) A prompt to hand to Claude Code:
#    "Write revenue_pipeline/scripts/asc_fetcher.py:
#     - JWT auth via PyJWT 2.8
#     - Pull 7 days of Sales Report (DAILY/SUMMARY)
#     - Decompress gzip, save to raw/asc_YYYY-MM-DD.tsv
#     - 200 with header-only body returns None and re-queues
#     - Exponential backoff up to 4 retries"

That prompt alone gets you about 80% of the way to a working script. The remaining 20% — adapting to your environment, paths, and secrets — takes one or two more hours. Expanding to multiple apps and rolling into SQLite is comfortably a next-weekend task.

For developers who run multiple apps as a one-person operation, the morning revenue check is the kind of task that becomes a quiet weight you don't notice until it's gone. Handing it to Claude Code frees up time for the work you actually want to be doing — new features, customer support, the next product. Personally, the 15 minutes I used to spend every morning has fully dissolved into the pipeline, and that time now goes into customer responses and planning the next app.

The pipeline code itself remains private, but if you are operating in a similar setup, the failure stories and the six alerting rules should be the most directly reusable parts.