mentijm

[naive wren]

👋 Thanks for reaching out
In fact yeah, your Webhook endpoints might occasionally receive the same event more than once. So you should making you event processing idempotent.
https://stripe.com/docs/webhooks/best-practices#duplicate-events
Creating a table with a uniq index on event_id is one of the solutions in fact.
Once you receive an event you store its id on that table and you set a status like 'treated', and you do a check when you receive a new event if you've already processed that event or not.
Or can design your integration in a way that you could do the same action twice without duplication. That will depends mostly on how you are designing your integration

[leaden narwhal]

Ok, if we were to create a table as an additional layer of safety (in case some webhook logic is not idempotent). Is the status like 'treated' needed?

Would it be wise to record the event in the table as soon as we received it? And then we schedule the jobs that has to be done (which might retry etc)

[naive wren]

Would it be wise to record the event in the table as soon as we received it?
Yes I agree you should record the event as soon as you receive it, respond with success as soon as possible and then do any complex treatment later.
https://stripe.com/docs/webhooks#acknowledge-events-immediately:~:text=Your endpoint must quickly return a successful status code (2xx) prior to any complex logic
That's way you can introduce the status logics, received, treated... all of this is just my personal opinion and don't hesitate to complete or challenge this approche, because again it mostly depends on how you design your integration