u/maulik1807

Why I open-sourced my email verification API

I built an email verification API and listed it on RapidAPI. First thing someone asked: *"How do we know you're not harvesting the addresses and selling them to spammers?"*

Honestly? Fair question. It's the right thing to ask of any verification service.

The uncomfortable truth is you can't prove a negative. Every service says "we don't store your data." ZeroBounce, NeverBounce, Hunter — they're all black boxes. You pay them, you trust them, and you have no way to verify either way.

So I open sourced the whole thing.

**What the code actually does:**

The pipeline is stateless. An address comes in, six checks run in memory, the result goes back out. Nothing is written to disk or a database. There are no analytics SDKs, no third-party calls, no logging of the address itself.

The six checks:

* RFC 5322 syntax validation

* MX record lookup (does the domain have mail servers?)

* Disposable domain detection (5,361+ known throwaway providers)

* Role-based address flagging (admin@, noreply@, support@, 35 patterns)

* Typo detection across 30 major providers (gmial.com → gmail.com)

* Catch-all domain detection

There's also an SMTP mailbox probe that attempts to confirm the inbox exists without sending anything — but I'm upfront that the hosting provider blocks port 25, so that check usually returns "unknown." The other six run fully.

**The self-hosting angle**

The better answer to the harvesting concern is letting you run it yourself. I'm working on a Docker image so you can deploy the whole thing on your own infrastructure and never send an address to my server at all. At that point the trust question disappears entirely.

**The economics argument**

If I were harvesting addresses to sell, I'd need verified, real addresses — which means spending compute on every lookup. At the price this runs at, the math doesn't work. But that's still just me asking you to trust me, which is exactly the problem.

Read the code. That's the only honest answer.

GitHub: [https://github.com/Maulik2007/email-verify-api\](https://github.com/Maulik2007/email-verify-api)

RapidAPI: [https://rapidapi.com/maulik1807/api/email-verification-and-validation1\](https://rapidapi.com/maulik1807/api/email-verification-and-validation1)

u/maulik1807 — 2 days ago
▲ 5 r/SideProject+2 crossposts

I built a free-ish email verification API that doesn't need any paid services under the hood — here's how it works

Most email verification APIs are basically a regex check wrapped in a $50/month subscription. I wanted to understand what "real" email verification actually looks like, so I built one from scratch in Node.js.

It runs 6 checks on every address:

  1. Syntax — RFC 5322 validation, not just a basic regex
  2. MX lookup — does the domain actually have mail servers? (catches user@gmail.con, dead domains, etc.)
  3. Disposable domain detection — 5,361 known throwaway providers flagged
  4. Role-based detection — admin@, noreply@, support@ and 32 other patterns
  5. Typo suggestions — Levenshtein distance across 30 top providers, so gmial.com → gmail.com
  6. Catch-all detection — identifies domains that accept every address regardless of whether the inbox exists

It also attempts an SMTP mailbox probe (step 7) but I'm honest that Railway blocks port 25, so that usually returns "unknown." The other 6 checks run fully.

Results come back as a 0–100 deliverability score with a reason code and per-check breakdown. There's also a bulk endpoint (up to 50 addresses per request).

For most use cases — blocking fake signups, cleaning a list before a campaign, catching typos at registration — checks 1–6 are enough. The only thing missing vs. the big players is confirmed mailbox existence, which requires bare-metal hosting to do reliably anyway.

It's live on RapidAPI if anyone wants to try it: https://rapidapi.com/maulik1807/api/email-verification-and-validation1

Happy to answer questions about the SMTP implementation or the scoring logic — the catch-all detection in particular was interesting to figure out.

reddit.com
u/maulik1807 — 2 days ago
▲ 3 r/SideProject+1 crossposts

I built a dead-simple HTML/Markdown → PDF API so you don't have to configure Puppeteer ever again

I kept running into the same problem on side projects — I'd need to generate a PDF (invoice, report, export) and end up spending hours setting up Puppeteer, dealing with Chrome sandbox issues on the server, and debugging page.pdf() options.

So I built a hosted API that handles all of it. You just POST your HTML or Markdown and get back a PDF. That's it.

What it supports:

  • Full HTML with CSS (backgrounds, custom fonts, tables)
  • GitHub-flavored Markdown (headings, tables, code blocks, bold/italic)
  • Page size, orientation, margins, headers/footers — all configurable
  • Works from any language — Node, Python, curl, whatever

Example (curl):

curl -X POST https://html-and-markdown-to-pdf1.p.rapidapi.com/api/v1/pdf/from-html \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html": "<h1>Invoice</h1><p>Amount: $99</p>"}' \
  --output invoice.pdf

It's live on RapidAPI with a free tier. Would love any feedback — especially on what features would make it actually useful for your projects.
https://rapidapi.com/maulik1807/api/html-and-markdown-to-pdf1

reddit.com
u/maulik1807 — 3 days ago