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!

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

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.

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!

Yep that’s the one. 

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.

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!

Thanks for all the help @joshdholtz 

@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!

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: {}
	}
}

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

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!

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.