Read on Twitter
We got some good questions from @ThijsNiks about idempotency in our API. I'll answer here along with some thoughts around API design https://twitter.com/ThijsNiks/status/1262977814019489792
First, a high level comment on API design. We've designed our API to be flexible for the developer, rather than enforcing a specific way you should build. While we want to steer people towards best practices, not everyone wants to build the same way. And that's fine
For anyone who doesn't know what idempotency is, it is the property of an operation that means if you try to do something twice, the result only happens once. It's why when you click the "Submit" button two times in rapid succession on a form, it is only submitted once
So we don't enforce idempotency as a requirement. Using idempotency keys is not essential to successfully creating objects in our API, so it is optional. However, it is best practice in production systems, especially around payments, to ensure you don't do the same thing twice
Another note for why it's optional is that it makes building against our API easier. If we forced developers to always pass a unique key, developers would have to make up keys unnecessarily, and potentially mutate their code to generate new keys for previously successful actions
We also only save idempotency keys for 24 hours. Some people have asked why not 72 hours, or 1 month, or N {period}. Any of these just shift the boundary out arbitrarily. The debate is really do you save them indefinitely or only for a predefined period of time
We save them for only 24 hours because we think the role of idempotency keys are to solve for short-term bursts of the same API calls, like what might happen if the same job fires on our customer's backend multiple times by accident.
Idempotency keys aren't meant to be an architectural crutch for our customer's systems. Our customers design their systems properly, independent of us saving the keys
We actually did explore saving idempotency keys indefinitely a few weeks ago. We decided not to, however, based on feedback from our customers similar to the thoughts above
