Kontacts vs Resend

Resend alternative: the inbox, not just the API

Resend is excellent email infrastructure. Kontacts is what you would spend a month building on top of it — a project inbox, an address list that decides which mail becomes a GitHub issue, and a booking page.

Resend forwards your inbound mail to an endpoint you write. Kontacts is the endpoint: read it in the app and watch it turn into issue #42. Free to start.

How Kontacts compares to Resend

FeatureKontactsResend
Read a received email without writing codeYes — project inbox in the appInbound mail is delivered by POST to an endpoint you build [2]
Send from the product without writing codeYes — compose in the dashboard, capped at 10/day per organisation on the free tierNot offered as an inbox; you send via the API from an app you build [1][2]
Full message body on arrivalYes, in the inboxWebhook carries metadata only; body and attachments require the Received emails API [2]
Authenticated mail to a listed address opens a GitHub issueYes, when routing is onNot offered [1][2]
Reply posted back as a comment on the issueYes — from the inbox, posted as a comment on the linked issueNot offered [1][2]
GitHub App scoped to repositories you pickYes, including private reposNot offered [1]
Booking page for the projectYesNot offered — Resend is email [1]
A non-developer teammate can act on the mailYes — it is a UIRequires an API key and an application [2]
Time to first received message in a repoPoint MX/SPF/DKIM, install the App, flip routing, send a testYou still have to build the app that does something with it [2]
Sending volume10 per day per organisation on the free tier, more on a paid plan, from the dashboard or POST /api/v1/send with an API key minted at Settings → API keys3,000/month free; 50,000 on Pro at $20/month [1]
Price to startFree plan availableFree plan: 3,000 emails/month, 1 custom domain, 30-day retention; Pro from $20/month for 50,000 [1]

Sources

  1. [1] https://resend.com/pricing — read . Free $0 (3,000 emails/month, 1 custom domain, 30-day data retention); Pro $20/month (50,000 emails, 10 domains); Scale from $90/month (100,000 emails, 1,000 domains); Enterprise custom. Inbound is available across plans. No scheduling/booking or GitHub issue creation is listed.
  2. [2] https://resend.com/docs/dashboard/receiving/introduction — read . "Resend processes all incoming emails for your receiving domain, parses the contents and attachments, and then sends a POST request to an endpoint that you choose." And: "Webhooks do not include the email body, headers, or attachments, only their metadata. You must call the Received emails API or the Attachments API to retrieve them." Getting started requires you to "create a new route that can accept POST requests".

Resend vs Kontacts: infrastructure and product

This is not a fair fight and it is not meant to be one, in either direction. Resend is infrastructure — a clean API, good deliverability, and inbound routing that turns a message into a POST at a URL you own. It is one of the better pieces of email plumbing available and we are not going to pretend it is a weak product.

But a webhook is not an inbox. When Resend delivers email.received, you get metadata; to see what the person actually wrote, you call the Received emails API from an application you have written, and then you decide where to put it, how to show it, who can reply, and what happens next (source [2], read 2026-08-18).

Kontacts is most of that application, already built. The message arrives in a project inbox you can read. With routing on, mail to an address on your list opens a GitHub issue in the repo you connected — or every address at the domain, with the optional catch-all on. A non-developer on your team can act on it. Nobody wrote a route.

A reply you write in the inbox leaves from the project address, threads correctly, and posts back as a comment on the linked issue. That is the same path as compose-and-send for a new message, plus In-Reply-To and the GitHub comment — it is not a stub.

Resend alternative for teams who do not want to build the inbox

The honest test: how much of the following do you want to own?

Parsing and storing the message. An inbox UI. Threading. Who on the team may see which project's mail. Sending the reply from the right address. Keeping the reply attached to the right conversation. Turning any of it into a work item in GitHub.

If the answer is “all of it, and I have opinions” — Resend is a great foundation and you should build on it. If the answer is “none of it, I just want the bug report to become an issue” — that is Kontacts, and the free tier covers it.

Resend pricing vs Kontacts pricing

Resend's free plan is 3,000 emails a month with one custom domain and 30-day data retention; Pro starts at $20/month for 50,000 emails and ten domains (source [1], read 2026-08-18). Those are good numbers for a sending API.

Kontacts is billed per organisation, not per seat. Prices live on the pricing page. Sending is capped: on the free tier, ten per day per organisation — ten across every project in that organisation, not ten each — whether you send from the dashboard or call POST /api/v1/send with an API key minted at Settings → API keys. A paid plan raises both the daily and the monthly ceiling. That is a real limit and we would rather print it than be quiet about it — but notice what the two products are pricing. Resend prices volume, because volume is the job. We cap volume, because the job here is the conversation: a project inbox, and an issue in your repo that a human can act on.

What Kontacts is not

It is not a mail client. There is no IMAP, so you cannot point Thunderbird or Apple Mail at it. It is not a transactional sending API at volume: POST /api/v1/send exists and takes an API key (with inbox:write) you mint at Settings → API keys, but on the free tier it is capped at ten sends a day per organisation — ten across every project in that organisation, not ten each — it sends as that one project identity. If you need to send a hundred thousand password resets, Kontacts is the wrong product and Resend is the right one — one endpoint that happens to exist does not change that. You can answer from the inbox: a reply leaves from the project address and, on a linked thread, posts back as a comment on the issue. There is also no self-serve data export yet.

When Resend is the better choice

Whenever email is a feature of your product rather than the workspace of your team. Signup confirmations, password resets, receipts, notification digests, anything at volume, anything that must be sent from your own code paths — that is Resend's job and it does it well, at 3,000/month free and $20/month for 50,000 (source [1]). We have a send endpoint and it is not a substitute: ten a day per organisation on the free tier, one project identity.

If you want full control of how inbound mail is parsed, stored and routed, take the webhook and build it — it will fit your product better than ours ever will. Kontacts is the right answer only when you want the inbox itself to be the product.

Questions, answered short.

Can Resend receive email?
Yes. Resend processes incoming mail for your receiving domain and sends a POST request to an endpoint you choose (resend.com/docs/dashboard/receiving/introduction, read 2026-08-18). The difference with Kontacts is what happens next: Resend hands the message to code you write, and Kontacts hands it to an inbox you can read, reply from, and route into GitHub issues.
What is the difference between Resend and Kontacts?
Resend is email infrastructure; Kontacts is the product built on that idea. Resend's inbound webhook carries metadata only and you call the Received emails API for the body (read 2026-08-18). Kontacts gives the project an inbox, turns authenticated mail to the addresses on your list into a GitHub issue when routing is on, and hosts the project's booking page.
Do I need to write code to use Kontacts?
No. You point your domain's MX, SPF and DKIM records at Kontacts, install the GitHub App and pick the repositories it may see, connect the project to a repository, flip routing on, and send a test message. There is no webhook receiver to build.
Can I send transactional email with Kontacts?
Not at volume. A POST /api/v1/send endpoint authenticated with an API key does exist — mint the key at Settings → API keys — but on the free tier it is capped at ten sends per day per organisation — ten across every project in that organisation, not ten each — it sends as one project identity. For transactional sending from your own code — signup confirmations, password resets, receipts, anything at volume — use Resend. That is what it is for.
How much does Kontacts cost compared to Resend?
Kontacts is billed per organisation, not per seat. Prices live on the pricing page. Resend's free plan is 3,000 emails/month with one custom domain, and Pro starts at $20/month for 50,000 emails (resend.com/pricing, read 2026-08-18).
Does Kontacts do scheduling too?
Yes — publish a meeting type and the project has a booking page with the team's hours, buffers, minimum notice and a booking horizon, and a booking puts the appointment on the project agenda. Resend does not offer scheduling; it is an email product.
What is Kontacts not?
It is not a mail client — there is no IMAP, so you cannot point Thunderbird or Apple Mail at it. It is not a transactional sending API at volume: an API-key-authed POST /api/v1/send exists — mint the key at Settings → API keys — but on the free tier it is capped at ten sends a day per organisation — ten across every project in that organisation, not ten each. There is no self-serve data export yet. And it is hosted only.