Launched this week
Helo
An independent email API from former Postmark folks
87 followers
An independent email API from former Postmark folks
87 followers
Helo is an email API built for developers and platforms that send on behalf of their customers. Contain bad senders before they drag down deliverability, let customers send from their own domains, and keep stats, unsubscribes, and credentials separate per tenant. It also covers the fundamentals: REST API and SMTP, SDKs in popular languages, separate transactional and broadcast infrastructure, and usage-based pricing starting at just $0.00035 per email—all features included.
Helo
Hi PH!
I'm Bettina, one of the humans behind Helo, an email API for sending transactional and marketing email from your application: password resets, receipts, notifications, newsletters, etc.
Most of our team worked together at Postmark for many years, so we know what it takes to build a rock-solid email service. If you've ever loved a product and then watched it get acquired, you probably know the rest of that story. We started Helo to keep building the kind of product we're good at, improve on what we have learned, take good care of our customers, and stay independent while doing it. We're bootstrapped and plan to stay that way.
Helo covers everything you'd expect from a developer-focused email service:
- REST API and SMTP, with SDKs for Ruby, JS, C#, Python and Go (more to come)
- Separate infrastructure for transactional and broadcast mail (so we can optimize deliverability for both)
- Event logs, stats, webhooks, suppressions, unsubscribes, flexible permissions
- Fair, usage-based pricing with no arbitrary feature gates - https://www.helohq.com/pricing
Beyond that, we designed Helo to fully support multi-tenant sending.
Most email providers are built for the general case: a single company sending its own emails to its own customers. But what if you build a platform that sends on behalf of your customers? Let’s say you’re building a restaurant management tool and want your restaurant owners to be able to send newsletters from your platform. You suddenly face a whole new set of spicy challenges. If one of your customers is sending spam, how do you catch that and ensure that one bad sender doesn’t spoil deliverability for your entire product? How can you make it easy for your users to send from their own domains? How can you make sure that recipients that unsubscribe from restaurant A’s newsletters are still receiving mail from restaurant B? The list goes on.
We've built Helo to address all of these concerns, while also allowing flexibility in how the relationships between domains, webhooks, credentials, etc. are defined amongst your tenants.
If you've built multi-tenant sending before, what was most painful? Is there something you wish your email provider handled for you but doesn't? I'd love to hear about it.
And, of course, I'd also love it if you gave Helo a try. 🧡
@bettina_specht1 The painful part was reputation isolation. One tenant blasting a bad list drags everyone else's deliverability down. Per-tenant suppression lists and separate subaccounts for the noisy senders fixed it, but per-tenant bounce and complaint handling is the unglamorous work nobody wants to build.
Macaly
ex postmark folks making email api again, love it 📬 what u doing different on deliverability?
Congrats @Helo team! Excited to try this out in my projects.
Helo
@alan_tippins1 Thank you! 🧡
Dial
the bootstrapped-and-staying-independent line hits different after watching postmark get acquired. on the per-tenant isolation - is that dedicated IPs per customer, or shared pools with reputation scoring per sender? asking because shared-pool is way cheaper to run but one bad tenant can still drag the whole pool down in practice, even with good internal tracking.
Helo
@galdayan great question! Much like we did in the old days at PM, we believe it's the providers responsibility to maintain pristine shared IP pools. Too often, providers abdicate that responsibility by trying to upsell their customers onto dedicated IPs, which are themselves a bit of a false promise (used incorrectly, dedicated IPs can actually hurt email delivery). It's really only at extremely large volumes across all of the major ISPs that it makes sense to put a customer on their own, dedicated IP address.
To bring that back to your question, when using our multi-tenant sending (what we call "Channels"), each channel is getting its own sending lane over our shared pool. We've built in tools on our side to proactively catch a bad sender on a channel (which could easily get buried when sending for customers is aggregated across a single account and degrade your sending reputation). Utlimately, we see it as our responsibility to make sure your emails getting to the inbox—after all, what's the point of using Helo (or any email service) if they're not.
This hits close to home. I'm a solo dev and launched a small SaaS on Postmark — their manual account-approval step meant I could only deliver to my own domain for weeks, which blocked real customer emails right when I needed them most. Ended up moving to Resend just to unblock the launch. Does Helo require that kind of manual approval before you can send to arbitrary recipients, or can a new account send broadly from day one (within normal abuse limits)? That gap is the main thing indie devs can't afford to hit mid-launch.
Helo
@victor_pratti Yeah, getting stuck in manual approvals is an annoying blocker, so this is one of the things we're doing differently at Helo. If you're looking like a legit sender to us, you won't be hitting any approval roadblocks as you get started.
Hope things are going well with the email sending for your SaaS now that you're up and running. But should you ever be looking for an alternative service, you now know where to find us. :)