inexorable-events

[upbeat summit]

FWIW ignoring the event and retrieving it from the API is what I recommend too, it has various advantages(it lets you use expand to get more information to use in reconciliation, and it helps for cases where you get events arriving out of order). So that is normal enough.

event.created is the time the Event object is created, which has no direct relation to event.data.object.created (which is the creation time of the API object (e.g. Subscription) that the event is notifying about.

When I receive an event that contains a Subscription object, I simply want to be able to determine if it's older or newer than the version of the Subscription I already have in my D
to me the best approach here, for a customer.subscription.updated event, is to upon receipt of the event, retrieve the Subscription from the API and sync my database with whatever state that has, as that will be the latest state, while what's in the event might be a snapshot that is older and has arrived out-of-order.

but yeah there is no simple perfect answer here, it's a common and valid problem not really addressed with our webhook system. The alternative here is to do something like push the events to a queue, sort it by event.created and work through them in order, but it seems brittle to me, and the timestamps are only precise to a second, so you can have ambiguity.

[willow lion]

Firstly, thank you for taking the time to reply - that's really appreciated. Secondly, you've probably just given me back the super-power of sleep. Can't wait for it to get dark now.

Of course, an incremental stamp, rather than a timestamp, would solve the problem wouldn't it? It wouldn't have to be eyeball friendly so could be long. Ticks representing midnight that day with an appended incremental integer for versions that day? Just thinking aloud.