Nitrosend vs MagicBell.

TL;DR

MagicBell is notification infrastructure. An in-app inbox ships as prebuilt UI components, and one API fans a single notification out to mobile push, web push, email, SMS, Slack, and Teams against each user's own preferences. That's a real job and MagicBell does it well. What it doesn't do is send the email: that goes to Mailgun, Amazon SES, SendGrid, or an SMTP account you configure and pay for underneath it.

Nitrosend is a different layer rather than a cheaper MagicBell. If the messages that matter leave your product as email, and campaigns, onboarding, and receipts are going out beside them, you're paying for an orchestration layer and a transport where one platform does both, and every part of it is an MCP tool before it's a screen. If you need the in-app inbox or mobile push, MagicBell keeps those.

1. Add and verify your sending domain in Nitrosend. DKIM and SPF live with whichever provider does the sending and MagicBell never held them, so there's nothing to unpick.
2. Point Nitrosend at the sending key you already gave MagicBell. BYO sending keys on Pro and above cover Amazon SES, Resend, Postmark, Mailgun, and SendGrid, which is three of the five providers MagicBell routes through, so if you were sending through Amazon SES, Mailgun, or SendGrid the reputation stays where it is and the decision stays reversible.
3. Move one low-stakes message type first. A receipt or a password reset, sent with nitro_send_message, and watch it for a week before anything else follows it.
4. Bring the people across with nitro_import_contacts. MagicBell holds app users rather than a mailing list, so these come out of your own database, and rebuilding anything scheduled as a flow with nitro_compose_flow is usually the first time that sequence has existed as one object.
5. Keep MagicBell for the channels it owns. The in-app inbox, mobile push, and Slack stay exactly where they are, and the delivery count drops to what those channels actually use.

• Nitrosend sends the mail itself, so there's no second vendor's bill sitting underneath the platform's.
• One meter instead of two: you pay for emails sent, not for deliveries counted once per channel reached.
• Unlimited contacts on every plan, including Free, so a list that grows without being mailed never moves the bill.
• Email is the product rather than one channel of seven, so campaigns, flows, segments, and transactional sends sit on one platform.
• Contacts are a marketing asset here: custom fields, a timeline, enrichment, lists, segments, and suppression on the record itself.
• MCP-first is an architecture, not an integration: every capability is an API endpoint and an MCP tool before it's a screen.
• The agent surface covers campaigns, flows, contacts, templates, segments, deliverability, billing, tests, and approvals.
• Transactional sends stay on REST and the SDK, because a send that has to be fast shouldn't wait on a tool call.
• A published price from 500,000 to over 4,000,000 emails a month, where a ladder usually turns into a sales call.
• BYO sending keys on Pro and above route mail through Amazon SES, Resend, Postmark, Mailgun, or SendGrid, on the domain and IP you already warmed.
• If MagicBell was already sending through Amazon SES, Mailgun, or SendGrid, that's the same key here, so the switch is reversible on day one.
• Between the three founders, our team has sent more than 6 billion emails across two companies that were both acquired.

Do you need a notification layer at all?

A notification layer earns its own vendor when notifications genuinely fan out. Several channels in real use, an in-app feed a user comes back to, one preference record governing all of it, and an escalation rule for the message nobody opened. That's real infrastructure, it's tedious to build, and MagicBell has built it.

It stops earning that vendor when the fan-out is theoretical, and for a lot of B2B products the fan-out is theoretical. The alert that matters is an email. The digest is an email, the invoice is an email, and the Slack integration has been next quarter's work for two years. The routing decision comes out the same way every time and the preference model has one row in it. At that point the layer is buying you routing you don't use, on top of a transport you're already paying for, metered once per channel reached.

The question the ladders can't answer

The comparison most teams run at this point is which notification platform to buy. The one worth running first is whether the thing they have is a fan-out problem at all, or an email program that arrived one message type at a time and got filed under notifications because the first message was a password reset.

If it's the second, a cheaper router isn't the next thing you need. Campaigns, flows, segments, and a contact record with a history on it are, and those are a different product category priced on a different unit. On Nitrosend all four are MCP tools an agent drives rather than screens a person clicks, and a router sitting in front of somebody else's transport can't retrofit that.

Where this runs out is the product whose fan-out is real: channels carrying different messages, a feed users check, preferences they've set themselves, and an escalation somebody depends on. There the answer isn't a swap at all. MagicBell keeps the notification layer, and the email is the only part that leaves it.

Can Nitrosend replace MagicBell?

For the email half, yes: transactional sends, campaigns, flows, and segments on a platform that does its own delivery. For the in-app inbox and mobile push, no, because Nitrosend specializes in email. That's a scope answer rather than a roadmap one, so plan the split by channel and keep the MagicBell account for the rest.

Does MagicBell send email itself, or do I still need an email provider?

It routes. You configure and pay for Mailgun, Amazon SES, SendGrid, Ping Email, or an SMTP account underneath it, and that account carries the actual send. So the email line on your budget is two bills for the same message: MagicBell's delivery count above, and the provider's per-send rate below it.

What does 50,000 notifications a month cost on each?

On Nitrosend, $100 Ultra covers 125,000 emails with sending included. On MagicBell, the $249 Startup plan covers 50,000 deliveries across all channels, counted once per channel a notification reaches, plus whatever your email provider charges to carry the email share of them.

What happens when you go past MagicBell's Startup allowance?

Deliveries beyond the 50,000 on the $249 Startup plan bill at $0.0025 each for the rest of that period, and a delivery is counted once per channel a notification reaches, so one alert landing in the app and in the inbox spends two of them. Projects meter separately at $99 for each one past the five, which puts staging and test environments on the invoice, and above that MagicBell moves you to an Enterprise quote.