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 .
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 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: 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 su