Notibase vs OneSignal

Comparison pages written by vendors are usually worthless, because the vendor picked the axes. So here is the deal: this page is written by us, we are obviously not neutral, and we have tried to make it useful anyway — including a section on when you should not choose us.

Two things we will not do. We will not quote OneSignal's pricing or limits, because those change and a stale number on a competitor's page is just a lie with a date on it — check their pricing yourself. And we will not claim they are bad at what they do. OneSignal is a mature product used by an enormous number of applications, and it earned that.

The short version

Notibase is built for the person who will be debugging the notification at 2am, not the person who will be presenting a campaign report on Thursday. That single choice explains almost every difference below.

If your notifications are a marketing channel run by a marketing team, a mature marketing suite is a reasonable thing to want. If your notifications are part of your product — the order shipped, the build finished, the message arrived — you are going to care about different things, and those are the things we built.

Where we are actually different

The delivery log shows the provider's raw response

When a push fails, Notibase records what APNs or FCM literally said, per device, and shows it to you. Not "failed". Not a category. The response body.

This sounds like a small thing until the first time a send half-works and nobody can tell you why. Most of the debugging questions in push have exactly one answer, and the provider already gave it to you — the only question is whether your platform kept it.

We also normalise errors into a small taxonomy on top of that (documented here), because "the token is dead" and "your credentials are wrong" need completely different responses from you, and a single failed state cannot tell you which happened.

Zero-dependency SDKs

The web SDK has no dependencies. The Node SDK has no dependencies. The iOS SDK is Foundation-only. The Android SDK is plain Kotlin over platform APIs — no androidx, which means it cannot conflict with the androidx version your app already pins. Flutter has one (shared_preferences).

This is not a purity contest. Every dependency an SDK drags in is a version conflict you might have to resolve on a deadline, and a supply-chain surface you did not choose.

Honest limits, written down

Our docs say that iOS cannot declare action buttons in a payload, that web push subscriptions die if you rotate your VAPID keys, that FCM data values must all be strings or the entire send fails, and that macOS ignores notification persistence. Those are not our features, they are the platform's constraints — and finding them out from a docs page is enormously cheaper than finding them out from a support ticket.

Everything is an API first

There is no feature in the console that is not an endpoint. The console is a client of the same public API you use, authenticated with a session instead of a key. If you want to do something from CI, you can.

A publishable-key model that is actually enforced

Client keys (ck_) can register devices and track events. They cannot list your audience, cannot read your delivery logs and cannot send anything. Server keys (sk_) never belong in a browser, and the SDK throws loudly if it sees one. That boundary is enforced server-side, per route, and tested.

Where OneSignal is the better choice

We would rather you pick the right tool than pick us.

• You need email and SMS in the same platform. Notibase is push, in-app inbox and live messages. Email and SMS are on our roadmap, not in the product. If you need one vendor for everything today, that is a real reason.
• You need journey builders and visual automation. Our campaign triggers are early. If your team designs multi-step lifecycle journeys in a canvas, you will find us thin.
• You need a large marketing feature surface — A/B testing, templates managed by non-engineers, deep segment analytics dashboards. Some of that we have, some is queued, some we may never prioritise.
• You are not technical and want to never see an API. Our console is good, but the product is unapologetically built for developers.
• You need a vendor with a long compliance paper trail — SOC 2 reports, procurement questionnaires, an enterprise support contract with an SLA. We are a young company and we will not pretend otherwise.

Where we are comparable

Both platforms do web push over VAPID, APNs over token-based auth, and FCM over the HTTP v1 API, because those are the only ways to do it. Both give you segmentation, scheduling, delivery statistics and a REST API. Both have SDKs for the platforms you would expect.

The underlying delivery is the same three providers for everyone in this category. Anybody claiming a fundamentally better delivery rate is selling something — what differs is what happens around the send.

Migrating from OneSignal

You can bring your audience over. The honest version:

What migrates cleanly. iOS and Android tokens, your user identifiers, and any attributes you export. Notibase reads a OneSignal CSV export directly and maps the columns itself, including notification_types — so people who unsubscribed stay unsubscribed rather than getting a surprise notification from a platform they never heard of. That last part matters more than it sounds.

What does not. Web push subscribers, unless you have the original VAPID private key. This is not a limitation either vendor invented: a browser subscription is cryptographically bound to the key pair that created it, and nobody can move it without that key. Most providers will not export it. Plan for rebuilding your web audience, or check first.

The full walkthrough is in Importing an audience, including a dry run that shows you exactly what would happen before anything is written.

Trying it

The fastest honest test is not a feature matrix, it is ten minutes: send yourself a push from the demo page with no signup, then create an account and get a notification onto your own device. If the delivery log tells you something useful the first time something goes wrong, that is the whole pitch.