Email providers don’t usually provide idempotent API endpoints because they have no way to enforce that the email will be sent exactly once downstream.
The best you can do with email is at least once (and you can’t even really do that because of spam), so you should just build that assumption into your app. If 1 out of 100,000 emails gets sent 2x no one is going to care (as long as you include information the user can use to dedupe manually).
Maybe adding an idempotent send endpoint reduces that from 1 /100,000 to 1/150,000 or whatever, but is that worth the extra complexity? Is dropping your duplicate email rate from some very small number to some smaller number going to make enough money to pay for the extra dev time, and the extra lifetime maintainability burden? Almost certainly not.
You could make that argument for lots of services that have external side effects, but that’s about what happens after the service has been asked to do a thing (to send an email in this case).
However just because an action may be duplicated after the provider has been asked to do a thing, it does not eliminate the value of the provider being able to deduplicate that incoming request and avoiding multiple identical tasks on their end. Without API level idempotency, a single email on the client’s end could turn into many redundant emails at the service provider’s side, each of which could then be subject to those same subsequent duplications at the SMTP layer. And even then, providers can use the Message-Id header to provide idempotency in delivery as many do.
This is an unavoidable consequence of distributed systems where the client may not know if the server ever received or processed the request, and it may also occur due to client-side bugs or retries within their own software.
In other words, API level idempotency can help eliminate all duplication prior to the API; depending on the service, the provider may also be able to eliminate duplication afterward as well. So it’s strictly better than not having it, really not that difficult to implement, and makes it easier for integrators to build a robust integration with you.
albertgoeswoof|11 months ago
If you only need this for transactional email, you could use MailPace, we support idempotency out of the box: https://mailpace.com/features/idempotent-email-api
sarchertech|11 months ago
The best you can do with email is at least once (and you can’t even really do that because of spam), so you should just build that assumption into your app. If 1 out of 100,000 emails gets sent 2x no one is going to care (as long as you include information the user can use to dedupe manually).
Maybe adding an idempotent send endpoint reduces that from 1 /100,000 to 1/150,000 or whatever, but is that worth the extra complexity? Is dropping your duplicate email rate from some very small number to some smaller number going to make enough money to pay for the extra dev time, and the extra lifetime maintainability burden? Almost certainly not.
bgentry|11 months ago
However just because an action may be duplicated after the provider has been asked to do a thing, it does not eliminate the value of the provider being able to deduplicate that incoming request and avoiding multiple identical tasks on their end. Without API level idempotency, a single email on the client’s end could turn into many redundant emails at the service provider’s side, each of which could then be subject to those same subsequent duplications at the SMTP layer. And even then, providers can use the Message-Id header to provide idempotency in delivery as many do.
This is an unavoidable consequence of distributed systems where the client may not know if the server ever received or processed the request, and it may also occur due to client-side bugs or retries within their own software.
In other words, API level idempotency can help eliminate all duplication prior to the API; depending on the service, the provider may also be able to eliminate duplication afterward as well. So it’s strictly better than not having it, really not that difficult to implement, and makes it easier for integrators to build a robust integration with you.
lisper|11 months ago
There is an existing standard for this in the form of the message-id header.
unknown|11 months ago
[deleted]