Too few APIs offer an idempotency guarantee, especially so many years after @stripe led the way. In many cases this is really the only way to make it possible (and much easier) for your API users to build a robust integration that can handle common distributed systems edge cases, application bugs, and retries, all without accidentally generating duplicate work or costing additional money. When I was recently evaluating transactional email API providers for River’s customer billing service, I could only find *2* offerings with idempotent email send APIs: @MailPace and @UseWaypoint. None of the others made it easy to guarantee that my system didn’t accidentally generate duplicate onboarding or notification emails to spam my customers by mistake. Idempotency should be the default in modern APIs, not a rare exception! It’s a problem I’ve faced again and again when integrating with 3rd party APIs or even when sending events between internal systems. River offers built in unique job features to make it easy to implement this in your API, but there are many ways to build this kind of capability. Check out the blog post in the reply 🔗