4 ms·

Having recently adopted Resend and skimmed a bunch of different email APIs, I'm still waiting to find a single provider whose API supports Stripe-style idempote

Having recently adopted Resend and skimmed a bunch of different email APIs, I'm still waiting to find a single provider whose API supports Stripe-style idempotency [1] so that I can guarantee I don't send the same email through their API multiple times. I'd like to confidently avoid accidentally spamming a user if i.e. a background job retries multiple times due to an unrelated error, or merely from failing to receive the API response that an email was sent/created successfully. Plunk's API does not appear to offer any such feature: https://docs.useplunk.com/api-reference/transactional/send https://docs.useplunk.com/api-reference/transactional/send Unfortunately neither does Resend, Sendgrid, Postmark, etc. [1]: https://docs.stripe.com/api/idempotent_requests https://docs.stripe.com/api/idempotent_requests

01HNNWZ0MV43FF 2y ago
Yep I was shocked that SendGrid doesnt do this I don't even expect them to keep a list of IDs forever, just some best effort like "we don't send anything with the same id twice in a one-hour window" Gmail's API did support this I believe, and then ofc my org transitioned to Microsoft so my little homemade email service quit working
johtso 2y ago
This is exactly what I've been wrestling with recently.. it's so disappointingly absent in all the offerings out there. The solution I ended up with was to build my own pseudo-idempotency around Postmark. It helps that Postmark at least has proper persistence so you can query their API to check if you've already sent a certain email. I had to move away from Mailchimp because, if an email gets queued for some reason, it isn't reflected as sent in the API so there's no way of knowing whether an email is hiding in "queued limbo". Postmark doesn't have this problem. The only caveat is that there is a delay between sending an email and it being reflected in the API (seems pretty standard across the different services). This means I had to implement a simple database backed lock to make sure I never try to send the same email more than once in quick succession. It's kind of ridiculous, but.. I couldn't find any alternative. Edit: Wonder if it would be worth wrapping something like this up into some kind of a self-hostable proxy service. You'd provide the idempotency key in a header and it would do the rest
- dandigangi 2y ago
  Hi. Thanks for the feedback. Recently took over Postmark's engineering and interested in seeing where we can do better as we keep building.
dandigangi 2y ago
Hi. I recently took over engineering at Postmark. Noted! Thanks for the feedback.
- Sytten 2y ago
  While you are here, I have been asking for years to have better access control on API keys so they can only use assigned servers. So my staging cant send prod emails...
  - johtso 2y ago
    API tokens are server specific aren't they?
    - dandigangi 2y ago
      They are!
- bgentry 2y ago
  I understand this change might be a large undertaking to implement across the entire API, and although it would be good to do everywhere, it’s primarily just the send email API that needs it.
  - dandigangi 2y ago
    I like the idea. Staff engineer and I discussed a bit. Added something to our backlog so we don't lose track of it.
fixie 2y ago
Be sure to check out Waypoint (usewaypoint.com). It's an email API with a tightly integrated template builder and has idempotent requests (https://www.usewaypoint.com/docs/idempotent-requests https://www.usewaypoint.com/docs/idempotent-requests).
- bgentry 2y ago
  Thank you! I'm not sure how this didn't come up in what I felt was a pretty comprehensive round of Google searching, but it looks like a fantastic option. If only they had free allotment or something <$20/mo for a small number of emails :) But otherwise this looks a the solution I was looking for.
albertgoeswoof 2y ago
Probably too late, but we support this over at mailpace.com https://docs.mailpace.com/guide/idempotency https://docs.mailpace.com/guide/idempotency

01HNNWZ0MV43FF 2y ago

Yep I was shocked that SendGrid doesnt do this I don't even expect them to keep a list of IDs forever, just some best effort like "we don't send anything with the same id twice in a one-hour window" Gmail's API did support this I believe, and then ofc my org transitioned to Microsoft so my little homemade email service quit working

johtso 2y ago

This is exactly what I've been wrestling with recently.. it's so disappointingly absent in all the offerings out there. The solution I ended up with was to build my own pseudo-idempotency around Postmark. It helps that Postmark at least has proper persistence so you can query their API to check if you've already sent a certain email. I had to move away from Mailchimp because, if an email gets queued for some reason, it isn't reflected as sent in the API so there's no way of knowing whether an email is hiding in "queued limbo". Postmark doesn't have this problem. The only caveat is that there is a delay between sending an email and it being reflected in the API (seems pretty standard across the different services). This means I had to implement a simple database backed lock to make sure I never try to send the same email more than once in quick succession. It's kind of ridiculous, but.. I couldn't find any alternative. Edit: Wonder if it would be worth wrapping something like this up into some kind of a self-hostable proxy service. You'd provide the idempotency key in a header and it would do the rest

dandigangi 2y ago
Hi. Thanks for the feedback. Recently took over Postmark's engineering and interested in seeing where we can do better as we keep building.

dandigangi 2y ago

Hi. I recently took over engineering at Postmark. Noted! Thanks for the feedback.

Sytten 2y ago
While you are here, I have been asking for years to have better access control on API keys so they can only use assigned servers. So my staging cant send prod emails...
- johtso 2y ago
  API tokens are server specific aren't they?
  - dandigangi 2y ago
    They are!
bgentry 2y ago
I understand this change might be a large undertaking to implement across the entire API, and although it would be good to do everywhere, it’s primarily just the send email API that needs it.
- dandigangi 2y ago
  I like the idea. Staff engineer and I discussed a bit. Added something to our backlog so we don't lose track of it.

fixie 2y ago

Be sure to check out Waypoint (usewaypoint.com). It's an email API with a tightly integrated template builder and has idempotent requests (https://www.usewaypoint.com/docs/idempotent-requests https://www.usewaypoint.com/docs/idempotent-requests).

bgentry 2y ago
Thank you! I'm not sure how this didn't come up in what I felt was a pretty comprehensive round of Google searching, but it looks like a fantastic option. If only they had free allotment or something <$20/mo for a small number of emails :) But otherwise this looks a the solution I was looking for.

albertgoeswoof 2y ago

Probably too late, but we support this over at mailpace.com https://docs.mailpace.com/guide/idempotency https://docs.mailpace.com/guide/idempotency