Setting Up Triggered Notifications: Email, SMS, Telegram

Introduction

Imagine a customer placing an order on your site, paying by card, but not receiving a status update. They start worrying, call support — your business loses money and reputation. How do you build a fault-tolerant notification system that delivers messages via email, SMS, or Telegram regardless of channel failures? We break down the architecture, code, and infrastructure tested on over 50 projects in e-commerce, fintech, and SaaS. We guarantee that no event is lost — our system uses a queue with exponential backoff and monitoring.

In over 5 years, we have never encountered a lost notification due to an architectural mistake. All issues were resolved during the design phase.

Problems We Solve

• Message loss — a channel goes down or the API returns an error (e.g., Twilio returns 500). We use a queue (Bull Queue) with retry and logging. On failure, the message is retried after 2, 4, 8 seconds (exponential backoff). After 3 failures, it goes into a Dead Letter Queue for manual analysis.
• Channel confusion — a user wants Telegram notifications but gets SMS. We implement a personal cabinet with preference settings: channel selection for each event type, quiet hours, and time zone.
• Spam traps — transactional and marketing notifications are separated. Marketing uses separate channels (email) with an unsubscribe option. Quiet hours (22:00–08:00) block sending during off-hours.

// notification.service.ts
interface NotificationRequest {
  userId: string;
  type: NotificationType;
  data: Record<string, unknown>;
  channels?: Channel[];
  priority?: 'high' | 'normal' | 'low';
}

type NotificationType =
  | 'order.placed'
  | 'order.shipped'
  | 'payment.failed'
  | 'password.reset'
  | 'promo.discount';

class NotificationService {
  async send(request: NotificationRequest): Promise<void> {
    const prefs = await this.userPrefsRepo.findByUserId(request.userId);
    const channels = request.channels ?? this.resolveChannels(request.type, prefs);

    await Promise.allSettled(
      channels.map(channel => this.sendViaChannel(channel, request, prefs))
    );
  }

  private resolveChannels(type: NotificationType, prefs: UserPrefs): Channel[] {
    const channelMap: Record<NotificationType, Channel[]> = {
      'order.placed': ['email', 'telegram'],
      'order.shipped': ['email', 'sms', 'telegram'],
      'payment.failed': ['email', 'sms'],
      'password.reset': ['email'],
      'promo.discount': prefs.marketingChannels
    };
    return channelMap[type] ?? ['email'];
  }
}

Email via Resend

For email notifications, we use Resend. Below is a code example:

import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);

async function sendEmailNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  const template = emailTemplates[type];

  await resend.emails.send({
    from: '[email protected]',
    to: user.email,
    subject: template.subject(data),
    react: template.component({ user, ...data })
  });
}

// Template for order.shipped
const orderShippedTemplate = {
  subject: (data) => `Your order #${data.orderId} has shipped`,
  component: ({ user, orderId, trackingNumber, estimatedDelivery }) => (
    <OrderShippedEmail
      name={user.firstName}
      orderId={orderId}
      trackingNumber={trackingNumber}
      trackingUrl={`https://example.com/track/${trackingNumber}`}
      estimatedDelivery={estimatedDelivery}
    />
  )
};

SMS via Twilio

For SMS notifications, we use Twilio. Example:

import twilio from 'twilio';
const client = twilio(process.env.TWILIO_SID, process.env.TWILIO_TOKEN);

async function sendSmsNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  if (!user.phone || !user.phoneVerified) return;

  const templates: Record<NotificationType, (data: Record<string, unknown>) => string> = {
    'order.shipped': (d) =>
      `Order #${d.orderId} shipped. Track: ${d.trackingNumber}. Expected by ${d.date}`,
    'payment.failed': (d) =>
      `Payment for order #${d.orderId} failed. Update your card: ${d.retryUrl}`
  };

  const text = templates[type]?.(data);
  if (!text) return;

  await client.messages.create({
    to: user.phone,
    from: process.env.TWILIO_PHONE,
    body: text
  });
}

Telegram via Bot API

For Telegram notifications, we use a Telegram bot. Example:

import TelegramBot from 'node-telegram-bot-api';
const bot = new TelegramBot(process.env.TELEGRAM_BOT_TOKEN);

async function sendTelegramNotification(
  user: User,
  type: NotificationType,
  data: Record<string, unknown>
) {
  if (!user.telegramChatId) return;

  const messages: Record<string, (d: Record<string, unknown>) => string> = {
    'order.shipped':
      (d) => `📦 *Order #${d.orderId} shipped*\n\nTracking: \`${d.trackingNumber}\`\nExpected delivery: ${d.date}`,
    'payment.failed':
      (d) => `⚠️ *Payment failed*\n\nOrder #${d.orderId} not paid. [Retry payment](${d.retryUrl})`
  };

  const text = messages[type]?.(data);
  if (!text) return;

  await bot.sendMessage(user.telegramChatId, text, {
    parse_mode: 'Markdown',
    disable_web_page_preview: true
  });
}

// User linking Telegram account
bot.onText(/\/start (.+)/, async (msg, match) => {
  const linkToken = match[1];
  const userId = await verifyLinkToken(linkToken);

  if (userId) {
    await userRepo.updateTelegramChatId(userId, msg.chat.id.toString());
    bot.sendMessage(msg.chat.id, '✅ Telegram connected successfully! You will receive notifications.');
  }
});

Preference Management

// Table user_notification_prefs
interface UserNotificationPrefs {
  userId: string;
  emailEnabled: boolean;
  smsEnabled: boolean;
  telegramEnabled: boolean;
  marketingEmailEnabled: boolean;
  marketingSmsEnabled: boolean;
  quietHoursStart: string;
  quietHoursEnd: string;
  timezone: string;
}

How to Prevent Notification Loss?

A notification queue with retry is the key element. On send failure (e.g., Twilio returns 500), the message retries after 2, 4, 8 seconds. After 3 failures, it goes into the DLQ (dead letter queue) for manual analysis. Delivery reliability without a queue is about 95%; with a queue, it's 99.9%. That's 50 times fewer lost messages. For example, with 10,000 notifications per day, without a queue you lose 500; with a queue, only 10.

Why Do You Need a Queue with Retry?

Services are unstable: Resend may delay emails, Telegram has rate limits. A queue with backoff guarantees the message will be delivered without a crunch. We use Bull Queue with Redis. Additionally, we set up monitoring: if the error count exceeds a threshold, we send an alert to the team in Telegram.

Channel Comparison

SMS is delivered 60 times faster than email, which is critical for payment notifications. Although the per-unit cost of SMS is higher, it's justified for urgent events.

How to Set Up Notifications: Step-by-Step Guide for Notification Setup

1. Define triggers. Which events in your app require notifications? Typical set: order placed, payment failed, password reset.
2. Choose channels. For each trigger, determine the preferred channel. Duplicate critical events to two channels (email + SMS).
3. Set up the notification queue. Integrate Bull Queue with Redis to process messages with retry and logging.
4. Create templates. Develop HTML templates for email, text templates for SMS and Telegram with personalization.
5. Test scenarios. Test each channel failure, rate limit exceeding, and correct error handling.

Process

What's Included

• Notification architecture design
• Integration for email (Resend/SendGrid), SMS (Twilio), and Telegram (Bot API)
• Queue and retry configuration
• Personal cabinet for preference management
• Scenario testing (load, channel failures)
• Documentation and team training

Timeline

Basic configuration (3 channels, 5 triggers, notification queue) — from 1 to 2 weeks. The timeline depends on business logic complexity. Contact us — we'll assess your project in 1 day. Get a consultation — we'll select the optimal channels for your business and traffic.

Notification Costs

We use providers with low rates: Resend from $0.001 per email, Twilio from $0.05 per SMS. Telegram is free. You only pay for actual usage, with no hidden fees. Optimizing channel selection can save up to 40% of your notification budget. For example, sending 10,000 transactional emails costs $10, while 10,000 SMS costs $500; switching to Telegram for non-urgent notifications can save thousands annually.

Email Campaign Integration: Why Does It Often Break?

We’ve observed that a trigger email sent 10 minutes after registration converts 4–5 times better than the same email sent after 24 hours. This isn’t a marketing myth—it’s mechanics: while the user is still warm, while they remember the context. But most integrations with email services are built like this: form submits → synchronous HTTP request to API → if the API is slow, the user waits 3 seconds → the email either goes out or doesn’t, nobody knows. In one project, we saw a 30% drop in conversion simply because the email service responded with 504 and Laravel’s queue driver wasn’t configured. Lost emails often hit customers silently – no log, no alert, just a missing order confirmation.

If you’re facing lost emails or spam folder issues, order an audit of your current integration – we’ll find bottlenecks within 2 days.

Providers and Their APIs

Unisender — a Russian provider popular in the SMB segment. REST API, simple. Adding a contact: importContacts, sending a transactional email: sendEmail. Important: for transactional emails (order confirmations, password resets), Unisender Go is a separate service with a different API and separate pricing. Mixing bulk and transactional mailings in one stream is bad for domain reputation. Unisender Go handles up to 1000 requests per second.

SendPulse — provides email, SMS, web push, Viber, and Telegram bots through a unified API. Convenient for projects requiring an omnichannel approach. Automation 360 is a visual chain builder; you can trigger automation via API events. The PHP SDK (sendpulse/rest-api-php-sdk) is maintained but updated irregularly – better to use Guzzle directly.

Mailchimp — a choice for international audiences and marketing teams accustomed to the Mailchimp ecosystem. Transactional email via Mandrill (a subsidiary service). Marketing API v3 for list, tag, and campaign management. Webhooks for opens, clicks, unsubscribes, bounces.

SMS. For Russia: SMSCenter, MTS Exolve, Devino Telecom, SMS Aero. Their APIs are similar: a send method with phone, message, sender parameters (sender name must be registered separately with the operator). One nuance: the sender name must be registered through the aggregator with a contract – otherwise SMS won’t be sent on MTS/MegaFon/Beeline networks.

How to Build an Integration That Doesn’t Lose Emails?

Separate Transactional and Marketing Streams

Transactional emails (order confirmations, password resets, delivery status) go through a dedicated sender domain or subdomain tx.example.com. Marketing campaigns go through mail.example.com or news.example.com. If a marketing campaign receives many spam complaints, it should not affect the reputation of the transactional stream. According to SendGrid documentation, transactional messages should be sent through a dedicated IP pool to prevent cross-contamination.

Queue and Retry

Any call to the email API goes through a queue (Laravel Queue, Bull, Celery). If Unisender returns a 503, the job retries after 5 minutes, then 15, then 60. After 5 failed attempts, it goes to a dead letter queue with an alert. The user already received their 200 OK and knows nothing about the issue. This approach reduces bounce rate on projects to 0.5%.

Example Laravel job:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry after 5 min
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Templates

We store templates in code (Blade, Twig, React Email), not in the provider’s interface. Reasons: versioning via Git, browser preview without sending, testability. For complex templates with dynamic content — react-email with export to HTML via @react-email/render.

Validation and Consent

Before adding a contact to a list — double opt-in (confirmation email). Store the confirmation timestamp in your own database. Upon unsubscription — synchronously unsubscribe both at the provider and in your database. Ignoring webhook unsubscriptions is a direct path to account suspension at the provider. All processes comply with Федеральный закон № 152-ФЗ «О персональных данных».

Deliverability Monitoring and DKIM Setup

Connect provider webhooks for events: bounce (hard and soft), spam_complaint, unsubscribe. Hard bounce — immediately mark the email as invalid in your database, stop sending. Soft bounce 3 times in a row — same. Metrics: open rate, click rate, bounce rate, unsubscribe rate — review at least once a week. Our certified engineers configure alerts in Grafana/Prometheus.

DKIM configuration steps:

1. Generate a key pair (e.g., openssl genrsa -out private.key 2048).
2. Publish the public key in DNS as a TXT record for the selector (e.g., mail._domainkey.tx.example.com).
3. Provide the selector to the provider (SendGrid, Mailgun, Unisender).
4. Verify with dig TXT mail._domainkey.tx.example.com.

SPF, DKIM, DMARC must be configured separately for each stream. We use subdomains with different DNS records.

Why Is It Important to Separate Streams?

If you send a marketing campaign from the same domain as transactional emails and receive spam complaints, you risk getting the domain blocked — and users will stop receiving even order confirmations. SPF, DKIM, DMARC (Sender Policy Framework, DomainKeys Identified Mail, Domain‑based Message Authentication, Reporting and Conformance) must be configured separately for each stream. In one project, a marketing blast with 12% spam complaints blocked the transactional domain for 48 hours — we had to re‑authenticate with Google and Yandex.

What Does the Integration Scope Include?

• Audit of current communication streams and domain reputation (SPF, DKIM, DMARC)
• Provider and schema selection: transactional vs marketing traffic
• Configuration of SPF, DKIM, DMARC DNS records
• Development of email templates (HTML + dynamic content)
• Backend integration via queues and API
• Webhook setup for deliverability and complaints
• Operations documentation and team training
• Deliverability guarantee and post‑launch support

We deliver production‑ready documentation, access to monitoring dashboards, and a handover session with your engineers. Our certified engineers provide a 30‑day post‑launch health check guarantee.

Timelines and Cost

Cost is calculated individually after audit. We provide turnkey service: from analysis to production monitoring. Contact us for a free engineer consultation — we’ll evaluate your project and give accurate timelines. Over 7 years of experience in email service integration, 50+ projects implemented. Order a free audit of your current integration and receive a report with recommendations and estimated savings.