Question

User's entitlements are missing immediately after a TRANSFER event

  • 23 February 2022
  • 13 replies
  • 171 views
B
Userlevel 1
Badge +4

I am attempting to keep my database up to date with my users’ subscription states via RevenueCat’s webhooks. When my server receives an event from RC, it extracts the `app_user_id` and immediately hits the /subscribers API endpoint to fetch the new subscription info for that user and save it to my database. This seems to be working for new subscriptions, renewals, and cancellations.

I am running into an issue with the `TRANSFER` event type, however. I can trigger this event by logging out one of my users, logging into a new account, and restoring purchases. The Apple ID remains the same throughout, and I correctly log in/out to the Purchases SDK at the correct times, so RC (correctly) transfers the entitlements over to the new user ID.

I receive the `TRANSFER` event via webhook, and handle it as a special case. Instead of simply extracting and refreshing the `app_user_id` (which isn’t present), I check the user IDs in `transferred_from` and `transferred_to`. The user IDs are then sent as usual to the `/subscriptions` endpoint for their current state.

At this point, though, I find that both users have no entitlements. The `subscriber.entitlements` property is empty. I would expect it to be empty for the user ID that was `transferred_from`, but I would expect it to be populated for the user that was `transferred_to`. In fact, if I wait a few moments and hit the `subscribers` endpoint again manually, I see the entitlements correctly included. But by this point it is too late - my server has already responded to the event by pulling the latest subscriber info and updating my user to have no entitlement. 

Is this expected behavior? Shouldn’t the subscriber state provided by the API be up-to-date before the webhook fires? How should I be handling this? Perhaps some artificial delay before I fetch the user’s subscription info? If so, how long?

13 replies

joshdholtz
Rank
Userlevel 3
Badge +5

Hey @Ben Packard!

I did did some research and asked around and it looks like at the time of the webhook, the entitlements should be available through the `/subscriptions` endpoint. Do you happen to know exactly how long it takes for you to see the transferred entitlements? Is it a few seconds or more like a few minutes?

Thanks!

B
Userlevel 1
Badge +4

I want to say seconds rather than minutes, but I will do some more testing to confirm and get back to you.

B
Userlevel 1
Badge +4

Yes I can confirm it is a matter of a second or two at most. I validated this by logging from my webhook function that receives the event and confirming that the transferred-to user does not have the entitlement when I hit /subscribers in response to that event, while simultaneously refreshing the same /subscribers endpoint manually in Postman. The entitlement is there almost immediately, but not early enough for the webhook event.

I am testing in the Sandbox if that makes any difference.

 

joshdholtz
Rank
Userlevel 3
Badge +5

Hey @Ben Packard,

Thanks for confirming that! And just for clarification, is this the endpoint you are hitting after your receive the webhook? https://docs.revenuecat.com/reference/subscribers

Thanks!

B
Userlevel 1
Badge +4

Yep that’s the one. 

B
Userlevel 1
Badge +4

For now I have added a short delay on the serve-side before I fetch from /subscriptions. 1s seemed to work but I have gone with 3s.

joshdholtz
Rank
Userlevel 3
Badge +5

Hey @Ben Packard,

Glad that’s working! I did ask somebody more experience in our backend look into this because this does indeed seem like an issue on our side. Our docs instruct to hit the API right away so this data should be there.

I’ll reach back out when we have some more information on what’s going on!

Thanks again for reporting this!

B
Userlevel 1
Badge +4

Thanks for all the help @joshdholtz 

joshdholtz
Rank
Userlevel 3
Badge +5

@Ben Packard My pleasure 😊 

Oh, one thing if are able to get this! Would you be able to send us what the full response looks like with the entitlements missing? That will help out the team when looking into this.

Thanks!

B
Userlevel 1
Badge +4

Sure, First here is the webhook event as recorded by the dashboard:

{
  "api_version": "1.0",
  "event": {
    "app_id": "appdb16aed845",
    "event_timestamp_ms": 1645817299228,
    "id": "18E16D6B-ABDA-4F47-B923-5895EDCAD2E4",
    "store": "APP_STORE",
    "transferred_from": [
      "$RCAnonymousID:c06ef5da3dfd4b1388540018dec5654f",
      "116gnlmhbJ"
    ],
    "transferred_to": [
      "$RCAnonymousID:34ddf83ca1784236bffddd1a3655743a",
      "$RCAnonymousID:7342cc997a39478b94fc9e602d784933",
      "$RCAnonymousID:dbc046977723419fabd37233b5dd47cf",
      "0GEk2QeFbh"
    ],
    "type": "TRANSFER"
  }
}

The two non-anonymous IDs (116gnlmhbJ and 0GEk2QeFbh) are then sent to /subscriptions.

Fetching 116gnlmhbJ (transferred FROM) returns the following. Note that the original_app_user_id displayed in the response is an annonymous ID that is an alias of 116gnlmhbJ - I actually have another ticket open about why I am creating so many anonymous users. But for our purposes, we know this is the account the entitlement was transferred FROM, and entitlements is empty as expected.

{
	request_date: '2022-02-25T19:28:19Z',
	request_date_ms: 1645817299469,
	subscriber: {
		entitlements: {},
		first_seen: '2022-02-16T22:01:45Z',
		last_seen: '2022-02-25T15:26:48Z',
		management_url: null,
		non_subscriptions: {},
		original_app_user_id: '$RCAnonymousID:c06ef5da3dfd4b1388540018dec5654f',
		original_application_version: '1.0',
		original_purchase_date: '2013-08-01T07:00:00Z',
		other_purchases: {},
		subscriptions: {}
	}
}

Fetching 0GEk2QeFbh (transferred TO) looks as follows. Note that the entitlements object is empty, which is not expected. If I introduce a short delay before running this fetch, the entitlement is populated as expected.

{
	request_date: '2022-02-25T19:28:19Z',
	request_date_ms: 1645817299411,
	subscriber: {
		entitlements: {},
		first_seen: '2022-02-23T19:20:26Z',
		last_seen: '2022-02-25T14:33:14Z',
		management_url: null,
		non_subscriptions: {},
		original_app_user_id: '0GEk2QeFbh',
		original_application_version: '1.0',
		original_purchase_date: '2013-08-01T07:00:00Z',
		other_purchases: {},
		subscriptions: {}
	}
}

 

joshdholtz
Rank
Userlevel 3
Badge +5

@Ben Packard Thank you so much! We’ll let you know when we have this figured out 😊 

joshdholtz
Rank
Userlevel 3
Badge +5

Hey @Ben Packard!

Just wanted to let you know that our backend team deployed a fix for the latency you were seeing with the API response immediately after the webhook.

If you are able to verify that the data is there immediately after the webhook if/when you get a chance and would be great 😊 

Thanks!

B
Userlevel 1
Badge +4

Thanks to the team for the speedy turnaround @joshdholtz, I just launched my subscription so I’m not going to touch anything for the moment but I will try removing the delay the next time I’m in there tinkering.

Reply


Terms & ConditionsCookie settings