# Inbound Routes the Mail. Cotera Is What Answers It.

> Inbound.new routes mail to your webhook and leaves the agent to you. Cotera ships the agent, 144 tool integrations, and email as a trigger. Compare both.

Source: https://cotera.co/inbound-vs-cotera

---

Inbound.new points your domain at a webhook and hands you the payload. Everything after that is code. Cotera picks it up there: you build an agent once, reuse it across Slack, schedules, and webhooks, and email is simply another way to interact with it.

## Cotera vs Inbound
| | Cotera | Inbound |
| --- | --- | --- |
| Agents get their own email address | Yes | Yes |
| Inbound email starts a run | Yes | Webhook, you write the handler |
| The agent itself is included | Yes | No |
| Built-in tool integrations | 144 | No |
| Multi-step reasoning and tool chaining | Yes | No |
| Durable execution that survives restarts | Yes | No |
| Build it without writing code | Yes | No |
| Schedule and webhook triggers too | Yes | No |
| Runs against your data warehouse | Yes | No |
| Address minted for you, no DNS to configure | Yes | You add MX records |
| Your own domain on the address | No | Yes |
| Unlimited addresses on your domain | No | Yes |
| Catch-all routing to one endpoint | No | Yes |
| Transactional sending included | No | Yes |
| Free tier | Yes (1,000 credits) | No ($4/mo entry) |

## FAQ
### Is Cotera an Inbound alternative?

For the agent, yes. For the mail plumbing, no. Inbound.new is developer email infrastructure: you point a domain at it, get unlimited addresses on that domain, and route each one to an endpoint or send everything to a catch-all webhook. What arrives at that webhook is a payload, and what happens next is code you write. Cotera is the code you would have written. You build an agent once and reuse it across Slack, schedules, and webhooks, and email is simply another way to interact with it rather than a separate integration to maintain.

### Do I have to configure DNS to use Cotera email triggers?

No, and that is the clearest practical difference. Inbound expects you to add a domain and set MX records before anything works, which is the right trade when you want mail arriving at support@yourcompany.com. Cotera mints the address for you: add an email trigger and you get something like deals-k3f9x2@inbound.cotera.ai, ready to copy off the trigger card. The trade runs the other way too, since Cotera addresses live on a Cotera domain rather than yours.

### What does Inbound do that Cotera does not?

Inbound owns the domain layer. You bring your own domain, mint as many addresses on it as you like, and route them individually or as a catch-all, which is exactly what you want if every message to a public support address should reach an agent. It also sends transactional mail, so one service covers both directions. Cotera does not host your domain, does not offer catch-all routing, and sends through whichever Gmail, Outlook, or SendGrid account you have connected rather than its own infrastructure.

### How does pricing compare?

Inbound prices email volume and domains, from $4/month for 5,000 emails through $79/month for 200,000 emails and 500 domains, with extra domains at $3.50 each. There is no free tier. Cotera prices the work the agent does rather than the mail it receives: $0 to start with 1,000 free credits and no card, then $500/month on the Team plan for 100,000 credits and unlimited seats. Very high mail volume is cheap on Inbound. Reasoning and tool calls are what you are actually buying on Cotera.

### Can I use both?

Yes, and it is a reasonable pairing. Keep Inbound on your public domain for the addresses customers see, and forward from there into a Cotera email trigger so an agent handles what arrives. You get your own domain on the outside and an agent you did not have to build on the inside.