API Alerts vs ntfy

ntfy and API Alerts both let developers send notifications from their code to their phone. They share the underlying HTTP-publish-and-receive idea. But they were built by different people for different reasons, and they sit in genuinely different categories.

This page exists to help you pick the right one for your use case. We are not going to argue that API Alerts is universally better. For a meaningful subset of developers (the ones who care about open source, who want to self-host, who want simplicity over routing) ntfy is the right answer and we will say so plainly.

The one-sentence framing

ntfy is a simple HTTP-based pub-sub notification service that is fully open source (dual-licensed under Apache 2.0 and GPLv2), built and maintained by Philipp Heckel, and runnable either as a free hosted service at ntfy.sh or as software you self-host on your own infrastructure. It is single-channel (push notifications to ntfy’s apps), uses a topic-based model where any topic name is a public address until you reserve it on a paid plan, and is funded by donations and corporate sponsorships rather than venture capital.

API Alerts is a notification routing platform. You send one event from your code, and we deliver it to push notifications, Slack, SMS, WhatsApp, email, or any webhook based on rules you configure. Multi-channel, team-aware, designed for projects that grow. Closed-source managed SaaS.

If you want self-hosted and open source, ntfy is honestly hard to beat. If you need multi-channel routing and a managed delivery pipeline, this is where we come in.

One more thing before the comparison: high-signal vs high-volume

There is a philosophical difference between API Alerts and ntfy that shapes everything below, and we want to name it explicitly so the rest of the page makes sense.

API Alerts is designed for high-signal alerting. The events you send through us are the ones you actually want to see in the moment they happen. A new paid user. A failing cron job. A production server going down. The signal is the whole point. We optimize for “every notification is something you care about being interrupted for,” and our pricing tiers reflect that volume profile.

ntfy supports a wider band, including the high-volume end. ntfy’s tooling and pricing are sized for the case where a developer wants to send many push notifications, often as part of automation, monitoring activity, or status streams. The Supporter tier at $6/month allows 2,500 messages per day, the Pro tier at $12/month allows 20,000 messages per day, and the Business tier at $25/month allows 50,000 messages per day. Annual billing brings those prices down to $5, $10, and $20 per month respectively. Those are real numbers for a real category of work, and ntfy serves it well.

Different philosophy, different volume profile, different pricing. The numbers below are not directly comparable because the two tools are sized for different intended uses. We are not in the analytics-volume zone and are not trying to be. If you need that volume, ntfy is genuinely the better choice for that workload.

There is also a second architectural difference between us and ntfy, alongside this volume one: ntfy is pub/sub, API Alerts is directed delivery with per-destination tracking. ntfy publishes messages to topics that subscribers consume. The ntfy server stores messages in a configurable cache, so it is not fire-and-forget in the strict sense — messages persist on the server, subscribers pull them, and the topic has its own message history visible in the dashboard and app. What ntfy does not have, by design, is per-recipient delivery tracking on the publisher side. The pub/sub model means the publisher does not know which subscribers received which messages, when, or whether anything failed for any specific recipient. API Alerts uses a different model: each event is delivered to specific configured destinations (push to specific devices, Slack to specific channels, SMS to specific numbers, webhooks to specific URLs), and each delivery is tracked individually with a per-destination log so you can see exactly what landed where and what didn’t. Both architectures are legitimate. They are optimized for different things. We get into that in the bullets and the FAQ below.

Side-by-side

	API Alerts	ntfy
Delivery channels	Push, Slack, SMS, WhatsApp, email, webhooks	Push only (to ntfy apps)
Open source	No (proprietary SaaS)	Yes (Apache 2.0 / GPLv2 dual-licensed)
Self-hostable	No	Yes (ntfy Server)
Free tier	1,000 events / month, account required	Free without sign-up; topic name acts as a password
Paid tier starting price	$12 / month (Solo)	$6 / month (Supporter, or $5 with annual billing)
Integration	HTTP API, 12 native SDKs, CLI, plus integrations like Zapier and GitHub Actions	HTTP API
Routing rules	Yes, dashboard-driven	None (single channel)
Account model	Workspaces with channel-scoped permissions	Topic-based; account optional for free use, required for paid features
Delivery model	Directed delivery with per-destination tracking	Pub/sub topic storage (no per-recipient log)

There are some real points in here we want to call out specifically.

ntfy is open source and self-hostable. We are not. This is the most important difference for a meaningful subset of developers. If you care about FOSS values, if you want to run your notification infrastructure on your own server, if you want to be able to read the source code that handles your data, ntfy wins on principle. We are a managed closed-source SaaS and we are not pretending otherwise. There is no version of API Alerts you can self-host. If self-hosting is a hard requirement, this is the end of the comparison and the answer is ntfy.

ntfy’s free tier is dramatically more generous than ours, and this is by design on both sides. ntfy lets you send messages without an account using topic names as passwords. We require an account and cap the free tier at 1,000 events per month. As covered in the framing section above, this is two tools sized for two different volume profiles, not one tool being stingy and the other being generous. ntfy is built to handle high-volume push including the activity-stream zone. API Alerts is built for the opposite end of that spectrum.

ntfy is funded by donations and sponsorships. We are not. ntfy is supported via GitHub Sponsors, Liberapay, and corporate sponsors including MagicBell, DigitalOcean, Warp, and ChangeDetection.io. We are a commercial SaaS with subscription pricing. Both models are legitimate, but they create different incentives. If you prefer to support tools that are not beholden to growth-at-all-costs incentives, that matters and we respect it.

When to choose ntfy

We mean it when we say ntfy is the right answer for some developers. Pick ntfy if any of the following apply:

You care about open source. ntfy is dual-licensed under Apache 2.0 and GPLv2, with the source on GitHub. You can read it, audit it, fork it, contribute to it. We are not open source, and we are not going to be in the foreseeable future. If FOSS values are non-negotiable for you, ntfy is the right pick and we recommend it without hesitation.
You want self-hosted. ntfy ships an “ntfy Server” you can run on your own infrastructure. Your data, your servers, your control, no SaaS in the loop. If self-hosting is a hard requirement, ntfy is the only honest choice between us and them. We do not offer a self-hosted version of API Alerts and we are not building one.
You want truly anonymous use. ntfy lets you publish notifications without creating an account by treating topic names as passwords. Pick a hard-to-guess topic name and you are publishing to a private channel without ever giving ntfy your email address. We require an account and a workspace before you can send anything.
You are sending high-volume push notifications. ntfy’s paid tiers comfortably handle 2,500, 20,000, or 50,000 messages per day on the Supporter, Pro, and Business plans respectively. Our largest tier is sized for a fraction of that volume because we are built for the high-signal end of the spectrum, not the activity-stream end. If volume is your primary need, ntfy is dramatically cheaper per message.
You only need push notifications and you want simplicity. ntfy is a single-channel tool that does one thing extremely well. The mental model is simple, the API is one HTTP request with no auth required for free use, and there is nothing to configure beyond the topic name. If you do not need routing rules, multi-channel destinations, or team features, ntfy’s simplicity is a feature, not a limitation.
You prefer tools funded by donations rather than venture capital. ntfy is built and maintained by Philipp Heckel, funded by GitHub Sponsors, Liberapay, and corporate sponsors. The funding model creates an incentive structure focused on serving the existing community rather than chasing growth metrics. If that matters to your decision-making, it matters and we respect it.

If any of these match you, ntfy is the right choice and we recommend it without hesitation. You can sign up at ntfy.sh (or self-host straight from the GitHub repo) and you can stop reading here. We will not be offended.

When to choose API Alerts

API Alerts is the right answer when push notifications alone are no longer the whole problem.

You need to route events to multiple channels. Push to your phone for “new paid user,” Slack to your team channel for “deploy completed,” SMS for “production server down at 2am,” email for “weekly digest.” One event from your code, multiple destinations. ntfy delivers push only. We were built for the routing problem from the start.
You want native SDKs as a convenience, but you are also fine with raw HTTP. API Alerts ships native SDKs for JavaScript, Python, Go, Kotlin, Swift, Rust, Java, C#, PHP, Ruby, Dart, and Godot. The SDKs exist as a quality-of-life layer: better error messages when something goes wrong, easier opt-in to new features and properties as we add them, and a three-line integration when you want it. They are not a hard requirement. The API Alerts HTTP endpoint is a single POST request, exactly like ntfy’s, and works fine if you would rather skip the SDK and call it directly. The SDKs are there when you want them and out of your way when you don’t.
You have a team and want channel-scoped permissions. API Alerts has workspaces with multiple channels, and you can give different team members access to different channels. ntfy’s model is built around topics rather than team workspaces, and team coordination is something you would have to layer on top yourself (probably with a self-hosted instance plus your own access control).
You are building something that might outgrow push-only. This is the most important reason. If you start with push notifications today, but you can imagine a future where you also want Slack alerts for your team, SMS for critical events, or email for daily digests, you should not pick a tool that locks you into a single channel. API Alerts is designed to grow with your project. ntfy is designed to do one thing extremely well, and that one thing is push.
You want to ingest events from third-party tools and route them. API Alerts has webhook ingestion and routing rules, so you can pipe Stripe payment events, Segment user events, or PostHog product events through us and route them to wherever your team works. ntfy does not have a comparable ingestion-and-routing model.
You want directed delivery with per-destination tracking, not pub/sub. API Alerts delivers each event to specific configured destinations (push to specific devices, Slack to specific channels, SMS to specific numbers, webhooks to specific URLs) and tracks each delivery individually. The dashboard shows you which destinations received which events, when, and whether the delivery succeeded. ntfy uses a pub/sub model: messages are stored in topics and subscribers consume them, but the publisher does not have visibility into which subscribers received what, when, or whether any specific recipient got the alert. Both models are legitimate, but if you want a publisher-side audit log of “did this critical alert actually reach the on-call engineer’s phone, and if not, why not,” that visibility is what the directed-delivery model gives you. We also retry failed deliveries automatically at the destination level, which is something pub/sub does not need (and could not do) by design. Your data stays yours, you can delete it whenever, and we never sell or share it or pipe it through our own analytics.
You want API key authentication, owned workspaces, and rotatable credentials. API Alerts uses standard API key authentication, with each key scoped to a workspace you own and optionally to specific channels within it. Keys live in the request header, not in the URL, so they don’t end up in server logs, browser history, or screenshots by accident. If a key is ever compromised, you can rotate it from the dashboard and update your code. Workspaces are owned by accounts, channels are scoped within workspaces, and team permissions are channel-by-channel via workspace membership rather than by sharing a secret. The model is the same as Stripe, Twilio, or any SaaS API you already integrate with. It is not as elegant as ntfy’s accountless “topic name as password” approach (which is genuinely a clever design for the use case it serves), but if your notifications carry sensitive information or you need the ability to rotate access cleanly when something changes, the auth-first model is the right tool for that job.

Code comparison

Sending a notification from a Python script with both tools.

ntfy:

import requests

requests.post("https://ntfy.sh/mytopic", data="Build complete")

API Alerts:

from apialerts import APIAlerts

alerts = APIAlerts("YOUR_API_KEY")
alerts.send(channel="ci", title="CI", message="Build complete")

ntfy’s API is genuinely simpler than ours for the simplest case. There is no auth, no payload structure, no API key. Type a topic name into the URL and POST a string. That simplicity is a real feature and we are not going to pretend otherwise.

The differences become visible when you want to:

Send the same event to multiple destinations without writing fan-out code yourself
Add structured tags, deep links, and metadata as first-class fields rather than embedding everything into a single message body
Switch where a channel delivers without changing your application code
Verify after the fact that a specific notification actually reached its destination

For a single push to your own phone, ntfy is honestly more elegant. For anything where you care about the structure or what happens after the call, the differences start to matter.

Pricing at realistic usage points

Three example developers, both tools, real numbers.

The hobby developer (around 50 messages per month)

ntfy: Free without sign-up. Topic name acts as the security boundary. Total over 12 months: $0.
API Alerts: Free tier handles this comfortably (well under our 1,000/month limit). Receiver app is free. Total over 12 months: $0.

For low-volume push-only use, both are essentially free. ntfy is structurally simpler because you do not need to create an account at all.

The high-volume push automation use case (around 5,000 messages per month, push only)

This is a use case API Alerts is not designed for, and we want to call that out directly rather than competing on price for a workload we are not built for.

ntfy: Comfortable on free or Supporter tier. The Supporter tier at $6/month (or $5/month with annual billing) allows 2,500 messages per day (around 75,000 per month), which is more than 15x the volume in this scenario. Total over 12 months: $0 to $72 monthly, or $60 with annual billing, depending on whether you sign up for the paid tier to support the project.
API Alerts: 5,000 events sits right at the Solo tier ceiling. Pick Solo at $12/month ($144 monthly, $120 annual) to run close to cap, or step up to Team at $30/month ($360 monthly, $300 annual) for 25,000 events of headroom and unlimited team members.

ntfy is dramatically cheaper here, AND it is the better fit for the use case. We mean both halves of that sentence. 5,000 push notifications per month is the sort of volume that suggests automated activity streams, status pings, or scheduled aggregations rather than high-signal alerts. ntfy is built for that and serves it well. API Alerts is built for the opposite end of the spectrum. If your use case is high-volume push automation, ntfy is genuinely the right call and we are not going to compete for it on price or features. We would also gently suggest taking a look at what those 5,000 events are. If any of them are routine enough that you regularly skim past them or filter them away, your alerts may already be drifting into background noise, and the right move is fewer events rather than a bigger tier.

The startup with a small team (around 5 users, multi-channel routing, around 10,000 events / month)

ntfy: ntfy is push-only and topic-based. There is no Slack delivery, no SMS, no email, no WhatsApp, no team workspace model. To make this scenario work, you would need to glue ntfy together with separate Slack, Twilio, and email tools yourself, or maintain separate accounts on multiple platforms.
API Alerts: Team tier at $30/month covers up to 25,000 events/month with unlimited team members, with all channels (push, Slack, SMS, WhatsApp, email, webhooks) included in one subscription. Total over 12 months: $360 monthly, or $300 with annual billing.

This is the scenario where we win, and we win because the comparison stops being apples-to-apples. ntfy does not solve the multi-channel routing problem for teams. We do.

FAQ

Can I migrate from ntfy to API Alerts?

Yes, the integration pattern is similar enough that the migration is mostly mechanical. Both services accept HTTP POST requests with a message body, so the wire format is straightforward to swap. You can run both in parallel during the transition: send each event to both services until you are confident the API Alerts version is delivering correctly, then drop the ntfy call. We do not have a dedicated migration tool because the integration is small enough to migrate by hand in most codebases.

Does API Alerts offer a self-hosted version like ntfy does?

No, and we want to be clear about it. API Alerts is a managed SaaS only. We are not building a self-hosted version of the platform in the foreseeable future. If self-hosting is a requirement for you, ntfy is the right tool and we recommend it without reservation.

Why is API Alerts’ free tier 1,000 messages per month when ntfy is effectively unlimited?

Honest answer: because we are sizing the free tier for our design philosophy, not for raw volume. API Alerts is built for high-signal alerting, where every event you send is something you actively want to see in the moment it happens. The 1,000 number is what one developer would generate if they treat each event as something genuinely worth being interrupted for. ntfy is built for a wider band including the high-volume zone, and its pricing reflects that. We are intentionally not trying to compete in that volume space, because we believe the right answer at that scale is usually fewer events, not a bigger free tier. We are unlikely to ever match ntfy’s effectively-unlimited tier because that would imply chasing a use case we deliberately do not serve.

Can I use both ntfy and API Alerts at the same time?

Yes. Some developers use ntfy for personal high-volume push notifications (home automation events, monitoring streams, IoT sensors) and API Alerts for the high-signal team-aware events (paid users, deploys, critical alerts) that need routing to multiple channels. There is no conflict. The two tools serve different jobs and compose well.

How is API Alerts’ delivery audit log different from ntfy’s topic-based message storage?

Both API Alerts and ntfy store messages on the server. The architectural difference is in how delivery is tracked, not whether messages are stored at all.

ntfy uses a pub/sub model. Messages are published to topics, subscribers read from topics, and the ntfy server stores messages in a configurable cache. The publisher’s request returns 200 and the message persists in the topic until subscribers consume it (or until the cache expires). The publisher does not have visibility into which subscribers consumed which messages, when, or whether any specific recipient received their alert. The pub/sub architecture is by design and serves the use cases ntfy is built for, including many-to-many broadcast notifications and the case where the publisher genuinely does not need to know who is listening.

API Alerts uses directed delivery with per-destination tracking. Each event is delivered to specific configured destinations: push notifications to specific devices, Slack messages to specific channels, SMS to specific phone numbers, webhooks to specific URLs. Each delivery is tracked individually. The dashboard shows you which destinations received which events, when, whether the delivery succeeded or failed, and what the error was if it failed. If you want a publisher-side audit log of “did this critical alert actually reach the on-call engineer’s phone, and if not, why not,” that visibility is what the directed-delivery model gives you that pub/sub does not.

Different architectures, different visibility surfaces, both legitimate. Pub/sub is more elegant for many-to-many notification distribution where the publisher does not care about specific recipients. Directed delivery with per-destination tracking is more useful for targeted alerts where the publisher does care about specific recipients getting through. They optimize for different things.

That said, “we store your events” is a sentence developers (rightly) read carefully. So the rest of the answer:

Your events are yours. You own them, you can delete them whenever you want, and the dashboard has direct controls for deletion at the event, channel, and workspace level.
We never sell or share your data. Not to advertisers, not to analytics platforms, not to anyone. Storage is operational, not extractive.
Your event data is never piped into our own internal analytics. This is unusual and worth saying explicitly. Most SaaS tools pipe customer event data through their product analytics so they can build dashboards about usage. We deliberately don’t do that with your event data. Storage exists to serve your routing, retry, and audit needs, not ours.

How does API Alerts’ authentication model compare to ntfy’s “topic as password” approach?

They are two genuinely different security models, optimized for different use cases. Both are legitimate design choices and we want to describe them accurately rather than lean on either one.

ntfy’s free public tier treats the topic name itself as the secret. There is no account or API key. Anyone who knows the topic name can publish to it or subscribe to it. It is the same pattern as Google Docs “anyone with the link” sharing or AWS S3 pre-signed URLs: secrecy through unguessable URLs. The convenience of “no account needed” is the whole point of the design, and it works well for personal hobby projects, home automation, and low-stakes notifications. For stronger access control, ntfy also offers reserved topics on its paid plans (where you reserve a topic name to your account so others cannot publish to it) and full authentication on self-hosted instances.

API Alerts uses standard API key authentication. Every event sent to API Alerts requires a valid API key passed in the Authorization header. Keys are scoped to workspaces you own, and optionally to specific channels within them. Keys can be rotated from the dashboard if you suspect compromise, and the new key works immediately while the old one is invalidated. Team members get channel-by-channel permissions through workspace membership rather than by sharing a secret. The model is the same as Stripe, Twilio, or any SaaS API you already integrate with.

Which one is right for you depends on what you are sending. If your notifications are low-stakes and the convenience of accountless use matters more than rotatable credentials, ntfy’s free tier fits the use case nicely. If your notifications include sensitive information (customer data, payment details, PII, credentials, internal team alerts) or if you need to be able to revoke access cleanly when team members change, the auth-first model is the right tool. Use whichever fits.

How does ntfy compare to other indie push notification tools?

If you are weighing ntfy alongside other tools in this space, we have honest comparisons of the two main alternatives we know about: see our Pushover comparison and our Pushbullet comparison (coming soon). The short version: Pushover is a paid one-time-purchase service that has been doing one thing reliably for over a decade, Pushbullet is the older cross-device service, and ntfy is the open-source self-hostable option. Each one fits a different audience and a different set of values.

Where can I learn more about ntfy?

ntfy.sh is the official site. The GitHub repo is where development happens. There are active community channels on Discord and Matrix linked from the site. The documentation is clear, well-maintained, and a good model for a focused open-source project.

Get started

If API Alerts is the right fit for your use case, you can create a free workspace and send your first event in about five minutes. The free tier is 1,000 events per month, no credit card required.

If ntfy is the better fit for what you need (open source, self-hosted, single-channel push, high volume, or all of the above), head to ntfy.sh instead. We mean it.

Pricing and feature claims about ntfy were verified against ntfy.sh. If anything on this page becomes inaccurate as ntfy or API Alerts evolves, please let us know and we will update it.