Posts

Post marked as solved
2 Replies
867 Views
The notification webhook is marketed as a way to get server-side updates on changes to in-app subscriptions. In the normal case, you can use that information to know the current state of a subscription. However, the retry system means that a notification may come up to 72hrs after the actual state change occurred and that also means that notification may be out-dated (another state change occurred between the time it was intended to be sent and the time it actually got successfully sent). How are we supposed to ensure that a received notification is the current state of a subscription? Can we used the signedDate to determine the order of notifications? (ie. when a notification fails to be sent and is resent, is the signedDate not altered so it can be used to order the notifications?) Or do we need to always make a request to the /inApps/v1/subscriptions/ endpoint to get the latest state and not rely on the contents of the notification?
Posted
by magnawut.
Last updated
.