A two-way email API sends mail from your app and also receives the answers. The receipt goes out from a real address on your domain, the customer replies, and your code is told about the reply and can read it. Most email APIs only do the first half.
Linden makes canvas bags and sells them from its own site. When someone orders, the site sends a receipt from noreply@linden.shop. Anna gets hers, notices the shipping address is her old flat, and does the obvious thing: she hits reply and types the new one.
Her message goes nowhere. At best it bounces, and at worst it is quietly accepted by a mailbox nobody reads. The bag ships to the old flat. Anna now thinks Linden ignored her, and she is right. The shop had the answer in writing and no way to hear it.
That is the gap a two-way email API closes. Nothing about sending changes. What changes is that the address on the receipt is a real mailbox, and the reply comes back to the same system that sent the original.
What a two-way email API actually is
A regular transactional email API does one job. Your code makes a request with a recipient, a subject and some HTML, or the name of a template, and the service delivers it from your domain. You get an id back and, if you ask, events telling you it was delivered or bounced. That is the outbound half, and it is what most transactional services are built around. Some sell inbound parsing as a separate feature: a webhook carrying the raw message, with no mailbox behind it for a person to open.
A two-way API adds the inbound half on the same account and the same domain. The addresses you send from are mailboxes. When someone answers, the message lands in that mailbox, and the service posts a webhook to your server saying a message arrived, who it is from, the subject, a snippet and the thread it belongs to. Your code can then fetch the message in full, attachments included, through the same API it used to send. People can read the same mailbox in webmail or a phone app, so a reply your code does not know what to do with still reaches a human.
What you can build once replies come back
Most of the value comes from small things that used to need a support ticket. A few examples of what Linden, or any product that sends mail, can do once the reply comes home:
| The customer replies to | What your code does with it |
|---|---|
| An order receipt, with a new address | Matches the thread to the order and updates it before it ships |
| A meeting reminder, with "can we move this?" | Offers new slots, or hands the thread to the person who owns the calendar |
| A weekly report, with a question | Opens a ticket with the report attached, so support sees what the customer saw |
| An invoice, with a PDF of a signed purchase order | Pulls the attachment and files it against the account |
| A trial reminder, with "not now, too expensive" | Tags the account and tells whoever runs sales |
| Any of them, with something no rule covers | Leaves it in the mailbox for a person, or passes it to an AI agent to draft an answer |
The reply arrives as a message.received webhook with the sender, subject, snippet and thread id. The last row uses the MCP server, which exposes the same mailbox to Claude and to agents.
Who it helps, and how
The customer benefits first, and in the simplest way: they can answer an email and be heard. Nobody enjoys a receipt that says "do not reply to this message" followed by a link to a contact form that asks for the order number printed in that same email.
For the people running the product, replies are the most honest feedback they get. Someone who answers a password reset with "I never asked for this" has just reported a problem you would otherwise never see. A reply to a churn email saying why they are leaving is worth more than any survey. With noreply@, all of that is thrown away before anyone reads it.
For the developer, the gain is having one system instead of three. Without a two-way API, reading replies means a separate inbound parsing service, a mail host for the humans, and glue code to keep the threads together. Here the domain is set up once, SPF, DKIM and DMARC are written for you, and the same API key sends, reads and searches. Templates live in the dashboard, so the copy on the receipt can change without a deploy.
noreply@ is a way of telling your customers you are not listening. A two-way API is a way of listening without hiring anyone.
How it works on Faivelo
Faivelo started as email hosting, so the mailboxes came first and the API was built on top of them. That is why the inbound half is not an add-on. You send with POST /api/v1/emails or the faivelo package on npm, reference one of the 36 starter templates or your own by alias, and pass variables. A missing required variable fails the request with a 422 instead of sending a half-filled email, and an idempotency key makes a retried request send once. Replies land in the mailbox and fire the message.received webhook, signed with your endpoint secret and retried for about a day if your server is down.
Sending is included in the plan rather than priced per email: 3,000 a month on Starter at $6, 20,000 on Growth at $12, 50,000 on Pro at $24 and 100,000 on Business at $49, with unlimited mailboxes on every plan. Webhooks, including message.received, come with Pro and Business, and all of it is switched on during the 14-day trial.
Send one receipt, then answer it
Start a trial, add your domain, send yourself a receipt from a real address, and reply to it. Watch the reply arrive at your endpoint. No card for fourteen days.