Launched this week
Helo
An independent email API from former Postmark folks
93 followers
An independent email API from former Postmark folks
93 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.
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. 🧡
ex postmark folks making email api again, love it 📬 what u doing different on deliverability?
@petrkovacik We are committed to maintaining pristine IP pools and zero-tolerance for poor sending practices. We're making it easy to setup authentication and handle recipient opt-out. We also don't offer an outright free plan (our pricing is already significantly cheaper than competitors), which we think goes a long way towards discouraging spammers and keeping our reputation in great shape. There are also some more proactive anti-abuse mechanisms we have put in place to catch malicious messages before they reach inboxes.
Congrats on your launch. Will consider this for my future projects. Do you have plans to do inbound?
@itsaydrian yes! inbound/receiving is one of our top priorities right now. we're hoping to add it within the next few weeks.
Congrats @Helo team! Excited to try this out in my projects.
@alan_tippins1 Thank you! 🧡
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.
@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.