Settings reference

Settings has six tabs: Connections, Workspace, Preferences, Notifications, MCP and Team. This page lists every section and what it controls, with links to the pages that cover each in depth.

App Store Connect credentialsCopy Anchor Link

Four values connect RevenueHog to Apple: the .p8 private key file, the Issuer ID, the Key ID, and your Vendor Number. The first three authenticate; the vendor number is the account Apple files your sales reports under, so without it there is no revenue or subscription history to pull. They live under Settings → Connections → APP STORE CONNECT. The private key is encrypted at rest (AES-256-GCM, authenticated) and scoped to your workspace; the dashboard only ever shows whether a key is present, never its contents.

Saving credentials starts a sync immediately, so you do not have to wait for the next daily run to see anything. It also runs the key capability check.

To rotate a key, generate a new one in App Store Connect and re-upload it. Editing the identifiers alone keeps the stored key. See Connect App Store Connect for where to find each value.

Validation messages you may see:

Related surfaces: Settings → Notifications holds your push rules (event toggles workspace-wide and per app, minimum amount, quiet hours, MRR milestones, per-app mutes, the daily digest, new-app and review alerts, the alert sound and how notifications stack on your phone), and Settings → Connections → SDK DEVICES lists the App Attest enrollments the optional SDKs create for user-level attribution, with per-device revoke. See Notification preferences.

The key capability matrixCopy Anchor Link

Saving credentials (and the Re-check button next to them) runs a sweep of read-only probes against App Store Connect and records what your key's role unlocks. The matrix renders the result feature by feature: revenue reports, payout reports, analytics, TestFlight, webhooks and auto-wiring, each marked AVAILABLE, MISSING or UNKNOWN. Read-only keys are a fully supported choice; a missing row is a preview of what a broader role would add, never an error. API key roles maps roles to rows.

MISSING means Apple answered the probe with 403: the key is valid but its role lacks that access, and the row says which role fixes it. UNKNOWN means the probe could not run or could not classify Apple's answer; the row's note explains why, for example "Add a vendor number to check report access." or "No imported app to probe against yet. Re-check after your first sync." If Apple rejects the key outright (401), the matrix shows no per-feature states at all, because every row would fail for the same reason, and instead asks you to confirm the Issuer ID, Key ID and .p8 file.

Two deliberate subtleties. A report probe that finds no report posted for the checked period still counts as access ("No report was posted for the probe period, but access was accepted."), because a missing role answers 403 where a missing report answers 404. And auto-wiring is never probed, because the only honest probe would be the write itself; it shows as detected on first use ("Resolved on the first auto-wire attempt."), or immediately as available when the key is Admin, which can write everything.

New app discoveryCopy Anchor Link

RevenueHog re-checks App Store Connect several times a day, so an app you ship later turns up on its own. What happens next is the auto-wire switch under Settings → Preferences → APPS.

On, a newly discovered app is wired the moment it appears: RevenueHog points Apple's server-notification URLs at itself and keeps whatever URL was there as a forwarding endpoint, so an app that was already reporting to your own server keeps doing exactly that. Off, discovery only sends you a notification and touches nothing until you say so. Either way this writes to App Store Connect, so it needs a key with the App Manager or Admin role; a read-only key reports that specifically rather than failing, and the capability matrix shows auto-wiring as missing. Changing it requires an owner or admin.

Refund requestsCopy Anchor Link

When a customer asks Apple for a refund, Apple sends a consumption request and gives you a chance to state a preference. Settings → Preferences → REFUNDS decides how RevenueHog answers on your behalf, workspace-wide, and any app can override it on its own detail page.

The default is undeclared, and it is deliberately inert: RevenueHog does not answer Apple at all, so the refund is decided exactly as it would be if RevenueHog were not in the loop. The other three (prefer grant, prefer decline, no preference) are sent to Apple as a preference, not a decision. Apple still decides. An unrecognized stored value falls back to undeclared, because answering Apple on a value RevenueHog does not understand is worse than not answering.

TeamCopy Anchor Link

A workspace can have owners, admins and members. Invited people get an email link. Admins manage members and other admins; only an owner can manage owners; a member sees the roster and asks an owner or admin for changes. Notification rules are per person, so nothing you change here changes a teammate's alerts. See Team and roles.

Apple Small Business ProgramCopy Anchor Link

Apple's standard split gives developers 70% of revenue (a 30% commission). Members of the App Store Small Business Program keep 85% (a 15% commission). Your report-derived revenue needs no setting for this: Apple's daily Sales reports state proceeds at your actual commission rate (membership included) and RevenueHog uses Apple's figures as-is, with no adjustment on top.

The Small Business toggle under Settings → Preferences → SMALL BUSINESS controls the one surface that has to guess: the live feed. Real-time events arrive via Apple Server Notifications, which carry the customer price but not your proceeds, so each event's detail page estimates proceeds from that price. Apple takes 30% by default, or 15% with the toggle enabled.

The toggle takes an optional admission date. Set it and the reduced rate applies only to events on or after that day, because joining the program does not retroactively repay old sales. Leave it blank and the whole history is treated as enrolled.

Per-app forwarding endpointsCopy Anchor Link

Each app can define a Production and a Sandbox forwarding URL. When Apple posts a notification to RevenueHog, it verifies the signature, records the event, then re-POSTs Apple's exact signed payload to your URL for the matching environment, so your own server validates it as if it came straight from Apple.

Leave a URL blank to record events in RevenueHog without forwarding them. Delivery attempts and their HTTP results are listed under each app's recent events and summarized on the webhooks page. See Forwarding and Server notifications.

Other Connections sectionsCopy Anchor Link

Billing and the Alerts subscriptionCopy Anchor Link

RevenueHog is free on the web: every app, full history, the live feed, metrics, customers, event forwarding, and the one-click server-notification wiring. There are no tiers and nothing to upgrade.

The one paid thing is RevenueHog Alerts, an auto-renewable subscription purchased inside the iOS app. It unlocks visible push notifications (event alerts, MRR milestones and the daily digest) for everyone in your workspace. Its status shows on the Billing page; manage or cancel it through your App Store subscriptions. See Billing.

Clearing credentialsCopy Anchor Link

Settings → Connections → DANGER has Clear credentials…, which removes the stored .p8 key and identifiers and stops the daily sync. Everything already imported stays exactly where it is; new data simply stops arriving. It asks for confirmation first, and re-uploading a key resumes syncing.

This differs from Settings → Workspace → DANGER, which deletes your whole account. See Delete your account.

MCP tokensCopy Anchor Link

Settings → MCP creates and revokes personal access tokens for MCP clients. See MCP server.