#fadi obaji - webhooks

1 messages ยท Page 1 of 1 (latest)

fringe mountain
#

Can you provide some context for what you mean here?

analog igloo
#

We're using webhook events to update our DB to start the users' subscription after successful payments depending on the webhook event we're receiving

#

as well as any update to the subscription status

#

also storing the subsciption object returned in the event's payload to minimize the API calls when we want to get the subscription info and display it to the user

#

so you can see our concern, that's why i'm asking are there a robust way to update our DB

#

?

#

not only subscriptions tho, we're letting users adding payyment methods to their account as well, so we're also relying on the webhooks for that as well

fringe mountain
#

Yep, webhooks are a great option for this. Depends on your request patterns you can also handle some actions synchronously when your requests succeed, but in terms of client completed payments yes the webhooks are what we recommende

analog igloo
#

Yeah I could update the DB on successful requests but then I thought nope, because I need the created field to update the updated field in my DB, because I only update the DB if the created field in the received event is greater or equal to the updated field in the DB

#

to prevent older events replacing new ones

#

is this a good approach?

#

because I tested the webhook system, if you resend an older event, the event will get sent exactly as it is, not the updated one of it

fringe mountain
#

if you're referring to out-of-order events where you rely on some that arrive in close succession, another approach here is to use the event/type as a signal but then always load the object from the API to ensure you get the latest version, instead of using the event payload directly

#

ah yea resending old events would have similar stale data issues, yes

analog igloo
#

I'm talking about events of the same type, let's say the event customer.subscription.updated

#

can I rely on the created field of the event to determine if it's newer or older than the one i saved in the DB?

fringe mountain
#

well, created shouldnt change for a given subscription. Can you explain what youre trying to solve for here?

analog igloo
#

okay let me show you some code

#

one sec

#

that one for example

#

notice the $event->created

#

still here ๐Ÿ˜ข

vestal yew
#

Hey ๐Ÿ‘‹
synthrider had to step away but I can take over from here
give me some time to catch up on the threads
Thanks

analog igloo
#

okay!

charred oar
#

So yes, you can rely on the event->created timestamp of a subscription like that

#

If I understand your question correctly

#

It can help determine the order of events on the same object

analog igloo
#

Great! that's what I wanted to confirm, that the created field is accurate

#

thanks!