#cipater - Afterpay
zenith crescent
Can you share an example event ID? Many events are generated asynchronously unrelated to any specific API request, and would be expected to not have this.
ID of the API request that caused the event. If null, the event was automatic (e.g., Stripe’s automatic subscription handling).
https://stripe.com/docs/api/events/object#event_object-request-id
What are you trying to do with this key?
hollow harbor
Here's an example event: evt_3KW5e3Itk6ybx3Jp29sZoKUa
Since webhooks can be sent multiple times for various reasons, I'm using the idempotency_key to keep track of which events I've handled. To be, well, idempotent. I was initially using the event id itself, but discovered that new ids are used for each attempt. So the idempotency_key was the only thing that I've found to be stable across retries.
zenith crescent
Hmm this doesnt sound quite right
I was initially using the event id itself, but discovered that new ids are used for each attempt.
You should be using the event ID as you described
Where are you seeing unique event id on retries? This would be highly unexpected.
hollow harbor
I'm not able to find the original set of payment intents that led me to that conclusion. But I recall that at the time, my server was returning HTTP status of 500 for some events, and seeing unexpected errors on my end upon retries because of (what appeared to be) unique event IDs. In other words, I'm fairly confident that I saw two unique event IDs for e.g. charge.succeeded , but both had the same idempotency_key
I was juggling a variety of IDs in attempting to chase down the bug, so I suppose it's not impossible my "eyes got crossed" somewhere along the way. But I strongly recall being very confused about what I was seeing, because as you said, it was highly unexpected.
proud flame
catching up here one sec
hollow harbor
no worries.
This doesn't mention "event ID" specifically, but does at least seem to imply that the event (and therefor it's ID) can be used to de-dup... but man, I'm so certain I came across a case where that just didn't seem to be true. 🤷
proud flame
ok caught up and my read was the same as synthrider that you should be using the Event ID to reconcile if you've seen an event or not, not the idempotency key
so when you say
I was initially using the event id itself, but discovered that new ids are used for each attempt.
AFAIK that shouldn't be possible. when I've seen duplicate events, theyr'e the same event being sent twice, so same ID, same body etc
hollow harbor
Hmm, interesting. Okay, well, I'll go back to using the event ID, and keep an eye out for anything unexpected. Thanks for the help. 👍