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.
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
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...
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.
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.
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
Self-hosting the mail-composing, mail-merging and tracking functions while using third-party SMTP is well-trod territory. The former can be done on a pretty basic box and the latter, at scale, is a heavy lift.
My guess is Plunk is for people who need a Mailchimp-like offering at a lower-than-Mailchimp price point.
The last time I tried to use Sendy with SES I received a NNN from AWS after I stating I would be using it for email marketing (MailChimp alternative). It seems that my "self-hosting" idea was cancelled by a 3rd party.
Most likely you did not answer the questions that are most important to them.
- How will you make sure that only subscribed recipients will get your emails
- How will you handle bounces and complaints
- How will you monitor your sending
Don't beat around the bush and you will be approved in less than 1 day.
Resend is also built on top of SES, and yet it's an extra layer of hosted services on top of it. So this is actually a self-hosted alternative to i.e. the functionality that Resend offers, even though there are still other underlying dependencies. Seems like a reasonable way to describe it IMO.
So if an application uses a 3rd party provider for authentication (Google, Github, etc) is this no longer considered "self-hosted", despite it running on user's hardware?
I'm curious to know where you draw your imaginary line.
SES is an email platform. So Plunk is a self-hosted email platform - which uses a cloud platform to actually send email. If it's not sending email by itself, it's not a self-hosted email platform.
Those apps using 3rd party auth providers almost universally have them as an optional plugin, allowing you to choose one of a dozen auth providers or your own self-hosted one. You're not tied to any specific 3rd party platform, and rarely tied to any 3rd party platform at all.
if we look at the philosophy behind self-hosting - to be able to host it ourselves, aka not rely on an external party for hosting, that means that if an external party is down or otherwise unavailable, then that line becomes fairly apparent. If 3rd party auth is required, then it's not really self-hosting then is it, because if that third party is down and the software can't be used, then that philosophy is violated. if it's optional, then that's fine though.
For something to be considered self-hosted, If the bombs drop and civilization is over and me, and my home lab are the only survivors, can I still use that software? I'd probably have other concerns in that case, like how am I going to survive nuclear winter, but that's where the imaginary line is.
To most shops, using SES is considered "doing it ourselves" so I somewhat get the characterization. It's very common for self-hosters to use DO, Lightsail, Hetzner because the thing you're hosting is the software. With SES the line between it and SG can be huge if you're using all of SG's high-level features or razor thin if you use SG as SMTP over API.
You host it yourself. It's an email marketing platform (not an email server), but you use AWS SES as an email infrastructure because it is cheap and reliable. You cannot build or host your own infrastructure since emails are hard these days, you use AWS SES or alternative to send emails like most of these services and apps do. It's so easy to get blocked or blacklisted by other email providers.
The wording is awkward and suboptimal. If you don't know what AWS SES is, you'd easily get the wrong impression. In fact, I'd even say it's factually incorrect. It's not built on top of AWS SES. It's built to utilize AWS SES for its functionality. Slightly different, pedantic really.
“Platform” normally implies that it includes the infrastructure that implements the intended functionality, or what is named in the product/project name (“email platform”). In that sense the name is misleading.
(Disclaimer: I run Buttondown, which is an email-inflected product. I also have a comparison guide of various MTAs here — https://buttondown.email/comparison-guides/esps — and will add Plunk!)
Nuances of self-hosting aside, I'd recommend caution looking at that pricing pane.
The disclaimer is:
> Calculated based on the plan that best matches the features of Plunk at 2500 emails per month.
And the author then cites prices of $0.001/email for Plunk and $0.013/email for Sendgrid.
I am neither a user or fan of Sendgrid but that feels like disingenuous anchoring. Sendgrid's free plan is 100/day; if you want to eliminate the free plan entirely and just focus on their cheapest paid option, it's $19.95 for 50K emails — or $0.000399/email, cheaper than Plunk's sticker price.
It's not entirely obvious to me how that $0.013 was even calculated ($0.013 * 2500 = $32.50). Either way, be sure to spot-check against live sticker rates before making a decision there.
My understanding was that the main interest of SendGrid, Mailgun et al was precisely that they manage to (more or less) reliably mass send email through the great MS/Google/Proofpoint, where hitting the recipient's mailbox is less than guaranteed if you self-host.
Maintaining sender reputation is tough and I don't think anyone in their right mind should try this in house. If you're not a M3AAWG member, you'll probably hit a brick wall when trying to explain to Google why your whole IPV4 block is erroneously on a blocklist.
Founder of Plunk here.
Yes, Plunk is designed to work with AWS SES. I was not the one that made it hard for folks to self-host their own email infrastructure. SES is simply the cheapest and most reliable option out there. Reminder, we are not talking about a private "let's send 10 emails a day" solution. This needs to deliver marketing emails at scale.
Does that mean you have to use SES, no. The code is open-source, swap it out for another provider if you truly believe that you can do it better. I'm open for contributions.
Readit News
Plunk's API does not appear to offer any such feature: https://docs.useplunk.com/api-reference/transactional/send
Unfortunately neither does Resend, Sendgrid, Postmark, etc.
[1]: https://docs.stripe.com/api/idempotent_requests
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
https://docs.mailpace.com/guide/idempotency
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
Someone doesn't really understand self-hosting.
My guess is Plunk is for people who need a Mailchimp-like offering at a lower-than-Mailchimp price point.
- How will you make sure that only subscribed recipients will get your emails - How will you handle bounces and complaints - How will you monitor your sending
Don't beat around the bush and you will be approved in less than 1 day.
I'm curious to know where you draw your imaginary line.
Those apps using 3rd party auth providers almost universally have them as an optional plugin, allowing you to choose one of a dozen auth providers or your own self-hosted one. You're not tied to any specific 3rd party platform, and rarely tied to any 3rd party platform at all.
For something to be considered self-hosted, If the bombs drop and civilization is over and me, and my home lab are the only survivors, can I still use that software? I'd probably have other concerns in that case, like how am I going to survive nuclear winter, but that's where the imaginary line is.
Once you have an external requirement and not option, it is no longer a self-hostable software.
> Plunk is an open-source email platform built on top of AWS SES.
I’m out. That’s everything I needed to know about this project to never look at it again.
Deleted Comment
Nuances of self-hosting aside, I'd recommend caution looking at that pricing pane.
The disclaimer is:
> Calculated based on the plan that best matches the features of Plunk at 2500 emails per month.
And the author then cites prices of $0.001/email for Plunk and $0.013/email for Sendgrid.
I am neither a user or fan of Sendgrid but that feels like disingenuous anchoring. Sendgrid's free plan is 100/day; if you want to eliminate the free plan entirely and just focus on their cheapest paid option, it's $19.95 for 50K emails — or $0.000399/email, cheaper than Plunk's sticker price.
It's not entirely obvious to me how that $0.013 was even calculated ($0.013 * 2500 = $32.50). Either way, be sure to spot-check against live sticker rates before making a decision there.
So this just makes an opensource email UI not platform
Founder of Plunk here. Yes, Plunk is designed to work with AWS SES. I was not the one that made it hard for folks to self-host their own email infrastructure. SES is simply the cheapest and most reliable option out there. Reminder, we are not talking about a private "let's send 10 emails a day" solution. This needs to deliver marketing emails at scale.
Does that mean you have to use SES, no. The code is open-source, swap it out for another provider if you truly believe that you can do it better. I'm open for contributions.
That's the beauty of open-source.
I can't see anything in the docs about it.
https://docs.useplunk.com/working-with-contacts/metadata