Build a Mobile App Revenue Dashboard with Claude Code — Integrating AdMob, App Store Connect, and Google Play Console APIs with Automated Daily Reports

Stack Choices (and Why)

Here's the setup. I'll explain each choice.

• Cloudflare Workers — Cron Triggers for daily batch jobs. Zero cold-start cost and a generous free tier.
• Cloudflare KV — Persistence for daily aggregates. prefix list supports date-range queries naturally.
• Hono — Lightweight, type-safe framework that runs inside Workers.
• Recharts — For dashboard charts. Lives in Next.js, not Workers.
• Next.js + Cloudflare Pages — Dashboard UI that reads KV via an internal API route.

If you want the deployment and operations side of Workers in more depth, I covered that in running Next.js on Cloudflare Workers in production.

A key decision: the batch job and the UI are separate projects. Their runtime needs are different. The batch runs on a cron a few times a day; the UI has to respond fast to user clicks. Separating them means I can iterate on the UI without risk of breaking the ingestion pipeline.

Step 1: App Store Connect — Auth and Sales Reports

This is the first wall. App Store Connect's auth flow is nothing like the Google APIs, and if it's your first time, you will get stuck.

Signing Your Own JWT with a P8 Key

App Store Connect uses JWTs you sign yourself with an ES256 private key. Download the P8 file from your Apple Developer portal, then sign with jose or similar.

// src/auth/appstore.ts
import { SignJWT, importPKCS8 } from 'jose';
 
interface AppStoreAuthConfig {
  issuerId: string;
  keyId: string;       // the 10-char ID in the P8 filename
  privateKey: string;  // contents of the P8 file (PEM)
}
 
/**
 * Generates a JWT for the App Store Connect API.
 * Apple caps validity at 20 minutes; we intentionally use 18.
 */
export async function generateAppStoreJWT(config: AppStoreAuthConfig): Promise<string> {
  const privateKey = await importPKCS8(config.privateKey, 'ES256');
 
  const jwt = await new SignJWT({
    iss: config.issuerId,
    aud: 'appstoreconnect-v1',
  })
    .setProtectedHeader({
      alg: 'ES256',
      kid: config.keyId,
      typ: 'JWT',
    })
    .setIssuedAt()
    .setExpirationTime('18m')
    .sign(privateKey);
 
  return jwt;
}

Why 18 minutes instead of 20? Apple allows up to 20, but if the token expires mid-request you'll get a 401 that's hard to diagnose. Capping at 18 avoids the edge case where a long batch run sees a token flip mid-execution. This is the root cause of "mysterious occasional 401s" in production.

Parsing the gzip-Compressed TSV

Once the JWT works, you can call Sales Reports. Brace yourself for the response format.

// src/fetchers/appstore-sales.ts
import { gunzipSync } from 'node:zlib';
 
export interface AppStoreSalesRow {
  appleId: string;
  title: string;
  units: number;
  developerProceeds: number;
  date: string;
}
 
export async function fetchAppStoreSales(
  jwt: string,
  vendorNumber: string,
  reportDate: string,
): Promise<AppStoreSalesRow[]> {
  const params = new URLSearchParams({
    'filter[frequency]': 'DAILY',
    'filter[reportType]': 'SALES',
    'filter[reportSubType]': 'SUMMARY',
    'filter[vendorNumber]': vendorNumber,
    'filter[reportDate]': reportDate,
    'filter[version]': '1_1',
  });
 
  const res = await fetch(
    `https://api.appstoreconnect.apple.com/v1/salesReports?${params}`,
    {
      headers: {
        Authorization: `Bearer ${jwt}`,
        Accept: 'application/a-gzip', // required or you'll get 404
      },
    },
  );
 
  if (res.status === 404) {
    // Data for "today" or sometimes "yesterday" isn't finalized yet.
    return [];
  }
  if (!res.ok) {
    throw new Error(`App Store Connect error: ${res.status} ${await res.text()}`);
  }
 
  const compressed = new Uint8Array(await res.arrayBuffer());
  const decompressed = gunzipSync(compressed).toString('utf-8');
  return parseTSV(decompressed);
}
 
function parseTSV(tsv: string): AppStoreSalesRow[] {
  const lines = tsv.split('\n').filter(Boolean);
  const headers = lines[0].split('\t');
  const rows = lines.slice(1);
 
  const idxAppleId = headers.indexOf('Apple Identifier');
  const idxTitle = headers.indexOf('Title');
  const idxUnits = headers.indexOf('Units');
  const idxProceeds = headers.indexOf('Developer Proceeds');
  const idxDate = headers.indexOf('Begin Date');
 
  return rows
    .map((row) => {
      const cols = row.split('\t');
      return {
        appleId: cols[idxAppleId],
        title: cols[idxTitle],
        units: Number(cols[idxUnits] || 0),
        developerProceeds: Number(cols[idxProceeds] || 0),
        date: cols[idxDate],
      };
    })
    .filter((r) => r.units > 0);
}

Sharp edge: Without Accept: 'application/a-gzip', the API returns 404 with no hint that the header is the problem. It's in the docs but easy to miss if you're copying from a Stack Overflow snippet. I lost half an hour here.

Also, expect 404 for recent dates. Apple's daily data isn't available until a few hours after UTC midnight. Treat 404 as "data not ready yet" in your success path — if you treat it as a failure, your batch will alarm every morning.

Step 2: AdMob Network Report API

AdMob uses standard Google service-account OAuth2. Simpler than App Store Connect, but the query syntax has its own quirks.

// src/fetchers/admob-report.ts
import { GoogleAuth } from 'google-auth-library';
 
export interface AdMobRow {
  appId: string;
  appName: string;
  date: string;
  impressions: number;
  earnings: number;
  ecpm: number;
}
 
export async function fetchAdMobReport(
  serviceAccountKeyJson: string,
  accountId: string,
  startDate: string,
  endDate: string,
): Promise<AdMobRow[]> {
  const auth = new GoogleAuth({
    credentials: JSON.parse(serviceAccountKeyJson),
    scopes: ['https://www.googleapis.com/auth/admob.readonly'],
  });
  const client = await auth.getClient();
  const token = (await client.getAccessToken()).token;
 
  const body = {
    reportSpec: {
      dateRange: {
        startDate: parseDate(startDate),
        endDate: parseDate(endDate),
      },
      dimensions: ['DATE', 'APP', 'APP_NAME'],
      metrics: ['IMPRESSIONS', 'ESTIMATED_EARNINGS', 'IMPRESSION_RPM'],
      dimensionFilters: [],
      sortConditions: [{ dimension: 'DATE', order: 'ASCENDING' }],
    },
  };
 
  const res = await fetch(
    `https://admob.googleapis.com/v1/accounts/${accountId}/networkReport:generate`,
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${token}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(body),
    },
  );
 
  if (!res.ok) {
    throw new Error(`AdMob error: ${res.status} ${await res.text()}`);
  }
 
  const data = await res.json<any[]>();
  return data
    .filter((item) => item.row)
    .map((item) => ({
      appId: item.row.dimensionValues.APP.value,
      appName: item.row.dimensionValues.APP_NAME.value,
      date: formatDate(item.row.dimensionValues.DATE.value),
      impressions: Number(item.row.metricValues.IMPRESSIONS.integerValue || 0),
      // microsAmount is the value multiplied by 1,000,000
      earnings: Number(item.row.metricValues.ESTIMATED_EARNINGS.microsAmount || 0) / 1_000_000,
      ecpm: Number(item.row.metricValues.IMPRESSION_RPM.microsAmount || 0) / 1_000_000,
    }));
}
 
function parseDate(ymd: string): { year: number; month: number; day: number } {
  const [y, m, d] = ymd.split('-').map(Number);
  return { year: y, month: m, day: d };
}
 
function formatDate(d: { year: number; month: number; day: number }): string {
  return `${d.year}-${String(d.month).padStart(2, '0')}-${String(d.day).padStart(2, '0')}`;
}

Sharp edge: AdMob reports earnings as microsAmount — the real value multiplied by one million. Divide by 1,000,000 to get dollars or yen. Miss this and your revenue looks 100× larger than reality. I briefly thought I'd hit it big.

Also, AdMob's response mixes header, row, and footer elements in the same array. You have to filter for row before processing.

Step 3: Google Play Console Sales Data

Google Play's finalized revenue is exported as CSV to a Cloud Storage bucket. You have the Reporting API or the GCS approach. For finalized revenue, go with GCS — the Reporting API's numbers shift until the month closes.

// src/fetchers/playstore-sales.ts
import { GoogleAuth } from 'google-auth-library';
import Papa from 'papaparse';
 
export interface PlayStoreRow {
  date: string;
  productId: string;
  appName: string;
  amountMerchantCurrency: number;
  merchantCurrency: string;
}
 
export async function fetchPlayStoreSales(
  serviceAccountKeyJson: string,
  bucketName: string, // e.g. "pubsite_prod_rev_XXXXXXXXXX"
  yearMonth: string,  // YYYYMM
): Promise<PlayStoreRow[]> {
  const auth = new GoogleAuth({
    credentials: JSON.parse(serviceAccountKeyJson),
    scopes: ['https://www.googleapis.com/auth/devstorage.read_only'],
  });
  const client = await auth.getClient();
  const token = (await client.getAccessToken()).token;
 
  const objectPath = `sales/salesreport_${yearMonth}.zip`;
  const url = `https://storage.googleapis.com/storage/v1/b/${bucketName}/o/${encodeURIComponent(objectPath)}?alt=media`;
 
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${token}` },
  });
  if (!res.ok) {
    throw new Error(`Play Store GCS error: ${res.status}`);
  }
 
  const zipBuffer = await res.arrayBuffer();
  const csvText = await extractCsvFromZip(zipBuffer);
 
  const parsed = Papa.parse(csvText, { header: true, skipEmptyLines: true });
  return (parsed.data as any[]).map((row) => ({
    date: row['Transaction Date'],
    productId: row['Product id'],
    appName: row['Product Title'],
    amountMerchantCurrency: Number(row['Amount (Merchant Currency)'] || 0),
    merchantCurrency: row['Merchant Currency'],
  }));
}
 
async function extractCsvFromZip(buffer: ArrayBuffer): Promise<string> {
  const { unzipSync, strFromU8 } = await import('fflate');
  const files = unzipSync(new Uint8Array(buffer));
  const csvFile = Object.keys(files).find((name) => name.endsWith('.csv'));
  if (!csvFile) throw new Error('No CSV found in Play Store ZIP');
  return strFromU8(files[csvFile]);
}

Why GCS over Reporting API: The Reporting API returns live numbers that keep shifting until month-end. For P&L-style reporting, you want the Financial Reports in GCS, which are final. Use the Reporting API for daily trend sniffing, and GCS for the monthly books.

Step 4: Wiring It Up in Cloudflare Workers

With three fetchers in place, we put them behind a cron handler.

// src/worker.ts
import { fetchAppStoreSales, generateAppStoreJWT } from './fetchers/appstore';
import { fetchAdMobReport } from './fetchers/admob-report';
 
interface Env {
  REVENUE_KV: KVNamespace;
  ASC_ISSUER_ID: string;
  ASC_KEY_ID: string;
  ASC_PRIVATE_KEY: string;
  ASC_VENDOR_NUMBER: string;
  ADMOB_SERVICE_KEY: string;
  ADMOB_ACCOUNT_ID: string;
  SLACK_WEBHOOK_URL: string;
}
 
export default {
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    const yesterday = new Date(Date.now() - 86400_000).toISOString().slice(0, 10);
 
    const [appStore, adMob] = await Promise.allSettled([
      (async () => {
        const jwt = await generateAppStoreJWT({
          issuerId: env.ASC_ISSUER_ID,
          keyId: env.ASC_KEY_ID,
          privateKey: env.ASC_PRIVATE_KEY,
        });
        return fetchAppStoreSales(jwt, env.ASC_VENDOR_NUMBER, yesterday);
      })(),
      fetchAdMobReport(env.ADMOB_SERVICE_KEY, env.ADMOB_ACCOUNT_ID, yesterday, yesterday),
    ]);
 
    if (appStore.status === 'fulfilled') {
      await env.REVENUE_KV.put(
        `revenue:${yesterday}:appstore`,
        JSON.stringify(appStore.value),
        { expirationTtl: 60 * 60 * 24 * 365 * 3 },
      );
    }
    if (adMob.status === 'fulfilled') {
      await env.REVENUE_KV.put(
        `revenue:${yesterday}:admob`,
        JSON.stringify(adMob.value),
      );
    }
 
    await postDailySummaryToSlack(env.SLACK_WEBHOOK_URL, {
      date: yesterday,
      appStore: appStore.status === 'fulfilled' ? sumProceeds(appStore.value) : null,
      adMob: adMob.status === 'fulfilled' ? sumEarnings(adMob.value) : null,
    });
  },
};
 
function sumProceeds(rows: Array<{ developerProceeds: number }>): number {
  return rows.reduce((acc, r) => acc + r.developerProceeds, 0);
}
function sumEarnings(rows: Array<{ earnings: number }>): number {
  return rows.reduce((acc, r) => acc + r.earnings, 0);
}
 
async function postDailySummaryToSlack(
  webhook: string,
  summary: { date: string; appStore: number | null; adMob: number | null },
): Promise<void> {
  const lines = [
    `*${summary.date} revenue summary*`,
    summary.appStore !== null ? `App Store: $${summary.appStore.toFixed(2)}` : 'App Store: fetch failed',
    summary.adMob !== null ? `AdMob: $${summary.adMob.toFixed(2)}` : 'AdMob: fetch failed',
  ];
  await fetch(webhook, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: lines.join('\n') }),
  });
}

Configure the cron in wrangler.toml:

[triggers]
crons = ["0 22 * * *"]  # UTC 22:00 = JST 07:00 daily

Why Promise.allSettled instead of Promise.all: If one platform returns a 404 or 5xx, I still want to save the other two. Promise.all throws the moment one rejects, leaving you with a morning where Slack says "everything failed" when actually two-thirds of the data is fine.

When the Numbers Don't Match: Three Bugs I Measured

Everything above runs. Records land in KV, a summary shows up in Slack every morning. And the totals were still wrong.

The number in Slack and the number in App Store Connect's web UI didn't line up. If it had crashed, I'd have caught it on day one. Working-but-wrong is the worst failure mode there is.

I can't paste real sales data here, so to isolate it I built a TSV in exactly the shape Apple returns — CRLF line endings, 28 columns, a refund row — and ran it through parseTSV from Step 1 and sumProceeds from Step 4 unmodified. Five rows. The amounts are illustrative; the column semantics and row shapes are real.

Worked out by hand, the correct total is Σ(Units × Developer Proceeds) = 86.10 USD. Here's what Node 22 actually printed:

--- LF (\n)
  rows parsed: 4 / 5
  article's sumProceeds = 6.30
  correct Σ(units × proceeds) = 86.10
  understated by: 92.7%

--- CRLF (\r\n)  ← what Apple actually sends
  rows parsed: 4 / 5
  article's sumProceeds = 6.30
  correct Σ(units × proceeds) = 86.10
  understated by: 92.7%

Understated by 92.7%. And because LF and CRLF produce the identical wrong number, the instinct to blame line endings leads nowhere. There were three separate bugs.

Bug 1: Developer Proceeds is per unit, not per row

This is where the 92.7% comes from. In the SALES / SUMMARY report, the Developer Proceeds column is the developer's take on a single unit, not the row's revenue. Fifty copies at 0.70 each is 35.00 for that row, not 0.70.

sumProceeds adds r.developerProceeds directly, so it was reporting a sum of unit prices as if it were revenue. Unit prices land in the range of tens of cents to a few dollars, which means the result looks plausible. You can be two orders of magnitude off and never feel it while glancing at Slack over coffee.

The fix is to multiply: units * developerProceeds.

Bug 2: units > 0 silently deletes refunds

The .filter((r) => r.units > 0) at the end of parseTSV was there to drop free-download rows. But Apple represents refunds as negative Units, so the same filter throws those away too.

On the fixture above, the correct total including refunds is 86.10 USD; filtering to units > 0 gives 88.20 USD — overstated by 2.10 USD. Small in absolute terms, but the error grows exactly in the months you have the most refunds. The dashboard flatters you most when things are going worst.

Worse, later in this article I recommend building idempotent re-aggregation because "Apple revises past data for refunds." Re-running a batch whose parser discards refunds just converges on the same wrong number.

What you actually want to exclude is zero-value rows: units !== 0 && perUnitProceeds !== 0.

Bug 3: yesterday is off by one day in JST

const yesterday = new Date(Date.now() - 86400_000).toISOString().slice(0, 10); doesn't mean what it looks like once you pair it with the cron. crons = ["0 22 * * *"] fires at 22:00 UTC, which is 07:00 the next day in JST.

It always reaches one day further back than intended. That happens to be the safe direction with respect to Apple's data finalization, so nothing breaks — but the Slack message is labeled 8/18 while the reader assumes they're looking at 8/19. Month boundaries are the painful case: the notification arriving on the morning of September 2 covers August 31, so scrolling back through Slack to reconcile a month always comes up a day short.

If the intent is "the previous day in JST," compute it in that timezone rather than subtracting from UTC.

The corrected version

All three fixed. The diff is small; the numbers it produces are not.

// src/fetchers/appstore-sales.ts (corrected)
function parseTSV(tsv: string): AppStoreSalesRow[] {
  // Apple sends CRLF — strip the \r before anything else
  const lines = tsv.replace(/\r/g, '').split('\n').filter(Boolean);
  const headers = lines[0].split('\t');
 
  const idx = (name: string) => {
    const i = headers.indexOf(name);
    if (i === -1) throw new Error(`Sales report column not found: ${name}`);
    return i;
  };
  const idxAppleId = idx('Apple Identifier');
  const idxTitle = idx('Title');
  const idxUnits = idx('Units');
  const idxProceeds = idx('Developer Proceeds');
  const idxDate = idx('Begin Date');
 
  return lines.slice(1)
    .map((row) => {
      const cols = row.split('\t');
      const units = Number(cols[idxUnits] || 0);
      const perUnit = Number(cols[idxProceeds] || 0);
      return {
        appleId: cols[idxAppleId],
        title: cols[idxTitle],
        units,
        perUnitProceeds: perUnit,
        // Row revenue = units x per-unit. Refunds go negative naturally.
        developerProceeds: units * perUnit,
        date: cols[idxDate],
      };
    })
    // Drop only zero-value rows; keep negative (refund) rows
    .filter((r) => r.units !== 0 && r.perUnitProceeds !== 0);
}

// src/worker.ts (corrected date handling)
/** Returns the previous calendar day in JST, independent of when the cron fires. */
function jstYesterday(now = new Date()): string {
  const jstNow = new Date(now.getTime() + 9 * 60 * 60 * 1000);
  jstNow.setUTCDate(jstNow.getUTCDate() - 1);
  return jstNow.toISOString().slice(0, 10);
}

Turning idx() into a function that throws on a missing column matters more than it looks. If Apple reshuffles the report, headers.indexOf() returns -1, cols[-1] is undefined, and Number(undefined || 0) quietly yields 0 — so the batch completes successfully with every figure zeroed. That is the single worst behavior a money pipeline can have.

Every one of these would have surfaced on day one with a single test. I treated "a number appeared in Slack" as proof the thing worked, and then didn't question it for a long time. If your code ingests money from an external API, write one test: a five-row fixture in the real response shape, checked against a total you worked out by hand. The measurements above are literally just that test, and it would have saved everything in the first half of this article.

The same class of failure — silently wrong instead of loudly broken — shows up in date handling too. I wrote up a related timezone case in when an unattended job's log overwrites the previous day's.

Step 5: The Dashboard UI (Next.js + Recharts)

Once the Worker is writing to KV, the dashboard reads through an internal API route.

// app/api/revenue/route.ts
import { getCloudflareContext } from '@opennextjs/cloudflare';
 
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const days = Math.min(Number(searchParams.get('days') || '30'), 90);
 
  const { env } = getCloudflareContext();
  const endDate = new Date();
  const startDate = new Date(Date.now() - days * 86400_000);
 
  const results: any[] = [];
  for (let d = new Date(startDate); d <= endDate; d.setDate(d.getDate() + 1)) {
    const ymd = d.toISOString().slice(0, 10);
    const [appStore, adMob] = await Promise.all([
      env.REVENUE_KV.get(`revenue:${ymd}:appstore`, 'json'),
      env.REVENUE_KV.get(`revenue:${ymd}:admob`, 'json'),
    ]);
    results.push({
      date: ymd,
      appStoreTotal: sumOrZero(appStore, 'developerProceeds'),
      adMobTotal: sumOrZero(adMob, 'earnings'),
    });
  }
 
  return Response.json(results);
}
 
function sumOrZero(data: any, key: string): number {
  if (!Array.isArray(data)) return 0;
  return data.reduce((acc, r) => acc + (r[key] || 0), 0);
}

// app/dashboard/page.tsx
'use client';
import { useEffect, useState } from 'react';
import { LineChart, Line, XAxis, YAxis, Tooltip, Legend, ResponsiveContainer } from 'recharts';
 
export default function Dashboard() {
  const [data, setData] = useState<any[]>([]);
  useEffect(() => {
    fetch('/api/revenue?days=30').then((r) => r.json()).then(setData);
  }, []);
 
  return (
    <div style={{ padding: 24 }}>
      <h1>Mobile App Revenue Dashboard</h1>
      <ResponsiveContainer width="100%" height={400}>
        <LineChart data={data}>
          <XAxis dataKey="date" />
          <YAxis />
          <Tooltip />
          <Legend />
          <Line type="monotone" dataKey="appStoreTotal" stroke="#007aff" name="App Store" />
          <Line type="monotone" dataKey="adMobTotal" stroke="#00c853" name="AdMob" />
        </LineChart>
      </ResponsiveContainer>
    </div>
  );
}

Why an API route between the client and KV: Letting the client touch KV directly would leak auth material. Routing through a server endpoint keeps auth, rate limiting, and caching in one place. On Cloudflare Pages, the API route is itself a Worker, so there's no extra cost.

How || 0 Swallows NaN: Measuring the Google Play Side

Once the App Store numbers were honest, I went back to check Google Play. Reading the Step 3 fetcher next to the sumOrZero I had just written, my hand stopped on one line: Number(row['Amount (Merchant Currency)'] || 0).

Play's financial reports ship amounts with thousands separators still in them. It's a CSV, so those fields arrive quoted, and the parser hands back 1,600 as a single, correct cell. That string is neither empty nor 0, so || passes it straight through, and Number('1,600') comes out as NaN.

Then acc + (r[key] || 0) inside sumOrZero treats NaN as falsy and substitutes 0. The column exists, the parse succeeds, nothing throws. Only the rows above 1,000 quietly leave the total.

I built five CSV rows in the real shape — quoted fields, thousands separators, one refund — and ran them through Node 22. The amounts are illustrative; the quoting and column layout are not.

By hand, the total is 370 + 1,600 − 1,600 + 980 + 12,300 = 13,650. Here's what actually came back:

  Rows that became NaN: 3 / 5
  Article's total (sumOrZero) = 1350
  Correct total               = 13650
  Under-reported by: 90.1%

The awkward part is that the direction of the error changes month to month. Feed the same code a month where only the refund crosses 1,000 and it tips the other way:

Scenario B values: [ 370, 980, NaN ]  article total = 1350  correct = -250
  → difference: 1600 (over-reported)

Months that under-report and months that over-report sit side by side, so the shape of the chart still looks plausible. Lining up several months may not reveal it either.

Two short fixes. Strip the separators where you read, and drop || where you add.

// src/fetchers/playstore-sales.ts (corrected excerpt)
/** Strips thousands separators; refuses to guess at unreadable values. */
function parseAmount(raw: unknown, ctx: string): number {
  const normalized = String(raw ?? '').replace(/,/g, '').trim();
  const n = Number(normalized);
  if (normalized === '' || Number.isNaN(n)) {
    throw new Error(`Unparsable amount at ${ctx}: ${JSON.stringify(raw)}`);
  }
  return n;
}

// app/api/revenue/route.ts (corrected — replacing sumOrZero)
function sumStrict(data: unknown, key: string): number {
  if (!Array.isArray(data)) return 0;
  return data.reduce((acc: number, r: Record<string, unknown>) => {
    const v = r?.[key];
    if (typeof v !== 'number' || Number.isNaN(v)) {
      throw new Error(`Non-numeric ${key}: ${JSON.stringify(v)}`);
    }
    return acc + v;
  }, 0);
}

Run the same fixture through the corrected code and the total returns to 13,650, while a blank amount raises Unparsable amount at row X: "". If it breaks, I can fix it before breakfast.

On a money path, || 0 isn't a default — it's a place to hide a failure. Treating missing, zero, and NaN as the same thing is fine in the last render step and nowhere earlier. Mid-pipeline, I'd rather an unreadable value stopped me.

It took me half a year to suspect that line. On days when the total looked small, I put it down to the apps, or the season. What I may have been missing all along was the comma, and I only saw it after writing the App Store fixture. So here's the line I drew after measuring twice: leave no path where a failed parse is allowed to pass as zero.

Pitfalls You'll Hit (and How to Avoid Them)

These are the mines I actually stepped on.

Pitfall 1: Wrong kid Causes an Infinite 401 Loop

The JWT header needs kid — the 10-character Key ID. It matches the XXXXXXXXXX portion of the P8 filename AuthKey_XXXXXXXXXX.p8, not your Issuer ID or Team ID. Apple's error message is just "401 Unauthorized" with zero hints. When I complained "the JWT looks right but I still get 401", Claude Code immediately asked me to double-check kid. That saved me from another hour of staring at the token.

Pitfall 2: node:zlib Inside Cloudflare Workers

gunzipSync is a Node built-in. On Workers it requires compatibility_flags = ["nodejs_compat"] in wrangler.toml. Miss it and your Worker won't even boot — you get zlib is not defined.

main = "src/worker.ts"
compatibility_date = "2026-03-01"
compatibility_flags = ["nodejs_compat"]

Pitfall 3: KV Same-Key Write Rate Limit

KV limits you to roughly one write per key per second. If you parallelize aggressively and two writes hit the same key simultaneously, one can silently drop (no error, just no write).

The fix is key design. Use revenue:YYYY-MM-DD:platform so parallel tasks are always writing different keys. Don't try to share a key across platforms.

Pitfall 4: Multi-Currency Chaos in AdMob

If your apps are configured in different currencies, AdMob's report mixes them. Summing USD and JPY rows gives a meaningless number.

Always include LOCALIZED_CURRENCY_CODE in your dimensions. Aggregate per-currency, then convert to a base currency with an exchange-rate API before summing.

Pitfall 5: "Yesterday's" App Store Data May Not Exist Yet

App Store Connect daily data closes at UTC 00:00 and finalizes a few hours later. If your cron runs at JST 00:00 (UTC 15:00), yesterday's data is almost certainly not there, and you'll get 404s.

Schedule the cron for JST 07:00 or later. JST 09:00 is the sweet spot for reliability.

Design Lessons from Running This for Six Months

A few notes from actually operating the system.

Idempotent re-aggregation: Apple occasionally revises past data (refunds, returns). Your batch should accept a days=N argument and re-fetch the last week on demand. It makes month-end reconciliation much easier.

Failure-notification thresholds: Don't alert Slack on every failure. Use a "two consecutive failures" rule, or you'll train yourself to ignore morning alerts. Real outages get buried among transient 5xx noise.

Cross-checking the totals: I ran the same idea in Python for eight weeks and wrote it up in a daily App Store Connect and AdMob revenue pipeline. Different language, same potholes — empty report days, rate limits, timezone edges.

Cost visibility: The Workers free tier is generous, but KV reads grow quickly. If your dashboard gets any traction on social, you can brush up against the limit. Keep wrangler tail and Analytics within reach.

Bonus: Letting Claude Summarize Yesterday in Plain English

The final polish: ask Claude to describe yesterday's numbers in one or two sentences and post it to Slack. A line like "AdMob was 20% below the 7-day average yesterday — probably worth checking inventory or eCPM" turns a wall of numbers into an instant gut-check.

import Anthropic from '@anthropic-ai/sdk';
 
async function generateInsight(rows: any[]): Promise<string> {
  const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
  const response = await client.messages.create({
    model: 'claude-haiku-4-5-20251001',
    max_tokens: 300,
    messages: [{
      role: 'user',
      content: `Here are the last 7 days of app revenue. If yesterday looks unusual, say so in 1-2 sentences with a concrete action. No number dumps — just actionable insight.\n\n${JSON.stringify(rows, null, 2)}`,
    }],
  });
  return response.content[0].type === 'text' ? response.content[0].text : '';
}

The general idea of splitting models by job — a cheap one for orchestration and summaries, an expensive one for the hard part — is laid out in the Haiku 4.5 orchestrator and Opus worker pattern.

Why Haiku 4.5: The task is summarizing seven numbers in one or two sentences. Opus or Sonnet is overkill. Haiku 4.5 handles it naturally for roughly $0.0001 per call. Running it 30 times a day costs under a dollar a month.

Backfilling Historical Data

The cron only captures data going forward. When you first deploy, you'll want several months of history so the dashboard isn't empty. Here's the pattern I use.

// src/backfill.ts
export async function backfillAppStore(
  env: Env,
  startDate: string,
  endDate: string,
): Promise<void> {
  const jwt = await generateAppStoreJWT({
    issuerId: env.ASC_ISSUER_ID,
    keyId: env.ASC_KEY_ID,
    privateKey: env.ASC_PRIVATE_KEY,
  });
 
  const dates = enumerateDates(startDate, endDate);
  for (const date of dates) {
    // Serialize to respect Apple's rate limits.
    try {
      const rows = await fetchAppStoreSales(jwt, env.ASC_VENDOR_NUMBER, date);
      await env.REVENUE_KV.put(`revenue:${date}:appstore`, JSON.stringify(rows));
      await sleep(1000); // be polite
    } catch (err) {
      console.error(`Backfill failed for ${date}:`, err);
    }
  }
}
 
function enumerateDates(start: string, end: string): string[] {
  const dates: string[] = [];
  const s = new Date(start);
  const e = new Date(end);
  for (let d = new Date(s); d <= e; d.setDate(d.getDate() + 1)) {
    dates.push(d.toISOString().slice(0, 10));
  }
  return dates;
}
 
function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

Expose this behind an authenticated endpoint, not the cron. Backfills are long-running, and you want to run them deliberately, not on a schedule.

Small Operational Habits That Paid Off

Six months in, the things that actually mattered weren't big systems. They were these two.

Observability without a paid service

You don't need Datadog or Sentry for a project this size. Cloudflare gives you enough to stay sane.

• wrangler tail for live logs during debugging.
• Workers Analytics Engine for structured metrics — write a row per batch run with fields like platform, duration_ms, row_count, and query it from the dashboard.
• Workers Logs with Logpush if you want to fan logs out to R2 or a third-party service once you outgrow the free tier.

A minimal pattern I like: write a "batch health" KV entry per run.

await env.REVENUE_KV.put(
  `health:${new Date().toISOString()}`,
  JSON.stringify({
    ok: appStore.status === 'fulfilled' && adMob.status === 'fulfilled',
    appStore: appStore.status,
    adMob: adMob.status,
    duration_ms: Date.now() - startTime,
  }),
  { expirationTtl: 60 * 60 * 24 * 30 }, // 30 days
);

Then a tiny /health page reads the last 14 entries and flags any failures. Cheap, effective, and you can build it yourself in under an hour.

Currency Conversion for Cross-Platform Totals

Summing across platforms requires a shared currency. I recommend:

1. Store raw amounts per platform in their native currency.
2. Store a daily exchange-rate snapshot in KV: fx:YYYY-MM-DD keyed by currency pair.
3. Compute conversions at read time, not ingestion time.

Converting at read time means you can fix historical mistakes without re-running the batch. Fetch rates from a free source like the European Central Bank's daily feed or a paid service if you need weekend data.

async function loadFxRate(kv: KVNamespace, date: string, pair: string): Promise<number> {
  const data = await kv.get(`fx:${date}`, 'json') as Record<string, number> | null;
  // Fall back to the most recent rate if weekend/holiday
  if (data && data[pair]) return data[pair];
  for (let i = 1; i <= 5; i++) {
    const fallbackDate = new Date(new Date(date).getTime() - i * 86400_000).toISOString().slice(0, 10);
    const fallback = await kv.get(`fx:${fallbackDate}`, 'json') as Record<string, number> | null;
    if (fallback && fallback[pair]) return fallback[pair];
  }
  throw new Error(`No FX rate available near ${date} for ${pair}`);
}

Secrets management, so deploy day doesn't ruin your week

Don't paste your P8 key into wrangler.toml. Use wrangler secret put for anything sensitive — ASC_PRIVATE_KEY, ADMOB_SERVICE_KEY, SLACK_WEBHOOK_URL. These are encrypted at rest and never show up in logs.

When pasting a multi-line P8 key into a secret, replace newlines with \n literal characters, or use the file-based form wrangler secret put ASC_PRIVATE_KEY < key.p8. Be aware that Cloudflare trims trailing whitespace from secrets in some cases — your importPKCS8 call may fail with "Invalid key format" if the final newline is lost. Append one explicitly in code if needed:

const normalizedKey = env.ASC_PRIVATE_KEY.endsWith('\n')
  ? env.ASC_PRIVATE_KEY
  : env.ASC_PRIVATE_KEY + '\n';

This is the kind of detail that eats a Saturday afternoon when you deploy on Monday and everything breaks.

What I'd Build Next

A few ideas that would extend this into something more useful if the base pipeline is boring (which is the goal).

• Anomaly alerts: When today's revenue is more than 2 standard deviations below the 28-day mean, post a higher-priority Slack alert with recent AdMob eCPM trends attached.
• Cohort retention overlay: Pull DAU from App Store Connect Analytics Reports and overlay install-day cohorts on the same chart so you can see retention drop-offs correlate with revenue dips.
• Per-app P&L: Cross-reference with your infrastructure costs (Firebase, AWS, domain) so each app has a net-margin line, not just top-line revenue.
• Forecasting: Feed the last 90 days to Claude and ask it to project month-end totals based on weekday-adjusted trend. Claude is surprisingly good at rough forecasts if you give it the right framing.

Keep the base pipeline simple. Add complexity only when the absence is actually costing you something. That's how indie dev stays sustainable — by not building features you don't need.

One more practical detail: version your KV schema. Write the shape version into each record like { schema: 2, data: [...] }. When you inevitably want to add a new field, readers can fall back gracefully on old entries instead of crashing on missing keys. This trivial habit has saved me twice already during schema migrations.

Your Next Step

Don't try to implement all of this at once. Start with one thing: get App Store Connect's JWT auth to return a 200 on Sales Reports. Once that single request works, the remaining 70% of the project is variations on the same pattern.

If you get stuck on auth, drop into Claude Code's Plan Mode and tell it "I'm getting a 401 on App Store Connect's JWT auth — let's narrow down the cause together." That's exactly how I unblocked myself. The kid, the key format, the timing — one of those will be the culprit, and Plan Mode is good at isolating which.

Once all your indie revenue is on one screen, something else changes: you see which app to invest in next. The time you used to spend clicking between dashboards becomes the time you spend thinking about strategy. Six months in, I'd build this system again without hesitation.