*Last updated: July 2026*

## Key takeaways

- An in-app notification center is a persistent inbox inside your app, usually opened from a bell icon, where users review activity, alerts, and updates at their own pace.
- Push notifications and toasts vanish. The notification center keeps a browsable history, which is what cuts missed actions and support tickets.
- The strongest strategy combines channels: push for urgency, a toast for instant in-app confirmation, the in-app inbox for persistence, and email as a fallback.
- Real-time delivery over WebSockets, cross-channel state sync, action buttons, and per-user preferences are what separate a basic inbox from a great one.
- Building one from scratch runs three to six months. A drop-in component gets you there in days.

## What is an in-app notification center?

An in-app notification center is an interface inside your app, whether that's a web app or a mobile app, that shows a history of notifications and updates. Think of it as a persistent record of everything that happened while a user was away, or anything they missed while doing something else in your product.

Open GitHub or LinkedIn and there's a bell icon at the top of the screen. You tap it and see everything since you last checked: comments, mentions, likes, follows. That's an [in-app notification center](https://www.courier.com/platform/inbox) doing its job well enough that you don't think about it.

![A notification center concept illustration showing a bell icon and message list](//images.ctfassets.net/z7iqk1q8njt4/CRLuQCQ3Iu5tO8sBALiDl/b5b54c2eb11d25a64b7e3c213ba4652c/Frame_163978.png?w=600)

Those little bells with dots in the corner of an app have become a standard expectation. If you're building anything where events happen and users need to know about them, you'll want one sooner or later.

### How an in-app notification center shows up in your app

Most notification centers follow the same pattern: a bell icon in the header or nav bar, an unread badge showing the count of new messages, and a panel that opens to reveal the message list.

![Notification bell icon in filled, outlined, ghost, and minimal styles](//images.ctfassets.net/z7iqk1q8njt4/2ls6SwoOXyFTlObhFLabR3/1b137dd4ba2aa666b53e38b531261f29/popup_button_variants.png?w=600)

The bell comes in different styles depending on your design system. Filled and outlined variants suit bold UI; ghost and minimal styles fit cleaner interfaces. The dot signals unread messages at a glance, before a user even opens the panel.

![Notification center dropdown panel with tabbed views and unread indicators](//images.ctfassets.net/z7iqk1q8njt4/1DycgLG9gv2x3R28RthUNP/1b29c85a2937ec6f62a1768710f89691/popup_notifications.png?w=600)

Tapping the bell opens a dropdown, the most common pattern and the same interaction you've used on GitHub, Slack, and LinkedIn. The dropdown holds the core elements: tabbed views (all, unread, archived), an unread dot next to each new message, previews with timestamps, and the unread badge on the tab itself.

How the in-app inbox renders, and how users reach it, depends on the platform. In a web app it's usually a dropdown from the bell that updates live while the tab is open. In a mobile app, on both iOS and Android, it's more often a full-screen inbox that follows the platform's design guidelines, and it pairs with push so users still hear about something when the app is closed. The concept is the same on both; chapter 2 covers the setup differences.

A complete in-app inbox gives each notification a title, description, category tag (analytics, billing, team, engineering), and optional action buttons, with read and unread states clearly distinguished. A settings gear gives users access to their [notification preferences](https://www.courier.com/platform/preferences-management), and light and dark themes are both common.

That persistence is what makes the notification center valuable, especially once notification fatigue sets in and users start silencing your other channels. Push notifications show up outside your app and demand attention whether the user wants to give it or not. [Toast messages](https://www.courier.com/blog/what-is-a-toast-message) appear inside your app but vanish after a few seconds, fine for a quick confirmation but useless for anything a user might want to reference later. The in-app inbox sits there, patient and reliable, keeping the record.

### Notification center vs. push vs. toast vs. email

Every notification type has its place. The mistake most teams make is using one channel for everything. For the tradeoffs, see [when to use push versus in-app messages](https://www.courier.com/blog/in-app-messages-vs-push-notifications-differences-when-to-use-them).

| | In-app notification center | Push notifications | Toast messages | Email |
|---|---|---|---|---|
| **Persistence** | Permanent until archived | Stays in OS tray until dismissed | Disappears in 3-5 seconds | Permanent in mailbox |
| **User context** | Inside the app | Outside the app (OS-level) | Inside the app | Outside the app |
| **Best for** | Activity history, approvals, updates | Re-engagement, urgent alerts | Action confirmations, status updates | Detailed content, records, receipts |
| **User control** | Full (filter, archive, preferences) | Limited (on/off per app) | None (auto-dismiss) | Full (unsubscribe, folders) |
| **Delivery** | Real-time over WebSocket | Via FCM / APNs | Triggered by in-app events | Async over SMTP |
| **Risk if overused** | Inbox overload | Notification fatigue, uninstalls | Missed critical info | Email fatigue, spam |

The strongest strategies use these channels together. An in-app notification center paired with [multi-channel routing](https://www.courier.com/platform/multi-channel-routing) lets you send a push for urgency, show a toast for immediate confirmation, record the message in the inbox for later, and fall back to email if the user doesn't engage.

### Toasts vs. notification center messages, side by side

Toasts and notification center messages serve different purposes.

![Toast notification appearing at the edge of the screen with an action button](//images.ctfassets.net/z7iqk1q8njt4/25ArY7wUMItjIfLv1q74Kb/e91f8050dc917c785469bc3a6aeab81e/toast_light.png?w=600)

Toasts are transient. They appear at the edge of the screen, deliver a brief message ("Your report is ready"), and either auto-dismiss or wait for the user to close them. Some include an action button or a countdown bar. Once they're gone, they're gone. The in-app inbox gives that same message a second life: even if the user was away when the toast appeared, they'll still find it in their inbox.

## Why an in-app notification center matters

User expectations aren't going away. Nearly every app people use daily has trained them to expect this. When users open your app to see what they missed, they go looking for a notification center. Without one, you're fighting learned behavior.

The whole point is to let users review notifications on their own timeline, not yours. Sometimes they're mid-task and can't deal with something the moment it arrives. Sometimes they dismiss it by accident. The in-app inbox gives them the flexibility so a missed notification doesn't mean missed information.

The business case is straightforward. Notification centers increase engagement, because users have a reason to open the app and check what's new. They give you a second chance at communication, so the approval request someone missed at 3pm still gets seen when they check at 9am. And they cut the failure rate of time-sensitive actions and reduce support tickets, because there's a persistent record of what happened.

## Common use cases

An in-app notification center works across almost any app where activity happens and users need to know. The patterns hold whether you're building a social network, a project management tool, or a [healthcare app](https://www.courier.com/solutions/healthcare).

[Product notifications](https://www.courier.com/blog/transactional-product-and-marketing-notifications-what-are-the-differences) are the obvious ones: comments on a document, mentions in a thread, tasks that need doing. Status changes fit here too, like an order shipping, a payment clearing, or an export finishing. Approval workflows are a natural match, because they need action but not always immediate action. Someone has to review a budget or approve a feature flag, and the inbox gives them one place to see pending requests without feeling nagged.

System notifications cover the administrative side. [Security alerts](https://www.courier.com/solutions/alert-notifications) are the clearest example: logins from new devices, suspicious activity, password changes. Those need a permanent home, not a flash on screen. Billing and payment notifications belong here too, along with feature announcements, though you'll want to be careful about using the inbox for marketing.

### Real examples

[DroneDeploy](https://www.courier.com/blog/courier-inbox-complete-notification-center-web-mobile) makes drone mapping software for construction sites. They use their notification center for status updates when new maps and progress videos finish uploading. Those files are large and take time to process, so the inbox gives users a place to check back instead of waiting around. They also handle access-permission requests through it.

[LaunchDarkly](https://www.courier.com/use-cases/launchdarkly) built their feature-flag approval workflow around their notification center. When someone requests a new flag or an approval to change one, the notification reaches the right people instantly, and the inbox keeps a clear record of who requested what and when. They also use it for team changes, new invites, and billing alerts. (Chapter 4 has more on how these teams weighed building versus buying.)

## Key components

If you're adding an in-app notification center or evaluating one, some features are effectively mandatory and others separate a decent implementation from a great one.

![Notification center capabilities overview](//images.ctfassets.net/z7iqk1q8njt4/4clQh5YuosGuk4Ec7VoY93/58eec77ca418b9d6036dd03186755e0b/Frame_163968__5_.png?w=600)

### Mandatory features

You need a message list with clear read and unread states, so users know at a glance what they've seen. [Real-time delivery](https://www.courier.com/docs/platform/inbox/inbox-overview#real-time-delivery) is the next requirement: messages should appear instantly over a persistent connection, not five minutes later after a manual refresh. Archiving or deletion lets users manage the inbox. Unread badges on the bell tell them something's new without opening it. And [preferences](https://www.courier.com/platform/preferences-management) are essential, because not everyone wants the same notifications at the same frequency.

### Advanced capabilities

[Cross-channel synchronization](https://www.courier.com/docs/platform/inbox/inbox-overview#cross-channel-integration) is the most underrated feature here: it keeps a notification's read state consistent across channels, so if you read the email, the matching inbox notification is already marked read when you open the app. Courier handles it automatically across email, SMS, push, and in-app, which is what stops users from seeing the same notification over and over. Chapter 2 covers how it works.

Action buttons turn the notification center from a read-only log into a productivity tool. Instead of reading "Sarah needs approval on the Q4 budget," the user sees approve and reject buttons right there. They act without navigating to another screen. Every extra click is a chance to get distracted, and action buttons remove that friction.

![Notification layouts: standard, with action buttons, and compact](//images.ctfassets.net/z7iqk1q8njt4/47X0t2GzjxnLtNQF0tEJZQ/08ea2c2cb016d055842daa3d58331636/layouts.png?w=600)

Most notification centers support a few layout variants for different message types. Standard notifications show a title, description, and category tag. Notifications with actions add primary and secondary buttons in the row. Compact notifications condense everything to a single line for low-priority updates like deploy confirmations. Matching the layout to the message keeps the inbox scannable.

![Empty state for a notification center with a refresh action](//images.ctfassets.net/z7iqk1q8njt4/78r3kASx41J9SCr43L388a/36492a94a88f39b05f45af4e35f49cd2/no_messages.png?w=600)

Empty states matter more than most teams think. When a user opens their inbox for the first time or clears it out, what they see sets the tone. A good empty state confirms the feature works ("When you receive notifications, they'll appear here") and offers a clear action. It's a small thing that prevents confusion and support tickets.

Message filtering and views help manage the chaos of an active inbox. The basics cover unread, all, and archived. Better systems let you build custom views by tag, category, or date range. And message expiration keeps things tidy: "Your trial expires in 3 days" loses all meaning once the trial ends, so time-sensitive notifications can auto-clear after a set period instead of piling up.

All of these work together as a system. Real-time delivery doesn't matter much if cross-channel sync is broken. Action buttons lose their value if state management can't track what happened. You need the whole thing working together.

## In-app notification center glossary

| Term | What it means |
|---|---|
| **In-app notification center** | A persistent interface inside your app, usually opened from a bell icon, that stores a browsable history of notifications. |
| **In-app inbox** | The message-list surface of the notification center, rendered as a dropdown or a full page. |
| **Toast** | A transient in-app message that appears briefly and auto-dismisses. Good for confirmations, not for history. |
| **Push notification** | An OS-level message delivered through APNs or FCM, shown even when your app is closed. |
| **Cross-channel sync** | Keeping a notification's read/archived state consistent across inbox, email, SMS, and push. |
| **Digest** | One notification that groups many similar events ("10 new comments") to cut interruption. |
| **WebSocket** | A persistent, two-way connection used to deliver notifications in real time instead of polling. |

## Adding an in-app notification center to your app

[Building from scratch](https://www.courier.com/blog/how-to-build-a-notification-center-for-web-and-mobile-apps) runs three to six months of engineering: WebSocket infrastructure, state management, cross-channel sync, UI components, and ongoing maintenance. A platform like [Courier](https://www.courier.com/platform/inbox) cuts that to days.

Here's a basic React in-app notification center with Courier's [drop-in component](https://www.courier.com/platform/inbox):

```jsx
import { CourierInbox, useCourier } from "@trycourier/courier-react";
import { useEffect } from "react";

export default function NotificationCenter() {
  const courier = useCourier();

  useEffect(() => {
    // Generate the JWT on your backend, never in client-side code
    courier.shared.signIn({
      userId: "user_123",
      jwt: "your_jwt_token",
    });
  }, []);

  return <CourierInbox />;
}
```

That gives you a working inbox with real-time delivery, read and unread state, badge counts, and infinite scroll, all out of the box. Courier ships native SDKs for [React](https://github.com/trycourier/courier-web), [React Native](https://github.com/trycourier/courier-react-native), [iOS](https://github.com/trycourier/courier-ios), [Android](https://github.com/trycourier/courier-android), and [Flutter](https://github.com/trycourier/courier-flutter), so the same in-app notification center works across every platform your users are on.

For the full walkthrough with customization, theming, and multi-channel routing, keep going to chapter 2.

## Frequently asked questions

### What is an in-app notification center?

An in-app notification center is an interface inside your app, usually opened by tapping a bell icon, that shows a persistent history of notifications, alerts, and updates. Unlike push notifications or toasts that disappear, it lets users review and act on notifications at their own pace. Most modern SaaS and mobile apps include one as a standard feature.

### What is a notification bell?

The notification bell is the icon in an app's nav bar or header that opens the notification center. It usually shows a badge with the count of unread messages, and tapping it opens the in-app inbox or dropdown. Bell icons come in filled, outlined, ghost, and minimal styles depending on the design system.

### How do I add a notification center to my app?

You can build one from scratch or use a notification platform. Building it yourself means WebSocket infrastructure, state management, UI components, and cross-channel sync, typically three to six months of work. Platforms like [Courier](https://www.courier.com/platform/inbox) give you a pre-built, customizable component you can add in days with a few lines of code, across React, React Native, iOS, Android, Flutter, and vanilla JavaScript.

### What's the difference between push notifications and an in-app notification center?

Push notifications are delivered at the OS level and appear on the lock screen or tray even when your app is closed, which makes them best for re-engagement and urgent alerts. An in-app notification center lives inside your app and gives users a persistent, browsable history they can filter, archive, and act on. The strongest strategies use both: push for immediacy, the in-app inbox for persistence.

### Do notification centers work on web and mobile apps?

Yes, on both. In a web app, the notification center usually renders as a dropdown from the bell icon. In a mobile app, it more often opens as a full-screen inbox that follows iOS and Android design guidelines. Courier ships native SDKs for web apps ([React](https://github.com/trycourier/courier-web) and vanilla JavaScript), iOS apps ([Swift](https://github.com/trycourier/courier-ios)), and Android apps ([Kotlin](https://github.com/trycourier/courier-android)), plus [React Native](https://github.com/trycourier/courier-react-native) and [Flutter](https://github.com/trycourier/courier-flutter). Cross-device sync means a notification read in your web app also shows as read in your iOS or Android app.

---
---


An in-app notification center is a persistent inbox inside your web or mobile app. Learn what it is, why it matters, and the components that make one great.

What Is a Notification Center? In-App Guide

What an in-app notification center is, how it differs from push, toast, and email, and the components that separate a basic inbox from a great one.

What Is an In-App Notification Center?

*Last updated: July 2026*

## Key takeaways

- An in-app notification center is three layers working together: a backend that decides what to send, a delivery layer that gets it there in real time, and a frontend that renders the inbox.
- Real-time delivery means WebSockets, not polling. That's where most of the hard engineering lives: reconnection, offline sync, and connection health.
- With Courier, you install one SDK, call `signIn` with a user ID and a backend-generated JWT, and render the `CourierInbox` component. The same pattern holds across React, iOS, Android, React Native, and Flutter.
- One API call sends the same notification to the in-app inbox, email, push, SMS, and chat, and adapts the content to each.
- A web app and a mobile app follow the same install, sign-in, render pattern, but under different constraints: browser tab lifecycle and optional web push on web; OS app suspension, push permission, and native rendering on mobile.

## Architecture overview

Adding an [in-app notification center](https://www.courier.com/docs/platform/inbox/inbox-overview) means coordinating three layers that have to work together smoothly enough that users never think about the complexity underneath.

![Notification center architecture: your app, the notification service, the delivery layer, and where notifications land](//images.ctfassets.net/z7iqk1q8njt4/xfmkGk3obw2HeIuZSbcV7/131f73eb59bc96185c6d6fc6d78b49a1/notification-center-architecture.png?w=600)

The **backend layer** is where everything starts. Your app triggers an event whenever something happens that users might care about: someone comments, an order ships, a payment fails. The notification API receives that event and works out who should get it, what it should say, and where it should go. Routing decides which channels to use based on your rules and each user's preferences. This layer is mission control, handling the logic before anything reaches a user.

The **delivery layer** is all infrastructure. WebSocket connections handle real-time delivery, because HTTP polling is too slow for what users expect now. Message persistence makes sure nothing is lost if a user is offline when the notification fires. State synchronization keeps everything consistent across devices. And integration with APNs and FCM handles mobile push. This layer doesn't make decisions, it executes on them reliably.

The **frontend layer** is what users see and touch, across your web app and your mobile apps. [UI components](https://www.courier.com/docs/sdk-libraries/courier-ui-inbox-web#styles-and-theming) render the inbox, toasts, and badges. State management tracks which notifications are read, unread, or archived. Authentication keeps it secure. Real-time updates make new notifications appear without any action from the user.

Every layer has failure modes. WebSockets drop. Databases go down. Users lose connectivity. Mobile apps get suspended by the OS. A reliable notification center needs retry logic, queuing, fallbacks, and more monitoring than you'd expect. This is why teams who start building in-house often either abandon the project or ship something that technically works but doesn't feel reliable.

## SDK and platform support

Courier ships native SDKs for every major platform, so the same in-app notification center works across your web app, iOS app, and Android app. Install method and minimum versions vary.

| Platform | Package | Install method | Minimum version |
|---|---|---|---|
| Web (React) | `@trycourier/courier-react` | npm | React 16+ |
| Web (vanilla JS) | `@trycourier/courier-ui-inbox` | npm | Any framework |
| iOS | `courier-ios` | Swift Package Manager | iOS 15+ |
| Android | `courier-android` | Gradle via JitPack | Android 5.0+ |
| React Native | `@trycourier/courier-react-native` | npm + CocoaPods | iOS 15+, Android 5.0+ |
| Flutter | `courier-flutter` | pub.dev | Flutter 3.0+ |

Each SDK ships the same core capabilities: real-time delivery over WebSockets, cross-device state sync, and the pre-built `CourierInbox` component. The component renders with a default theme and accepts configuration objects for custom styling.

## Core capabilities

### Real-time delivery

Real-time delivery is non-negotiable for a modern in-app notification center, and it means WebSocket connections, not HTTP polling. The moment someone comments on a post or approves a request, the notification should show up with no action from the user.

The catch is that WebSockets are stateful connections, so they break in ways HTTP requests don't. Users lose connectivity constantly: elevators, tunnels, switching from WiFi to cellular, apps backgrounding. Your code needs connection recovery with automatic reconnection, re-authentication, and syncing whatever arrived while disconnected. Connection health becomes its own job, with heartbeats, timeouts, and exponential backoff on reconnection.

### Cross-channel state sync

Cross-channel state sync sounds simple until you build it. You send a notification over inbox and email at the same time. The user sees the email first, opens it, reads it. Then they open your mobile app, and the inbox notification is already marked as read, because the system knows they handled it over email.

The same has to work for SMS and push. A user taps a link in an SMS, the inbox message updates. They dismiss a push, the inbox archives. The goal is making the whole thing feel like one coherent system instead of separate channels sending similar messages. Courier does this automatically: when a notification goes out over [multiple channels](https://www.courier.com/solutions/mobile-channel), the backend tracks interaction events from all of them, flows them into a central state store, and propagates any change everywhere.

### Multi-device sync

Users switch between your web app, iOS app, and Android app throughout the day, and the in-app inbox needs to stay in sync across all of them without anyone thinking about it. Read something on your phone during your commute, and it's marked read on your laptop when you get to the office.

The hard part is keeping a single source of truth while devices aren't always connected, clocks aren't perfectly synced, and a user might act on two devices in quick succession. That takes conflict resolution, offline queuing for actions taken while disconnected, and an efficient sync protocol.

### Preferences

[Preference management](https://www.courier.com/platform/preferences-management) is essential, and plenty of systems get it wrong. Users need control over what they receive and how:

- Choose the notification types they care about (mentions yes, routine updates no)
- Pick channels per type (approvals over inbox and email, updates over inbox only)
- Set global rules ("nothing after 8pm")
- Manage subscription topics (billing yes, marketing no)

![Preference management interface with per-type and per-channel controls](//images.ctfassets.net/z7iqk1q8njt4/34fUnrJe38TYtArT9XRd6U/97fa7f9ef26ab6180b3ff06099adc1ef/Frame_163911__3_.png?w=600)

Courier's [preference center](https://www.courier.com/docs/platform/preferences/hosted-page) is hosted, so you don't build and maintain the preference UI yourself. The backend enforces these preferences automatically when it routes a notification, and it handles GDPR and CCPA requirements.

## Adding it to your app

The pattern is the same everywhere: install the SDK, sign in with a user ID and a backend-generated JWT, and render the component. What changes between a web app and a mobile app is the constraints around that pattern.

### Web app

In a web app the notification center renders in the browser, as a dropdown from the bell or a full page, styled with your theme or CSS. Real-time delivery runs over a WebSocket (WSS) that the tab holds while it's open, and the SDK reconnects when the tab wakes or regains focus. There's no OS push registration for the in-app inbox itself; browser push, for when the tab is closed, is a separate opt-in.

#### React

React is the fastest path. Install the package:

```bash
npm install @trycourier/courier-react
```

Add the [inbox component](https://www.courier.com/docs/sdk-libraries/courier-react-web):

```jsx
import { CourierInbox, useCourier } from "@trycourier/courier-react";
import { useEffect } from "react";

export default function NotificationCenter() {
  const courier = useCourier();

  useEffect(() => {
    // Generate the JWT on your backend, never in client-side code
    courier.shared.signIn({
      userId: "user_123",
      jwt: "your_jwt_token",
    });
  }, []);

  return (
    <div>
      <h1>Notifications</h1>
      <CourierInbox />
    </div>
  );
}
```

Sign in once, whether you're using the inbox, toasts, or other SDK attributes. The [SDK](https://www.courier.com/docs/sdk-libraries/sdks-overview) handles state, real-time sync, and backend communication.

#### Vanilla JavaScript

Not on React? The web components SDK works with any framework, or none:

```bash
npm install @trycourier/courier-ui-inbox
```

```html
<body>
  <courier-inbox></courier-inbox>

  <script type="module">
    import { Courier } from "@trycourier/courier-js";

    // JWT generated on your backend
    Courier.shared.signIn({
      userId: "user_123",
      jwt: "your_jwt_token",
    });
  </script>
</body>
```

### Mobile app

In a [mobile app](https://www.courier.com/solutions/mobile-channel) the inbox renders as a native view, with native scrolling, theming, and performance, not a web view. Two constraints shape the setup. First, the OS suspends backgrounded apps, so the SDK manages the connection lifecycle: reconnecting on foreground, restoring state, and refreshing the feed. Second, to alert users when the app is closed you register for push through APNs on iOS or FCM on Android, and the in-app inbox and push share read state. Minimum versions are iOS 15+ and Android 5.0+.

#### iOS

Add the package over Swift Package Manager:

```swift
dependencies: [
  .package(
    url: "https://github.com/trycourier/courier-ios",
    from: "5.0.0"
  )
]
```

Then authenticate and display:

```swift
import Courier_iOS

// JWT generated on your backend
Courier.shared.signIn(
  userId: "user_123",
  jwt: "your_jwt_token"
)

// SwiftUI
struct ContentView: View {
  var body: some View {
    VStack {
      Text("Notifications")
      CourierInboxView()
    }
  }
}
```

Recent iOS releases added long-press gestures with haptic feedback, pull-to-refresh on an empty inbox, and steadier WebSocket handling across background and foreground transitions.

#### Android

Add the SDK to your Gradle dependencies, pinning a version rather than tracking `latest`:

```gradle
repositories {
  google()
  mavenCentral()
  maven { url 'https://www.jitpack.io' }
}

dependencies {
  implementation 'com.github.trycourier:courier-android:5.0.0'
}
```

Then authenticate and render the inbox. `CourierInbox` is a Compose component, so host it from a `ComponentActivity` with `setContent`:

```kotlin
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import com.courier.android.Courier

class MainActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    // JWT generated on your backend
    Courier.shared.signIn(
      userId = "user_123",
      jwt = "your_jwt_token"
    )

    setContent {
      CourierInbox()
    }
  }
}
```

#### React Native

One codebase for both an iOS app and an Android app. Install the package and native dependencies:

```bash
npm install @trycourier/courier-react-native
cd ios && pod install
```

Then use it in your components:

```jsx
import { Courier, CourierInbox } from "@trycourier/courier-react-native";
import { useEffect } from "react";

export default function NotificationScreen() {
  useEffect(() => {
    // JWT generated on your backend
    Courier.shared.signIn({
      userId: "user_123",
      jwt: "your_jwt_token",
    });
  }, []);

  return <CourierInbox />;
}
```

## Sending notifications

A rendered inbox is empty until you [send notifications](https://www.courier.com/docs/platform/inbox/sending-a-message) to it. The simplest is an [API call](https://www.courier.com/docs/platform/sending/sending-overview) with a recipient, content, and routing:

```javascript
const { requestId } = await courier.send({
  message: {
    to: { user_id: "user_123" },
    content: {
      title: "New comment",
      body: "Sarah commented on your post",
    },
    routing: {
      method: "all",
      channels: ["inbox"],
    },
  },
});
```

### Multi-channel delivery

Multi-channel delivery replaces separate per-channel code with one API call that targets all of them:

```javascript
const { requestId } = await courier.send({
  message: {
    to: {
      user_id: "user_123",
      email: "user@example.com",
      phone_number: "+1234567890",
    },
    content: {
      title: "Order shipped",
      body: "Your order #12345 has shipped and arrives tomorrow",
    },
    routing: {
      method: "all",
      channels: ["inbox", "email", "push", "sms"],
    },
  },
});
```

The same [content](https://www.courier.com/docs/platform/content/content-overview) adapts to each channel automatically. The inbox gets rich text and action buttons. Email renders as HTML. Push condenses to a lock-screen format. SMS becomes plain text with shortened links.

The [routing engine](https://www.courier.com/docs/tutorials/sending/how-to-configure-multi-channel-routing) controls how channels interact. Send to everything at once with `all`, or try channels in sequence with fallbacks using `single`:

```javascript
routing: {
  method: "single",
  channels: ["push", "sms", "email"]
}
```

That tries push first, then SMS, then email.

### Using templates

![Courier template designer showing push and email notification templates](//images.ctfassets.net/z7iqk1q8njt4/cf54sv0nVi3CY4ZN5x4Xx/63316982d587e7244f8258051c968eac/designer.png?w=600)

When you're sending the same type of notification over and over, templates beat hardcoding content:

```javascript
const { requestId } = await courier.send({
  message: {
    to: { user_id: "user_123" },
    template: "comment-notification",
    data: {
      commenter: "Sarah",
      post_title: "Q4 Planning",
      comment_preview: "Great insights on the roadmap...",
    },
  },
});
```

Templates live in [Courier's designer](https://www.courier.com/docs/platform/content/template-designer/template-designer-overview), where non-technical teammates can edit content without touching code, and they adapt across channels automatically.

## Customization

Theming works through configuration objects where you set colors, fonts, border radius, and spacing. The inbox component applies them throughout.

![A Twilio-branded inbox showing the notification center themed to match a product](//images.ctfassets.net/z7iqk1q8njt4/7fFZOYlh6eA1GU2VZgFJUJ/41991ee58c80448fa4b675ac02ee5666/Frame_163968__2_.png?w=600)

Courier also gives you brand settings in the dashboard, so you configure your design system once and apply it across every notification. Dark mode is built in.

The built-in views cover unread, all, and archived. For anything more specific, you can build custom filtered views by tag, category, date, or any other metadata.

![Custom action buttons on a notification, deep-linking to specific screens](//images.ctfassets.net/z7iqk1q8njt4/7CkdG0vqcWOUXKZHoXunC1/6740bb571ffe7a7f757ebb0f213cdbe0/Frame_163976.png?w=600)

Action buttons turn notifications into interactive workflows. An approval notification gets approve and reject; a meeting invite gets accept and decline. Those actions can deep-link to a screen or trigger a custom handler.

[Digest notifications](https://www.courier.com/docs/platform/automations/digest) help manage volume. Instead of 15 separate notifications about thread comments, you send one that says "15 new comments on Q4 Planning." Courier groups similar notifications by time window, combines them, and sends at a sensible time.

## Frequently asked questions

### How long does it take to add a notification center with Courier?

The pre-built `CourierInbox` component can be running in an existing app in a few hours. The React, iOS, Android, Flutter, and React Native SDKs all follow the same pattern: install the package, call `signIn` with a user ID and a backend-generated JWT, and render the component. Theming and your first API send usually add another day. The work that takes weeks from scratch, WebSocket infrastructure, state management, and cross-device sync, is handled by the SDK.

### How does JWT authentication work for the notification center?

Each user session needs a signed JWT generated on your backend with your Courier API key. The JWT holds the user ID and an expiration, and your app passes it to `Courier.shared.signIn()` on the client. Courier validates the token before opening the WebSocket connection. When it expires, you generate a new one on your backend and call `signIn` again. The [authentication docs](https://www.courier.com/docs/platform/inbox/authentication) cover token generation for Node, Python, Go, Ruby, Java, C#, and PHP.

### What happens to notifications sent while a user is offline?

They're persisted and delivered when the connection comes back. The inbox loads unread notifications on reconnection, so users see everything they missed with no extra code. State (read, unread, archived) stays consistent because it's managed server-side, not in local storage.

### Can I use the notification center alongside push notifications?

Yes. Courier's [cross-channel integration](https://www.courier.com/docs/platform/inbox/inbox-overview) means the inbox and push share state. Open a push, and the matching inbox notification is marked read. Read a message in the inbox, and the push badge count updates. It works across iOS, Android, and web push from one API call that targets every channel at once.

![A mobile push notification sharing read state with the in-app inbox](//images.ctfassets.net/z7iqk1q8njt4/2brAQ0jr6eRZndtHMDywYN/35959bb48d63f146fa85b19bf1e730db/push_notification.png?w=600)

### How do I customize the appearance of the notification center?

The `CourierInbox` component takes a `theme` configuration object where you set colors, fonts, border radius, and spacing, and the dashboard brand settings apply your design system globally. Dark mode is built in. When the config options aren't enough, the SDKs support custom component rendering, so you can replace any part of the UI with your own while keeping the underlying state management and delivery.


Add an in-app notification center to your web or mobile app. Covers architecture, React, iOS, and Android code, real-time delivery, and multi-channel routing.

Add a Notification Center: Web and Mobile Setup

How to add an in-app notification center to a web app or mobile app: the three-layer architecture, then working React, iOS, Android, and React Native setup with the constraints of each.

How to Add a Notification Center to Your App

*Last updated: July 2026*

## Key takeaways

- Users scan notifications, they don't read them. Front-load the who, what, and why so a notification makes sense in about two seconds.
- Match the format to the urgency: inbox for things worth keeping, toast for confirmations, badge for glanceable counts, push for genuinely urgent alerts.
- Batching is the highest-impact fix for notification fatigue. One "10 new comments" beats 10 separate notifications with identical information value.
- Give users real control: per-type and per-channel preferences, quiet hours, and an easy opt-out that isn't "delete your account."
- Notification content can be sensitive. Secure the connection (WSS), authenticate every request, isolate user data server-side, and plan for GDPR, CCPA, and HIPAA.
- Web and mobile apps enforce these under different limits. On web, watch tab focus and ask for browser-push permission in context. On mobile, respect the OS push-permission prompt, Do Not Disturb, and battery, and deep-link into the right screen.

## Designing effective notifications

Users don't read notifications carefully. They scan them, usually while doing something else, and make a split-second call about whether something matters. Front-loading the important information and cutting the rest makes that scan easier.

![Inbox design options showing clear, scannable notification content](//images.ctfassets.net/z7iqk1q8njt4/6KUegyhiEwvjkSHYI9os0w/26bdbd9ee9ccc14803bf78942ed7e460/Frame_163978__1_.png?w=600)

A good notification tells you who, what, and why in about two seconds. "Sarah approved your design" says Sarah is the actor, approval is the action, and your design is the subject. "Homepage mockups for Project Alpha are ready for development" adds the context that helps you understand what to do next. "View design" gives you the obvious action.

Compare that to "Update" as a title and "There has been a change in the status of one of your items" as the body. You learned nothing except that you have to click through to find out what happened, and that's the kind of notification that trains users to ignore your system.

### Be specific

Instead of "payment processed," say "Visa ending in 4242 charged $49.99." Instead of "new comment," say "Sarah commented on Q4 Planning." Instead of "action required," say "review contract for new client Acme Corp." You already have this data, you're only choosing whether to include it.

| Do | Instead of |
|---|---|
| "Sarah approved your design" | "Update" |
| "Visa ending in 4242 charged $49.99" | "Payment processed" |
| "10 new comments on Q4 Roadmap" | 10 separate "New comment" notifications |
| Schedule digests for business hours in the recipient's time zone | Sending at 3am local time |
| Per-category opt-out controls | All-or-nothing notification settings |

### Match the format to the urgency

The format should match the urgency and the action required. Treating every notification the same is how a system gets ignored.

**Inbox messages** work best for updates users might want to reference later: non-urgent activity, status changes with lasting value, and anything worth keeping as a record. They're persistent and browsable.

**[Toast notifications](https://www.courier.com/blog/what-is-a-toast-message)** are for success or failure confirmations right after an action, time-sensitive alerts that need attention now, and brief information that loses relevance quickly. They disappear on their own, which signals the information is ephemeral.

**Badges** are for glanceable information that doesn't interrupt. The number on the bell tells users something is waiting without forcing them to deal with it.

**Push notifications** are the most interruptive, so use them sparingly: critical alerts when users are outside your app, true emergencies, and carefully considered re-engagement.

Use the loudest format for everything and users learn your notifications are always crying wolf. Match format to urgency, and they'll trust that when you do send something urgent, it's actually urgent.

## User experience principles

Every notification competes with everything else in a user's life: work, family, friends, other apps, the physical world. Attention is scarce. Ask yourself, "would I want to be interrupted for this?" If the answer is no, don't send it.

![Batching similar notifications into a single digest](//images.ctfassets.net/z7iqk1q8njt4/kAcVYncdqFjAftnSgJ7pJ/ddf5eddbc846c255d5f6a09bb62c5253/Frame_163980__1_.png?w=600)

If someone is getting notifications every few minutes, something is wrong with your logic. Either you're notifying about things that don't matter, you're not batching similar updates, or you're not respecting preferences. Users who feel bombarded turn everything off.

### Batching

If someone gets 10 comments on a thread in an hour, send one notification that says "10 new comments" instead of 10 separate ones. The information value is identical and the interruption cost is a tenth.

[Courier's digests](https://www.courier.com/docs/platform/automations/digest) handle this through workflow configuration. You define what counts as similar, set a time window for grouping, choose a template for the combined notification, and specify when batches go out. The system can also skip the digest if the user has already seen the updates.

### User control

Users need real control over their [notification experience](https://www.courier.com/platform/preferences-management). At a minimum:

- Clear preferences for each notification type
- Channel selection per notification category
- An easy way to opt out without deleting their account
- Respect for quiet hours and do-not-disturb settings

Courier's [preference management](https://www.courier.com/docs/platform/preferences/hosted-page) handles this through a hosted preference center. Users set preferences at different levels of granularity, and the Courier API enforces them automatically.

### Timing

Good timing takes context. A "complete your profile" prompt while someone is racing to finish a time-sensitive task isn't helpful; the same prompt next time they log in is.

Use [workflows](https://www.courier.com/platform/workflow-automations) to add delays and conditional logic that respect user state. Send onboarding prompts after a successful first action, not in the middle of one. Schedule digests for when users typically check in. Respect time zones so you're not waking someone at 3am.

### Keeping the inbox manageable

An inbox with 500 unread notifications is useless. Help users manage volume:

- Auto-archive read notifications after a reasonable period, like 30 days
- Set expiration dates on time-sensitive notifications
- Provide "mark all as read" for when someone falls behind
- Make archiving and deletion trivially easy

## Web and mobile apps: different constraints

These practices hold everywhere, but a web app and a mobile app enforce them under different limits.

### Web apps

- Users often have the tab open, so a real-time toast lands while they're looking. A toast in a background tab is missed, so keep anything critical in the inbox where it persists.
- There's no OS notification budget, but browser push, for when the tab is closed, needs explicit permission. Ask in context, after the user has seen why it's useful, not on first load.
- You have room to work with: a full-page inbox and a bell dropdown both fit. Match the surface to how often users check.

### Mobile apps

- The OS restricts background execution, so you can't rely on an open connection to reach a user who left the app. Use push through APNs or FCM to bring them back, and let the in-app inbox sync on foreground.
- Push permission is a one-time, high-stakes prompt, especially on iOS. Ask after the user hits a moment where notifications clearly help, not at launch, or you get a no you can't undo.
- Respect OS-level Do Not Disturb and Focus modes and the user's system notification settings. Fighting them gets your app muted or uninstalled.
- Watch battery and data. Aggressive reconnection or polling drains both; the SDK's managed connection handles this, but a custom build has to.
- Deep-link every notification to the exact screen it's about, not just the app. On a small screen, a short title that leads with the action matters even more than on web.

## Common pitfalls

### Over-notification

The usual pattern is notifying for every minor event regardless of importance, not batching similar updates, and treating everything as equally urgent.

The fix takes an honest look at what actually deserves a notification. Does a user need to know immediately that someone liked their post from three weeks ago? Probably not. Do they need to know their payment failed and their account downgrades tomorrow? Definitely. Map your notification types, assign realistic urgency levels, add [rate limiting](https://www.courier.com/docs/platform/automations/throttle), and use [batching](https://www.courier.com/docs/platform/automations/batching) for anything non-urgent.

### Poor message quality

Generic titles like "Update" or "Document shared" don't give users enough to decide whether something needs attention. "Sarah shared Q4 Budget with you" does. Write [content guidelines](https://www.courier.com/docs/platform/content/content-overview) that spell out the required information for each notification type, review templates regularly, and test every link and action before you ship.

### Technical failures

Technical issues create visible problems:

- **Poor offline handling.** Users miss notifications during connectivity drops, or see duplicates on reconnect.
- **Missing error states.** Blank screens or infinite spinners.
- **Weak WebSocket management.** Real-time delivery fails, or excessive reconnection drains battery.
- **No cross-device sync.** Users see unread notifications on their phone that they already cleared on their laptop.
- **Performance problems.** The inbox takes seconds to load or scrolls with jank.

Fix these by testing offline scenarios explicitly, handling every error case, monitoring WebSocket health, verifying cross-device sync on real devices, and using pagination plus virtual scrolling for large message counts.

### No personalization

Sending identical notifications to every user means power users get overwhelmed while casual users miss what matters. Segment on behavior, preferences, or role and tailor accordingly. Use templates with dynamic data so content adapts to context, pick [SDKs](https://www.courier.com/docs/sdk-libraries/sdks-overview) that support theming, and test with different user personas.

## Performance and scalability

### Frontend performance

The in-app inbox needs to stay fast on both web and mobile apps, even when a user has thousands of notifications. Pagination avoids loading everything at once by fetching in reasonable chunks. Virtual scrolling only renders the notifications actually visible, so memory stays constant regardless of count. Lazy-loading images prevents slow initial loads. Optimistic updates make the interface feel instant: a user marks something read, the UI updates immediately, and the request goes out in the background.

With [Courier's SDKs](https://www.courier.com/docs/sdk-libraries/sdks-overview) most of this is handled for you. The inbox component implements pagination and virtual scrolling, the WebSocket library manages connections with heartbeats, and state management uses optimistic updates by default.

### Backend efficiency

Batch API calls when you can. Cache user preferences instead of hitting the database for every notification. Rate-limit per user to prevent runaway loops. Use message queues to buffer spikes. [Courier's infrastructure](https://www.courier.com/platform/workflow-automations) handles this with automatic scaling, built-in queuing, and monitoring.

### Real-time at scale

WebSocket connections are stateful and long-lived, so they consume server resources the entire time a user is connected. At 100,000 concurrent users you need real infrastructure: connection pooling, automatic reconnection, offline queuing, heartbeats, and graceful degradation to polling when WebSockets are blocked. Courier's [WebSocket infrastructure](https://www.courier.com/blog/checklist-for-building-a-better-notification-center) is built for this, so notifications feel instant without burning resources or draining battery.

## Security and privacy

### Data protection

Notification content can be extremely sensitive: a healthcare app sending test results, a fintech app showing an account balance, a messaging app previewing a message. That data needs the same protection as the rest of your app.

Secure WebSocket connections over WSS are mandatory, not optional. [JWT authentication](https://www.courier.com/docs/platform/inbox/authentication) verifies identity before any notification is delivered. Token expiration keeps old tokens from working forever. Audit logging tracks who accessed what and when.

![JWT authentication flow between client, your backend, and Courier](//images.ctfassets.net/z7iqk1q8njt4/27VvnUFXMc1CawB9GYR1Xk/c3830f08aab397d31556fa4c4bd97774/courier-jwt-auth-flow.png?w=600)

Courier handles authentication and connection security for you. You provide user IDs and signed JWTs, Courier verifies them on the backend, and notifications only flow to authenticated, authorized users.

### User data isolation

Users should only ever see their own notifications. Server-side authorization has to verify every request, because you can't trust client-side filtering: a malicious user can modify their client code to request other users' data. User-scoped queries filter by user ID at the database level, and in B2B apps, tenant isolation enforces workspace boundaries. [Courier's architecture](https://www.courier.com/docs/help) enforces this automatically: the client requests notifications with an authenticated JWT, and the backend verifies the token, extracts the user ID, and returns only that user's notifications.

### Compliance

GDPR requires that users can access their notification data, delete their history on request, export their data in a portable format, give clear consent, and understand what you collect. CCPA requires disclosure of data collection, opt-out rights, and deletion on request. That means APIs for data export, deletion workflows that actually remove notification data, [preference management](https://www.courier.com/platform/preferences-management) with clear opt-out controls, and audit logs.

Healthcare apps face a stricter bar under HIPAA: notification content must not include protected health information in email or SMS. [Trusted Health](https://www.courier.com/solutions/healthcare), which coordinates time-sensitive nursing notifications with 3,000+ healthcare facilities, routes anything carrying PHI through authenticated in-app channels, so email and SMS carry no protected data. Courier's [preference center](https://www.courier.com/docs/platform/preferences/hosted-page) provides the opt-out controls, and the API supports data export and deletion.

## Frequently asked questions

### How many notifications is too many?

There's no universal number, but rising unsubscribe rates and users disabling categories are reliable signals that you've crossed the line. Track opt-out rates per notification type. If one category drives most of the unsubscribes, cut its frequency or make it opt-in rather than changing everything at once. [Rate limiting](https://www.courier.com/docs/platform/automations/throttle) in Courier caps notifications per user per time window without touching your application logic.

### What should a notification title include?

A title should name the actor (who), the action (what), and the object (what specifically). "Sarah commented on Q4 Roadmap" is complete; "New comment" is not. Users decide whether to read or ignore in seconds, so give them enough to decide without clicking through. When there's a monetary amount, a deadline, or an identity involved, put it in the title. The body is for context and actions.

### How do you handle notifications when a user is offline?

Store notifications in a persistent inbox that loads when the user returns, and queue push notifications for delivery when the device reconnects. For time-sensitive alerts, [workflows](https://www.courier.com/platform/workflow-automations) let you configure retry windows and fallback channels. An alert that expires in four hours shouldn't arrive six hours late, so set expiration times and suppress stale alerts rather than delivering them after they've lost relevance.

### When should you use a digest instead of individual notifications?

Use a digest when several events share a topic and none of them individually needs immediate action. Comment threads, activity summaries, and daily reports work well batched. Time-sensitive alerts like payment failures, security events, and deployment failures should send individually regardless of volume. [Courier digests](https://www.courier.com/docs/platform/automations/digest) let you define the window and the merge criteria so the batching logic lives in workflow configuration, not your application code.

### How do you keep the notification inbox from becoming overwhelming?

Set automatic archive times for read notifications: 30 to 90 days is common, depending on how long your users reference old alerts. Add expiration dates to time-sensitive items so they don't linger. Make bulk-read and archive actions easy to reach from the main inbox. Users abandon notification systems that become unmanageable, so a navigable inbox matters as much as reliable delivery.

---
---


Design in-app notifications users actually read. Covers content design, batching, preference management, performance, and security for web and mobile apps.

Notification Center Best Practices and UX

How to design notifications users actually read: content, format, batching, preferences, performance, security, and the different constraints on web and mobile apps.

Notification Center Best Practices

*Last updated: July 2026*

## Key takeaways

- The bell, badge, and feed are a weekend of work. The real-time backend behind them is a quarter, plus maintenance forever.
- Build only in a narrow case: notifications are your core product, your UX is too custom for any component, or data-residency rules force you to own the stack.
- A drop-in component gets you the same result in an afternoon and hands the reliability problem to a vendor.
- Courier adds cross-channel orchestration on top of the inbox: one send reaches in-app, email, push, SMS, and chat, with shared preferences and failover.
- Novu, MagicBell, Liveblocks, and OneSignal each fit a narrower slice: open-source and self-hosted, a standalone inbox, React real-time, or push at scale.

## What building it actually costs

The visible part, a bell, a badge, and a scrollable feed, is a weekend of work. Everything behind it is the quarter:

- **A real-time backend.** A WebSocket service that streams new notifications and state changes to every open client, with reconnection, presence, and the toast that surfaces a notification the moment it arrives.
- **State you can trust.** Per-user, per-notification read, unread, and archived state, plus an accurate unread count, kept consistent across a laptop and a phone at the same time.
- **Storage and pagination.** A datastore that holds each user's history and serves it fast when the feed is thousands of items deep.
- **Preferences.** Per-category and per-channel opt-in and opt-out, enforced everywhere a notification could go.
- **The operational tail.** Scaling the socket layer, uptime, on-call, upgrades, and security patching, forever.

That's before you staff it. A production build needs frontend engineers for your web app, iOS app, and Android app, backend engineers for the API and WebSocket server, DevOps for scaling and on-call, and QA across platforms. For a team of five to ten, notifications become the main project for two to three quarters.

The cost that matters most is opportunity cost. Your team can build this. The question is what they don't ship while they do: the features that slip, the core-product work that waits.

[Twilio](https://www.courier.com/use-cases/twilio) made this call themselves. Rather than expand their deprecated Notify API, they chose Courier for their own internal notification orchestration. When a communications-infrastructure company buys instead of building on its own APIs, the complexity is real.

## When building makes sense

Building is the right call in a narrow set of cases: notifications are your core product and the differentiation is worth owning, your UX is too custom for any prebuilt component, or data-residency rules require you to keep the whole stack in-house. Outside those, a component that ships today beats a build that pays off in a year.

## Courier: an inbox plus orchestration

Most tools answer one question: how do I render an in-app feed? Courier answers the harder one: what happens to a notification when the user isn't in your app right now.

- **One send, every channel.** The same notification lands in the inbox and can send a push, then fall back to email or SMS based on user preferences, from one [API call](https://www.courier.com/docs/platform/sending/sending-overview).
- **Consistent on web and native mobile.** Native SDKs for React, JavaScript and web components, iOS, Android, React Native, and Flutter, so the inbox is a real native view on a mobile app, not a web view.
- **Preferences and failover built in.** 50+ provider integrations with automatic failover, and hosted [preferences](https://www.courier.com/platform/preferences-management) that apply across every channel, not only the feed.
- **Production reliability.** A 99.95% uptime SLA, message queuing, automatic retries, and 24/7 monitoring, so you inherit the operational tail instead of staffing it.
- **Per-notification pricing.** One notification that fans out to several channels is one charge, with a free tier of 10,000 a month.
- **Cross-channel state sync.** Read it in email and the inbox marks read; dismiss the push and the inbox archives. Courier keeps one canonical state per notification and propagates it everywhere, no extra code. Chapter 2 covers the mechanics.

![Visual workflow builder for multi-channel notification logic](//images.ctfassets.net/z7iqk1q8njt4/24mnnvUpIPK5fL6PyuRPwo/df0ac14e788b76de57f6147dba789a30/Frame_163981.png?w=600)

Setup takes under an hour: install the SDK, sign in with a user ID and JWT, render the component. No WebSocket server, no schema, no state-management library.

## How Courier compares

Courier is used by teams like Twilio, LaunchDarkly, and CircleCI.

| Platform | Strongest for | Watch out for |
|---|---|---|
| **Courier** | Drop-in inbox plus cross-channel orchestration, widest native SDK coverage | Focused on transactional and product notifications, not marketing automation |
| **Novu** | Open-source and self-hosted setups | Self-hosting means you own scaling, uptime, and upgrades |
| **MagicBell** | A dedicated, polished standalone inbox | Web-first, with no native mobile SDK and no SMS channel |
| **Liveblocks** | Real-time React apps using collaboration features | React only, with no native mobile component |
| **OneSignal** | Push at scale | Transient in-app messages, with no persistent inbox |

Developer-first tools (Courier, Novu, MagicBell, Liveblocks) win on drop-in UI and developer experience. OneSignal and the other engagement platforms put the inbox, or transient in-app messages, inside a broader campaign platform. The pick comes down to whether your bottleneck is shipping a feed or running cross-channel programs. For the full field, see our comparison of the [best in-app notification centers](https://www.courier.com/blog/best-in-app-notification-centers).

## Customer proof

[DroneDeploy](https://www.courier.com/customers) makes drone mapping software for construction and surveying. Map files take real time to process, so users needed a notification when a job finished rather than a progress bar to watch. A from-scratch build would have taken months. They integrated Courier in weeks.

![DroneDeploy and Courier](//images.ctfassets.net/z7iqk1q8njt4/11UJ3tg8JnB8NWGOlHAm8W/b3a180ff2124127c301a34a903deb7ef/655beeb0d8674f4cbe11360d_dronedeploy.jpg?w=600)

> "We used the great looking pre-built component to save even more time. Notifications are not our core competency, so it made complete sense to integrate rather than build out and support our own implementation."
>
> **James Pipe, VP of Product, DroneDeploy**

[LaunchDarkly](https://www.courier.com/use-cases/launchdarkly) runs a feature management platform and uses Courier Inbox for flag-approval workflows. A request reaches the reviewer with approve and reject buttons in the row, and the inbox keeps the audit trail.

![LaunchDarkly and Courier](//images.ctfassets.net/z7iqk1q8njt4/6jzhSLeq2EI7R2kpkHrxRS/86fc038d7f25c82924d36252e4936064/launchdarkly.png?w=600)

> "We were able to build the in-app notification experience that we wanted with excellent support and communication from the Courier staff."
>
> **Lucy Wonsower, Software Engineer, LaunchDarkly**

## Getting started

The full setup is in chapter 2. The short version: sign up at [app.courier.com](https://app.courier.com/signup), grab your client key and auth token, install the SDK for your platform, sign in with a user ID and JWT, and render the inbox component. Send yourself a notification from the dashboard to confirm real-time delivery, then move your notification logic into [workflows](https://www.courier.com/platform/workflow-automations) as it grows.

The [free tier](https://www.courier.com/pricing) includes 10,000 notifications a month with full feature access, enough to build, validate, and launch most apps. Start there and upgrade when volume grows.

## Frequently asked questions

### How much does it cost to build a notification center in-house?

Production-quality notification infrastructure typically takes three to six months for basic functionality and another six months to handle edge cases, so six to twelve months of engineering before you have something reliable, not counting ongoing maintenance. The recurring costs are the ones teams miss: WebSocket server infrastructure, cross-device sync, multi-platform SDK maintenance, and an on-call rotation. Courier's free tier covers 10,000 notifications a month with no engineering overhead, and [paid plans](https://www.courier.com/pricing) scale with volume.

### How long does it take to integrate Courier?

Most teams have a working notification center in one to three days. The [SDK](https://www.courier.com/docs/sdk-libraries/sdks-overview) installs like any other package, authentication is a few lines, and the inbox component renders with sensible defaults. Getting from zero to a branded, functional in-app notification center usually takes under a week including customization and testing.

### What is the difference between Courier and OneSignal?

OneSignal specializes in push notifications, with strong delivery optimization and detailed push analytics. Courier is built for multi-channel product notifications: in-app inbox, email, SMS, push, Slack, and Teams from one API. If push is your only channel, OneSignal is worth evaluating. If you need a notification center alongside other channels with cross-channel state sync, Courier handles the full stack, and its in-app notification center is more customizable than OneSignal's.

### Does Courier support both web and mobile notification centers?

Yes. Courier provides SDKs for React and web components on the web, a native iOS SDK, a native Android SDK, Flutter, and React Native. They share the same API design, so the same backend code sends to every platform, and cross-device sync means a notification read in your web app also shows as read in your iOS or Android app.

### What happens when you exceed Courier's free tier?

The free tier includes 10,000 notifications a month with full feature access: inbox, push, email, SMS, workflows, analytics, and every channel. Past 10,000 you move to a paid plan with no loss of functionality; pricing scales with volume. [Courier's pricing page](https://www.courier.com/pricing) has current rates.

---
---


Should you build or buy a notification center? Compare the real timelines and costs, plus platforms like Courier, Novu, MagicBell, Liveblocks, and OneSignal.

Build vs Buy a Notification Center

An honest look at building a notification center versus buying one: what building really costs, when it's worth it, and how Courier compares to Novu, MagicBell, Liveblocks, and OneSignal.

*Last updated: July 2026*

## Key takeaways

- The implementation pattern is the same across industries. What changes is what you send and when.
- In B2B SaaS, the highest-value use case is approvals: a decision that needs to reach the right person fast, with action buttons and an audit trail.
- For DevOps, the win is signal over noise. Group a single incident's events into one thread instead of scattering them across the inbox.
- In healthcare, in-app notifications carry clinical context that email and SMS can't, because they stay inside an authenticated session.
- In marketplaces, one event fans out to buyer, seller, and operations, each seeing only what's relevant to them.

## How product teams use notification centers

An in-app notification center is the communication layer between your product and its users. The pattern is similar across industries: a persistent inbox, real-time delivery, action buttons, and preference management. What changes is what you send, and when.

## SaaS approval workflows

Approval workflows are one of the most common notification center use cases in B2B SaaS. Something needs a human decision before it proceeds, and that decision has to reach the right person quickly.

### Feature flag approvals

[LaunchDarkly](https://launchdarkly.com/) manages approvals for feature-flag changes through Courier Inbox. When an engineer requests permission to modify a production flag, the notification lands in the reviewer's inbox with context about the flag, the proposed change, and two action buttons, approve and reject. Reviewers act without leaving the app, and the inbox keeps a history of every request, pending, approved, and rejected, so teams audit decisions without querying a separate system.

### Contract and access review

Legal and procurement workflows follow the same pattern. New contracts route to the right reviewer by value or department, and reviewers see the summary, counterparty, and deadlines right in the notification. Escalation triggers when an approval is delayed past its SLA. Permission requests for sensitive systems like production databases, admin consoles, and security tooling use the same routing: the request shows who's asking, what they need, and why, and reviewers can approve, deny, or ask for more information without navigating elsewhere.

## DevOps and engineering alerts

Engineering teams need a notification center that surfaces actionable information without creating noise. The highest-value notifications are the ones that need action or add context you don't already have.

### Deployment status

[DroneDeploy](https://www.courier.com/customers) uses Courier to alert users when long-running processing jobs finish. Map processing for construction drone footage takes real time, so rather than polling for status, users get a notification when the map is ready. The same pattern fits CI/CD pipelines: each stage emits an event (build started, tests passing, deployment queued, deployment complete, rollback triggered), and each notifies the relevant engineers. The inbox, or a Slack channel, becomes a deployment log you check between other work rather than a terminal you babysit.

![Slack DevOps alert delivered through Courier](//images.ctfassets.net/z7iqk1q8njt4/1vh5p48BAVnASW5x5wR68o/58468e54788a5ec8d6ffa519b5df1d78/slack_dev_alert_2.webp?w=600)

### Infrastructure and incident notifications

Monitoring integrations notify on threshold crossings: CPU above 90%, connection pool exhausted, error rate spiking. Notifications route to on-call engineers and update when the alert clears. A single incident might generate several related notifications, alert triggered, acknowledgment, mitigation deployed, recovery confirmed, and those group into one thread instead of scattering as separate inbox items.

## Healthcare: care coordination

[Healthcare platforms](https://www.courier.com/solutions/healthcare) face a constraint other industries don't. HIPAA requires that email and SMS not contain protected health information, so in-app notifications inside an authenticated session become the place to carry clinical context that other channels can't.

### Staff coordination

[Trusted Health](https://www.courier.com/solutions/healthcare), which connects nursing professionals with 3,000+ healthcare facilities, routes staffing notifications through authenticated channels. Shift availability, assignment confirmations, and schedule changes reach nurses through the app rather than SMS or email, which keeps sensitive employment information inside the secure session.

### Patient-facing and provider workflows

Healthcare apps use in-app notifications for lab-result availability, appointment reminders, and care-plan updates. The notification itself carries no clinical data. It signals that information is available and links to the authenticated view, which keeps the channel compliant while still giving a timely alert. Care coordination platforms notify physicians when a patient's condition changes or test results come back abnormal. Critical notifications require acknowledgment, while routine updates batch into digests.

## Marketplace transaction tracking

Marketplaces coordinate multiple parties for every transaction. Buyers, sellers, and operations each need a different view of the same events.

| Transaction event | Buyer | Seller | Operations |
|---|---|---|---|
| Order placed | Confirmation with details | New order requiring action | (none) |
| Payment processed | Receipt | Payout timeline | (none) |
| Item shipped | Tracking information | Shipment confirmation | (none) |
| Delivered | Delivery confirmation + review prompt | Delivery confirmation | (none) |
| Dispute opened | Case reference + instructions | Case reference + response deadline | Case opened for review |
| SLA approaching | (none) | Warning with deadline | Escalation if unresolved |

Each role sees only the notifications relevant to their work. Sellers handling high volume get digest notifications rather than an individual alert for every update.

## Frequently asked questions

### How should I structure notification categories?

Start with the groupings users already think in: activity (things people did), alerts (things that need attention), and system (platform-level status). Within each, consider whether different roles need different notifications: an approval is relevant to the approver but not the requester once it's submitted. Don't create more categories than users can manage. Most preference centers with more than six types see users disable everything rather than configure it.

### What notification types work best with action buttons?

Notifications with a binary decision or a single obvious next step. Approvals (approve/reject), assignments (accept/decline), invitations (join/decline), and confirmation prompts all work well. Informational notifications like "your report is ready" or "deployment complete" don't need buttons, because the notification is the information. Avoid more than three action buttons, since decision paralysis lowers action rates.

### How do you keep a notification center from being ignored?

The main cause is irrelevance: notifications users didn't need. Audit each type against one test: does the user need to know this now, or can they discover it later? Anything that passes the second condition is a candidate for removal or a digest. The second cause is volume, and [rate limiting](https://www.courier.com/docs/platform/automations/throttle) plus [batching](https://www.courier.com/docs/platform/automations/batching) address that without removing notifications entirely.

### How do you handle notifications across time zones?

Store each user's time zone in their profile and apply it to every time-based delivery decision. That affects scheduling (send digests during business hours), display (show timestamps in local time), and urgency. Courier stores time zone as a [profile attribute](https://www.courier.com/docs/api-reference/user-profiles/get-a-profile) and applies it in workflow delay calculations when configured.

### When should a notification require acknowledgment?

Require acknowledgment when you need to know the recipient is aware: security alerts, required compliance training, and incident acknowledgment in on-call workflows. Informational notifications like feature announcements or activity summaries don't need it. Overusing acknowledgment trains users to dismiss without reading, which defeats the purpose.

---

> **Ready to add an in-app notification center to your app?** [Talk to a solutions expert](https://www.courier.com/request-demo) to walk through your use case, or [get started for free](https://app.courier.com/signup) with 10,000 notifications a month.


Real in-app notification center use cases: SaaS approvals, DevOps alerts, healthcare care coordination, and marketplace tracking on web and mobile apps.

Notification Center Use Cases and Examples

How product teams use in-app notification centers: SaaS approvals, DevOps and incident alerts, healthcare care coordination, and marketplace transaction tracking.

Notification Center Use Cases

How to Build a Notification Center

Learn how to add an in-app notification center to your web or mobile app: architecture, React and mobile code, UX best practices, and the build vs buy call.

Adding an in-app notification center sounds simple: a bell, an unread count, a feed users can scroll. The hard part is behind the bell, real-time sync, read state, preferences, and a UI that works on both web and mobile. This guide covers the whole thing: what an in-app notification center is, how to add one to a web or mobile app with real React, iOS, and Android code, the design and security practices that make it usable, and an honest build-vs-buy call with a platform comparison. It's written for developers who want a working feed without spending a quarter building one.

How to Add a Notification Center to Your App

Highlights

Contents

Products

Solutions

Platform