Guides / Prompting and shipping

How to Add Notifications to Your App: In-App, Email and Push

Add notifications to a web app: in-app bell, email and web push compared, how to store and send them, user preferences, and the mistakes that annoy users.

Mythex Team · 2026-09-29 · 6 min read

To add notifications to a web app, start with in-app notifications: a notifications table in your database and a bell icon that shows unread items. Add email for things people need to know when they're away, using an email provider, and add web push only when timely alerts matter, since it needs a service worker, user permission and, on iPhone, the app saved to the Home Screen. Whatever channels you use, create every notification in one place on the server and let users choose what they receive.

This guide compares the channels, shows a simple architecture, and gives prompts you can use with an AI app builder.

The main channels compared

Most apps need in-app plus email. Push and SMS are worth it when timing really matters, like a booking reminder or an order that's ready.

How a notification system fits together

Keep it simple and central:

1. Something happens. A comment is posted, a payment fails, a booking is tomorrow.
2. Your server calls one function, such as notify(user, type, data).
3. That function checks the user's preferences and writes a row to a notifications table (for the bell).
4. It then sends to other channels the user has turned on for that type: email through your provider, push through the Push API.
5. The frontend shows unread notifications and marks them read when opened.

A single entry point means you can add a channel, change wording, or respect preferences without hunting through the codebase.

What to store

A notifications table usually needs: user ID, type (for example comment_reply), a short title and body, a link to the relevant page, created time, and read time. A separate preferences table stores which channels each user wants for each type.

Showing new notifications

• Load on page view and poll every 30–60 seconds. Simple and reliable.
• Real-time updates with WebSockets or server-sent events feel instant but add moving parts. Start with polling unless instant updates matter.

Email notifications

Email needs a sending provider and a verified domain; the details are in how to send emails from your app. For notifications specifically:

• Send from the server, never with a provider key in the browser.
• Batch chatty events. "3 new comments" in one email beats three emails.
• Offer a daily or weekly digest for low-priority activity.
• Include an unsubscribe or preferences link in non-essential email. Rules on marketing email differ by country; check what applies to you.

Web push notifications

Web push lets your site send alerts that appear like app notifications. Per MDN's Push API documentation, it works like this:

1. Your site registers a service worker, a script the browser can run in the background.
2. After the user agrees, the service worker subscribes through PushManager.subscribe(). The browser returns a subscription with an endpoint and encryption keys.
3. Your server stores that subscription and, when something happens, sends a message to the endpoint, usually signed with VAPID keys (a key pair identifying your server).
4. The browser starts your service worker, which shows the notification, even if your page isn't open.

MDN also notes the endpoint should be kept secret, since knowing it is enough to send messages to that user.

iPhone and iPad

WebKit added Web Push for web apps in iOS and iPadOS 16.4, with two conditions from its announcement: the site must be added to the Home Screen, and permission must be requested in response to a user action such as tapping a Subscribe button. So on iPhone, push only reaches users who've installed your web app. See native vs progressive web apps for what installing a web app means.

Asking for permission well

Don't ask on first visit. Explain the benefit first ("Get a reminder an hour before your class"), then show the browser prompt when the user taps a button. If someone declines, the browser may not let you ask again, so a premature prompt can lose them permanently.

Scheduled notifications need a trigger

"Reminder 24 hours before" or "weekly summary every Monday" need something to run on a schedule. That's a background-job problem, covered in how to run background jobs. A common pattern: an external scheduler calls a protected endpoint every few minutes, and that endpoint sends whatever is due.

Prompts to give your AI builder

Start with in-app:

Add in-app notifications. Create a notifications table (user, type, title, body, link, created_at, read_at). Add a server function notify(userId, type, data) that every feature calls. Show a bell icon in the header with an unread count, a dropdown of the latest 20, and a "mark all as read" button. Poll for new ones every 60 seconds.

Then preferences and email:

Add notification settings: for each type (comment replies, mentions, billing), let the user choose in-app, email, both or none. notify() must respect these. Send email through [PROVIDER] using the secret [ENV_NAME] on the server only. Group comment emails so one user gets at most one email per 15 minutes.

Then push, if you need it:

Add optional web push. Register a service worker, generate VAPID keys and store the private key as a secret. Add an "Enable notifications" button in settings that asks for permission only when clicked. Store each subscription per user and device, send pushes from notify() when the user opted in, and delete subscriptions the push service reports as expired.

Common mistakes

• Notifications scattered through the code. Every feature sends its own email differently, and preferences get ignored. Use one notify() function.
• Asking for push permission on page load. Most people decline, and you may not get another chance.
• No preferences. Users who can't turn off noisy alerts turn off all of them, or leave.
• Sending from the browser. Email and push keys belong on the server.
• Not cleaning up dead push subscriptions. Expired subscriptions pile up and waste sends.
• Sensitive details in the notification text. Lock screens show it. "You have a new message" is safer than the message itself.
• No record of what was sent. When a user says "I never got the email", logs with provider message IDs help you find out why.

Checklist

• One server-side notify() function used everywhere
• Notifications table with read state, and a bell with an unread count
• Per-type channel preferences, respected by notify()
• Email sent from the server with a verified domain; digest or grouping for chatty events
• Push permission asked only after a user action, with an explanation
• Push tested on desktop and on an iPhone with the app added to the Home Screen
• Expired push subscriptions removed
• No sensitive content in push or email previews
• Scheduled reminders have a reliable trigger

Notifications in Mythex

Mythex doesn't include a built-in email or push service for the apps you build, so you bring your own email provider and generate your own push keys, stored as project secrets. The in-app part only needs the project's database, which Mythex adds when you ask for it. Build with prompts like those above, test the bell and emails in Preview, and test push on your published URL, since service workers and push need a real HTTPS address. The docs recipe Send email from your app has a starter prompt. Mythex doesn't document scheduled jobs, so plan timed reminders with an external trigger as described in how to run background jobs.