How to Add Email and SMS Notifications to an App

Notifications work best when a person knows why they received one and what to do next. "Your appointment moved to 2:00 PM" is useful. Five messages about every internal edit are not.

Email and SMS share an event source but behave differently. Email can carry detail and be opened later. SMS is more immediate, constrained, and potentially costly. Build from the event and the recipient's need, then choose a channel.

Start with a notification table

For each event, write the audience, channel, timing, and action. A booking app might use: booking confirmed to customer by email, appointment changed to customer by email and optional SMS, and new booking to staff in the app.

Do not send SMS for every status change just because it is available. Ask whether a timely text helps the person act. Combine related edits when possible and avoid sending messages that are already obsolete by the time a background job runs.

Write the message in plain language with the business name, the relevant fact, and a next step. Avoid putting sensitive details in subject lines or SMS previews.

Here is a starting event map for the booking example in this article. It specifies what the app must save before sending anything:

Create a message job only after the booking change commits. Store the booking ID and the version the message describes. Before a scheduled job sends, compare that version with the current booking. If it is stale, do not send an old time. This is the part that prevents a customer from receiving two contradictory appointment messages.

The table is a template for the booking workflow, not a claim that every app needs these notifications.

Understand device SMS versus automated SMS

A mobile app can open the device's text composer with a recipient and draft message. The person then sends it using their phone. In an Expo app, expo-sms supports this composer workflow; it does not silently send transactional texts from your server.

If your app must send booking reminders or verification texts automatically, use a server-side messaging provider.

Keep API credentials on the server, initiate the send from a trusted event or job, and store provider response identifiers. Do not place provider secret keys in the mobile bundle.

Decide whether replies go to a monitored number. A message that says "reply to reschedule" must have a working reply-handling process.

Model notifications as event-driven jobs

When a booking changes, save the booking change first. Then create a notification job that records event ID, recipient, channel, template version, planned send time, and status. This avoids a push or SMS announcing a change that failed to save.

Use an idempotency key such as event ID plus recipient plus channel. A retry should not text a customer twice for the same reschedule. Before sending a delayed reminder, check whether the appointment is still active and at the expected time.

A practical set of states is Queued, Sending, Sent to provider, Delivered where supported, Failed, and Canceled. "Sent to provider" does not mean the recipient read it.

Build templates with meaningful fallbacks

Keep content templates separate from business logic. A template needs required variables, an example, a character-aware SMS variant, and a fallback when an optional field is missing.

Example SMS: "Huxly Demo Service: Your visit is now Tue, 2:00 PM. View details: [short trusted link]." Avoid generic public links with long-lived access to private records. Have links open an authenticated screen or use a token with appropriate limits.

Preview templates with a long customer name, different time zones, and missing optional address data. Use a localized date format and include the time zone where recipients might be in different regions.

Record consent and preferences

Separate service messages from marketing messages. Record which channels a person has chosen, what consent was collected where required, and how they can change preferences.

Rules differ by country, sender type, and message purpose, so review the requirements for the markets you operate in with appropriate counsel or your provider's compliance guidance.

Give people control over optional alerts. A critical account security notice may have a different handling policy than a promotional offer. Honor opt-outs and suppression lists at send time, not only when a user first signs up.

For international SMS, check whether the provider supports the destination country and required sender registration. Costs and delivery rules can vary.

Handle failures and timing

Email can bounce. SMS can be rejected, delayed, or delivered to a recycled number. Store delivery errors by category and provide staff with a clear "notification failed" state for important workflows. Do not expose raw provider errors to end users.

Retry temporary failures with spacing and a maximum attempt count. Do not retry permanent invalid-address or opt-out errors. If a reminder is scheduled for an appointment that was canceled, cancel the job.

Quiet hours matter for non-urgent notifications. Use the recipient's time zone and a stated timing policy. A reminder scheduled at 9:00 in the server's time zone may arrive at midnight locally.

Protect account and customer data

Verify phone numbers and email addresses where the workflow requires reliable delivery. Reconfirm a changed destination before sending sensitive information. Never include a password, full payment card, or confidential document in a text.

Restrict notification logs to authorized staff. Keep only the content and delivery metadata you actually need. A provider dashboard is another place where message data may be visible; review that access too.

Test a complete event

Create a booking, change its time twice quickly, and cancel it. Confirm that the recipient receives the right final message, that stale reminders are canceled, and that retries do not duplicate sends. Test an opted-out phone number and a bounced email.

Use provider test modes where available, but also run a controlled live test across actual devices and carriers for your launch markets.

Check that links go to the correct signed-in record and do not reveal data to someone with an old phone number.

Build notifications with Huxly

Specify the events, not just the channels: "When a confirmed booking is rescheduled, save the booking first and queue one email to the customer. Send an optional SMS only when they have opted in. Include the new time with its time zone and a secure booking link. Cancel stale reminder jobs, avoid duplicate sends on retries, and show staff a failed-delivery state."

Add one event at a time. Review the real messages on a phone before expanding to every workflow. If you already have push notifications, keep channel preferences and event IDs aligned so one change does not generate redundant alerts.

FAQ

Conclusion

Good notification systems make important changes visible without creating noise. Begin with a small event table, trustworthy delivery states, and clear user preferences; then add channels only where they help.