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.