How an independent open-source project grew into a full TypeScript SDK and was eventually adopted by MailChannels.
Sometimes, open-source projects start with a very small problem.
You build something because you need it yourself, publish it because you think someone else might find it useful, and then keep improving it simply because you enjoy building software.
That was the story behind mailchannels-sdk.
What started as a small Nuxt integration eventually became a full Node.js and TypeScript SDK for MailChannels. Along the way, I learned a lot from the Vue, Nuxt, and UnJS ecosystems, took inspiration from other developer-focused tools such as Resend, and eventually had the opportunity to join MailChannels and get the project adopted and officially maintained.
This is the story of how that happened.
TL;DR
- Built a small Nuxt integration that evolved into a full TypeScript SDK for MailChannels.
- The SDK focuses on developer experience (camelCase, TypeScript types, local simulator) and covers 40+ endpoints.
- I joined MailChannels and now help maintain the SDK; contributions and feedback are welcome.
What you'll learn
- Why I built the SDK and the problems it solves
- How the project evolved from a Nuxt module into a Node.js SDK
- Key design choices and what's next
Discovering MailChannels
I first discovered MailChannels in 2022–2023 while working on several personal and professional projects that needed a simple and affordable way to send emails.
I'm primarily a web application developer, and at the time I was working a lot with Cloudflare Workers. Email was a common requirement: contact forms, welcome emails, registration notifications, and other transactional messages.
MailChannels was a good fit for these projects because it was directly integrated in Cloudflare Workers at no cost, and using it also introduced me to parts of email infrastructure that I hadn't worked with deeply before.
I started learning more about email delivery and security, including things like DKIM signing and domain authentication.
What started as a practical requirement gradually became something I was genuinely interested in.
The Cloudflare Workers problem
I continued using MailChannels across several projects.
Then, in October 2024, MailChannels announced the end of support for Cloudflare Workers.
I had already built several applications around MailChannels, and replacing all of those integrations with another provider wasn't particularly appealing.
Fortunately, MailChannels was offering its Email API with a free tier. I signed up, obtained an API key, and continued using MailChannels through the Email API.
That solved the immediate problem.
But it also exposed another one.
The API was fine. My integrations weren't
The MailChannels API gave me everything I needed, but I found myself repeatedly building the same request structures across different projects.
You need to know how properties such as personalizations work, remember the available options, construct the request correctly, and make sure the payload matches the API specification.
Doing it once is easy.
Doing it across multiple projects gets repetitive.
I started thinking that TypeScript could make this experience much nicer.
Instead of manually constructing API requests every time, I wanted something closer to:
import { MailChannels } from "mailchannels-sdk"
const mailchannels = new MailChannels("your-api-key")
await mailchannels.emails.send({
from: "Acme <hello@acme.com>",
to: "user@example.com",
subject: "Welcome!",
html: "<p>Thanks for joining</p>"
})
The MailChannels Email API wasn't necessarily the problem.
I wanted a better developer experience around it.
Starting with Nuxt
My first solution wasn't a Node.js SDK.
I mainly use Nuxt in my own web projects, so I initially created a small Nuxt module (nuxt-mailchannels) to make MailChannels easier to integrate into those applications.
That small project solved my immediate problem.
But working within the Nuxt ecosystem also influenced how I thought about the library.
The Vue, Nuxt, and broader UnJS ecosystem has always been a big source of inspiration for me. There is a strong focus on developer experience, TypeScript, clean APIs, composability, portability, and making complicated things feel simple.
Working with projects such as Nuxt, Nitro, and other UnJS packages taught me a lot about how good JavaScript tooling can feel.
I wanted to bring some of those ideas into the MailChannels integration.
Eventually I started asking myself:
Why should this only work for my Nuxt projects?
From a Nuxt module to a Node.js SDK
I had also been looking at other projects in the JavaScript ecosystem and was particularly inspired by how Resend structured its Node.js package.
The API was simple and pleasant to use.
That made me think:
What if MailChannels had something similar?
At that point, the project started becoming more ambitious.
Instead of a small Nuxt module, I decided to build a proper Node.js SDK for MailChannels.
The goal wasn't simply to wrap a few HTTP endpoints.
I wanted to cover the MailChannels API as completely as possible while making the interface feel natural to JavaScript and TypeScript developers.
Today, the SDK covers a broad range of MailChannels Email API functionality, with around +40 official endpoints.
Making an API feel like JavaScript
One of the things I care about most in the SDK is the developer experience.
The MailChannels API uses snake_case for many of its properties. That's perfectly reasonable for an HTTP API, but JavaScript developers generally expect camelCase.
So the SDK intentionally adapts the API to JavaScript conventions.
Instead of:
some_property_name
you generally work with:
somePropertyName
Some properties are also grouped into nested objects or simplified when that makes the API easier to understand.
The goal isn't to reproduce the HTTP API exactly.
The goal is to create an API that feels like a JavaScript library.
Building more than send()
The project has grown considerably since those first experiments.
Sending transactional emails is still at the heart of the SDK, but it now covers much more of the MailChannels platform.
Some of the things you can do include:
- Send transactional emails
- Check DKIM, SPF, and Domain Lockdown
- Custom tracking domains
- Configure DKIM keys
- Manage webhooks
- Manage sub-accounts
- Retrieve metrics
- Inspect webhook delivery batches
- Handle suppressions
- Run a local simulator for development and testing
- Nodemailer transport
- CLI commands
The SDK also includes an AI-agent skill containing focused documentation and recipes for coding agents such as Claude Code, Cursor, Codex, and similar tools.
These aren't features I originally planned when I created the first Nuxt module.
They came naturally as the project evolved, joining forces officially with MailChannels, and we started thinking about what would make the SDK genuinely useful to other developers.
I built it because I enjoy open source
There wasn't a business plan behind this project.
I built it because I enjoy coding.
I enjoy publishing things on GitHub, npm, experimenting with ideas, learning from other open-source projects, and seeing something I built become useful outside my own projects.
Even without a direct monetary return, there's a lot of personal satisfaction in that.
You solve a problem for yourself, turn the solution into a reusable project, and eventually someone else can benefit from it.
That's one of the things I love about open source.
When the project became more than my project
One of the most rewarding parts of this journey was seeing the project evolve from something I created independently into something connected to the company whose API it was built for.
What started as my own Nuxt integration eventually became a complete Node.js SDK for MailChannels.
The project is now officially maintained with MailChannels involvement, and I'm the Lead Maintainer of the Node.js SDK at MailChannels.
As the project became an official MailChannels SDK, it was migrated from my personal GitHub repository to the MailChannels organization on Bitbucket.
That transition is something I never really planned when I published the first version.
I was simply trying to make my own projects easier to maintain.
It's a good reminder of one of the things I love about open source: you don't always know where a project is going when you publish the first version.
What's next?
The project is still actively developed.
As the MailChannels Email API evolves, I'll continue keeping the SDK synchronized with it, refining the developer experience, and adding support for new capabilities.
The underlying goal hasn't changed since the beginning:
Make working with MailChannels feel natural for JavaScript and TypeScript developers.
What started as a small Nuxt module for my own projects has grown into a full Node.js SDK.
And for me, that's one of the most rewarding parts of building in open source.
You don't necessarily start by trying to build something important.
Sometimes you just build something you need.
You publish it.
You keep improving it.
And eventually, it can become something meaningful to people beyond yourself.
Try it
If you're building a Node.js or TypeScript application that uses MailChannels, you can install the SDK with:
npm install mailchannels-sdk
The project is open source, actively maintained, and feedback and contributions are welcome.
Official documentation: https://docs.mailchannels.com
Personal documentation: https://mailchannels.yizack.com
NPM: https://www.npmjs.com/package/mailchannels-sdk
Source: https://bitbucket.org/mailchannels/mailchannels-email-api-sdk-js
MailChannels: https://www.mailchannels.com/
Top comments (0)