RevenueHog

// sdks

No SDK required. SDKs available.

Everything RevenueHog does (the live feed, MRR, churn, alerts) works with zero code in your app. The optional SDKs add one capability: user-level attribution, linking purchases to your own user IDs. Here's exactly what that looks like in Swift, React Native and Kotlin.

last updated 2026-07-11 · by revenuehog

The part that needs no SDK (all of it)

RevenueHog reads your revenue server-side: an App Store Connect API key imports every app on it with about a year of daily history, and Apple's Server Notifications V2 stream events in real time. Nothing ships in your binary, no release is needed, and if you never install an SDK you still get the entire product. That's the architecture, not a free-tier limitation.

What the server-side view can't know is which of your usersa purchase belongs to. Apple's data identifies subscriptions, not accounts, so RevenueHog derives anonymous, stable customers from transactions (how that works). The SDKs exist to upgrade those: an identify + attribute call links transactions to your user ids, and anonymous history re-attributes automatically after login.

status

The packaged SDKs (Swift Package, npm, Maven) ship soon. They're not published yet, so there are deliberately no install commands on this page. The API is open today: the snippets below are the real integration surface, and the raw-HTTP section works right now.

Swift (iOS 15+, StoreKit 2)

One line at launch. The SDK listens to StoreKit 2 transaction updates and attributes verified purchases automatically: zero dependencies, never crashes your app (every failure is swallowed into a debug log), offline-safe with a persisted retry queue.

Swift · the whole integration
import RevenueHog

@main
struct MyApp: App {
    init() {
        RevenueHog.configure(apiKey: "pk_live_…") // ← the one line
    }
    var body: some Scene { WindowGroup { ContentView() } }
}

// The SDK listens to StoreKit 2 Transaction.updates (plus current
// entitlements once at launch) and attributes every verified
// transaction automatically, to a persisted anonymous id, until:
RevenueHog.identify(userId: "user_42")
// …after which everything reported anonymously re-attributes to user_42.

RevenueHog.setAttributes(["plan": "pro", "cohort": "2026-07"])
RevenueHog.reset() // on logout: fresh anonymous id

React Native / Expo

Pure TypeScript, no native modules. Works in Expo Go. Hooks react-native-iapautomatically when it's installed, or take manual control from your own purchase listener.

React Native · the whole integration
import RevenueHog from '@revenuehog/react-native';

RevenueHog.configure({ apiKey: 'pk_live_…' }); // ← the one line

// With react-native-iap installed, purchases attribute automatically.
// Or wire it manually from your own purchase listener:
purchaseUpdatedListener((purchase) => {
  RevenueHog.attributePurchase({
    originalTransactionId:
      purchase.originalTransactionIdentifierIOS ?? purchase.transactionId!,
    productId: purchase.productId,
  });
});

await RevenueHog.identify('user_42'); // links prior anonymous reports
await RevenueHog.setAttributes({ plan: 'pro' });

Kotlin / Android

Zero dependencies (platform HTTP + JSON), minSdk 24. To be direct about what it's for: RevenueHog ingests Apple revenue today. The Android SDK provides identity parity across your platforms and stores Play purchase mappings for potential future Play ingestion.

Kotlin · the whole integration
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        RevenueHog.configure(this, "pk_live_…") // ← the one line
    }
}

// When you know who the user is:
RevenueHog.identify("user_42")
RevenueHog.setAttributes(mapOf("plan" to "pro"))

// Play Billing purchases (stored for future Play ingestion;
// RevenueHog ingests Apple revenue today):
RevenueHog.attributePurchase(
    purchaseToken = purchase.purchaseToken,
    productId = purchase.products.firstOrNull(),
)

Authentication

Everything authenticates with your organization's publishable key from settings → api (pk_live_…). It's safe to ship in the app binary: it can only write identity data, never read revenue, and it's rate-limited per organization. Wire-level details (payload schemas, limits, CORS) live in the SDK reference.

With and without the SDK

You wantSDK needed?
Revenue dashboard, MRR, churn, trialsNo. The .p8 key covers it
Live feed of purchases, renewals, churnNo. Apple's Server Notifications cover it
Push alerts and widgets on your phoneNo. Server-side + the iOS app
Event forwarding to your own backendNo. Configured per app in the dashboard
Customer profiles & LTVNo. Derived from transactions (anonymous but stable)
Know which of your users made a purchaseYes: identify + attribute
Device model / OS / locale on profilesYes
Custom attributes (plan, cohort, …)Yes

No SDK at all: the raw HTTP calls

The SDKs are ~500-line conveniences over two endpoints. Any HTTP client, including your backend, can integrate today:

curl · identify + attribute against the live API
# identify: upsert a user (repeat calls merge attributes)
curl -X POST https://revenuehog.dev/api/sdk/v1/identify \
  -H "Authorization: Bearer pk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "appUserId": "user_42",
    "bundleId": "com.example.app",
    "platform": "ios",
    "attributes": { "plan": "pro" }
  }'

# attribute: link a StoreKit transaction to that user
curl -X POST https://revenuehog.dev/api/sdk/v1/attribute \
  -H "Authorization: Bearer pk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "appUserId": "user_42",
    "bundleId": "com.example.app",
    "originalTransactionId": "2000000123456789",
    "productId": "com.example.app.pro.monthly"
  }'

Semantics worth knowing

identify upserts: repeat calls shallow-merge attributes and update device fields. attribute re-points: sending the same originalTransactionId with a new appUserIdmoves the transaction. That's the entire anonymous-to-real-user aliasing mechanism. Rate limit: 240 requests/minute per organization, 429 + retry-after beyond it. Full schemas in the SDK reference.

FAQ

Do I need an SDK to use RevenueHog?
No, and that's the point. Revenue, the live feed, MRR/churn metrics, customers and push alerts all work server-side from your App Store Connect key and Apple's Server Notifications. The SDKs add exactly one thing: knowing which of your users a purchase belongs to.
Where do I install the packages?
The packaged SDKs (Swift Package, npm, Maven) aren't published yet. They ship soon. The API they call is open today: the code above is the real integration surface, and the raw-HTTP calls below work right now with your publishable key. When the packages land, swapping raw calls for the SDK is renaming, not rearchitecting.
Is the publishable key safe to ship in my app?
Yes. The pk_live_… key (dashboard → settings → api) is public by design: it can only write identity/attribution data, never read revenue. Writes are rate-limited per organization.
What data do the SDKs send?
Only: your user id (or an anonymous UUID before login), bundle id, OS version, device model, locale, and attributes you explicitly pass. No IDFA, no fingerprinting, no receipt payloads. Undeliverable requests retry with backoff and queue offline; a failure is never allowed to crash your app.
Why is there a Kotlin SDK if RevenueHog is Apple-only?
Identity parity. RevenueHog ingests Apple App Store revenue today; the Android SDK exists so the same user has one identity across your platforms, and attributePurchase stores the Play purchase→user mapping server-side now, so history lights up if Play ingestion ships later.

Start without any of this: connect a key, free. Add attribution later if you ever want it.

// related