# RevenueCat affiliate attribution for iOS subscriptions: a server-side pattern

> A server-side attribution layer can credit affiliates for RevenueCat-powered subscriptions while RevenueCat stays the source of truth for entitlements.

Published: 2026-07-20 · Last reviewed: 2026-07-20

## Two jobs, cleanly separated

RevenueCat answers one question well: is this customer entitled right now? It manages subscription state, receipts, and the entitlement your paywall checks. Affiliate attribution answers a different question: which partner drove this subscription, and what commission is owed after refunds. Those are separate concerns, and keeping them separate is what lets each stay simple.

Attribloom does not replace RevenueCat and does not ship a native RevenueCat plug-in. The pattern below is a server-side integration you own: RevenueCat remains the entitlement source of truth, and the attribution layer reads Apple's own signals to assign commission.

## The pattern

The attribution key is the StoreKit 2 appAccountToken. When a referred user is about to buy, your app fetches an Attribloom-issued token from the bind endpoint and sets it on the purchase. Apple returns that token in the signed transaction and in every App Store Server Notification for the subscription. You keep using RevenueCat exactly as before to unlock features.

- Bind on first launch: fetch the Attribloom-issued appAccountToken and persist it.
- Set that token on the StoreKit 2 purchase option.
- Let RevenueCat manage entitlements from its own receipt handling, unchanged.
- Forward App Store Server Notifications v2 to Attribloom so it can confirm and reconcile commission server-side.

## Why not attribute from RevenueCat data alone

You could try to derive attribution from RevenueCat webhooks, but the durable, forgery-resistant key is the appAccountToken carried in Apple's signed notifications. Attribloom re-verifies Apple's JWS chain independently, so commission never depends on trusting a client or a third-party callback for the money path.

If your app has no server that receives Apple notifications, point your App Store Server Notifications v2 URL at your own endpoint and forward each signed payload. RevenueCat can still receive its own copy for entitlements. The two consumers do not conflict.

## Frequently asked

### Does Attribloom have a native RevenueCat integration?

No. This is a server-side pattern you implement. RevenueCat stays the entitlement source of truth, and Attribloom attributes commission from the StoreKit 2 appAccountToken and App Store Server Notifications v2.

### Will setting an appAccountToken interfere with RevenueCat?

No. The appAccountToken is a purchase option that Apple echoes back for attribution. It does not change how RevenueCat validates receipts or grants entitlements.

### Where does the token come from?

From Attribloom's bind endpoint, which mints it against a specific affiliate. Your app must not invent its own UUID, because a self-generated token attributes to no affiliate.

## Primary sources

- [Apple: appAccountToken](https://developer.apple.com/documentation/appstoreservernotifications/appaccounttoken) · checked 2026-07-20
- [Apple: Product.PurchaseOption appAccountToken(_:)](https://developer.apple.com/documentation/storekit/product/purchaseoption/appaccounttoken(_:)) · checked 2026-07-20
- [Apple: enabling App Store Server Notifications](https://developer.apple.com/documentation/storekit/enabling-app-store-server-notifications) · checked 2026-07-20

## Next steps

- [StoreKit 2 integration guide](/guides/ios)
- [iOS affiliate tracking without an SDK](/learn/ios-affiliate-tracking-without-sdk)
