#usamarashad-idempotency-keys
edgy nexusBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- usamarashad, 37 minutes ago, 4 messages
- usamarashad, 1 hour ago, 8 messages
- usamarashad, 3 hours ago, 12 messages
- usamarashad, 5 hours ago, 17 messages
- usamarashad, 8 hours ago, 16 messages
- usamarashad-webhooks, 20 hours ago, 16 messages
and 5 more
tacit atlas
Not really no
Our docs just describe how to use them
What part is confusing?
Perhaps I can assist
finite socket
ok. it;s not confusing, its just that i dont see why I would need to use them in my application. In my application I have express endpoints which create subscriptions and one time payment intents. As I understand the endpoint is triggered only once when the client requests for the relevant action. Where would the idempotency keys fit in?
tacit atlas
It's for safely retrying requests
If some action fails, you can run retries without accidentally creating 2 charges, etc
It's not a stripe-specific concept
Also recommend reading https://stripe.com/blog/idempotency
finite socket
ok i will read this
edgy nexusBOT
finite socket
so does it mean that the idempotency key should be send by the frontend as a session key all the way down to the back-end. And as long as the front-end is active it should send this session key with every create object request?
lyric plume
hey ther ejust stepping in for @tacit atlas who needs to step away
finite socket
Sure
lyric plume
It depends on your integration details, but typically I'd say this is something you'd only used server-side to manage retry logic
For example, our built-in SDK network retry feature uses idempotency keys
finite socket
Noted. I will think this over. Thanks for your help
lyric plume
NP!
finite socket
The other point here I would like to bring to your attention is that all the code which we have written that generates or updates objects is inside a "try catch" block
so I would assume that if something does go wrong with the network and lets say a product price creation failed, then the try catch block would hit an error and nothing would be created. Right?
so the product creation can be retried again without the idempotency key..